Re: Time for a bug tracker?

[Alain Toussaint <alain.toussaint@securivm.ca>]

[-- Attachment #1: Type: text/plain, Size: 2531 bytes --]

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.

Alain


2014-09-04 20:32 GMT-04:00 Rich Felker <dalias@libc.org>:

> 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.

source: http://www.ncbi.nlm.nih.gov/pmc/articles/PMC1279512/

[-- Attachment #2: Type: text/html, Size: 3260 bytes --]