Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 4 Sep 2014 22:38:48 -0400
From: Alain Toussaint <>
Subject: Re: Time for a bug tracker?

I haven't commented much here but at SAP (Montreal Labs where I work), we
use Jira but I agree it's a heavyweight framework which is probably too
much for the requirement you posted (it meet our needs) but I have 4 hours
free Sunday so I'll look up for a good bug reporting system. I also plan to
be more involved wrt musl in a year but in the meantime, I will strive to
give more time to musl before that.


2014-09-04 20:32 GMT-04:00 Rich Felker <>:

> I'm wondering if we've reached the point yet where musl really should
> have a bug/issue tracker. I know I've started to have a hard time
> keeping track of open requests for bug fixes, features, etc.
> If we do add a bug tracker, here are some criteria I think would be
> useful for selecting one:
> 1. Easily integrates with our current developers' and
>    users'/bug-reporters' preferred tools/workflows:
> - No need for heavy web browser, but convenient to use with one if you
>   do want to.
> - Ability to query and make changes to issues via command line tool
>   and/or email if preferred.
> 2. Easy to link to other resources:
> - Mailing list message that reported an issue, if it was first
>   reported/discussed by email.
> - Git commit that introduced bug, if it's a regression.
> - Git commit in test repo that adds regression test, if any.
> - Downstream bug reports (e.g. in musl-based distros).
> 3. Practical to host on light musl-based hosting:
> - No dependency on Apache or other bloated httpds.
> - No dependency on ultra-bloated application frameworks or language
>   runtimes like Java, though Python, Perl, or PHP could possibly be
>   tolerable.
> - No dependency on bloated database backends.
> One thing I'd like to consider, if/when we do setup a bug tracker, is
> importing a sort of bug history, generated 90%-mechanically from musl
> git history, so we can have searchable records of past bugs and
> corresponding regression tests in it. One motivation for this is that
> I'd like to have separate bug status for "fixed, pending regression
> test" and "fixed, has regression test" so that we could track which
> bugs are missing regression tests, and do that tracking for historical
> bugs too.
> Any recommendations? I have the most experience with bugzilla, and
> like it well enough, but I don't know where it stands for all the
> criteria above.
> Rich

High confidence was slightly more associated with an incorrect response.


Content of type "text/html" skipped

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.