Bug tracking

[Nathan Sidwell <nathan at codesourcery dot com>]

Martin,
> The downside, of course, is that the real bugs are piling up in my gcc
> bug folders - nicely sorted as badcode, internal, notaccepted,
> shouldnotaccept, wishes; without being touched at all, it seems. So if
> anybody is running out of things to fix in g++ - I could offer quite
> some input :-)
Codesourcery has hired me to fix bugs, I was going over the testsuite
to find them, and some of the bug reports to the lists. If you've got
some popular ones, let me know. Front end g++ template bugs are the
current emphasis, bug other front end bugs are fine too.

Please let me know.

> Seriously, if we can switch over to some online bug tracking system, I
> *would* install all those there, even if it may take a couple of
> full-time days to do so.
Yup, the deployment of gnats never really took off did it? The one I was
putting together at that time ran into a killer modperl bug, which I
had insufficient time to work around, and then gnats was deployed, so
I lost interest.

The lack of a proper bugtracking system is hampering the GCC effort. I think
we have a good reputation for fixing bugs, reported via the list, but it
is rather haphazzard and does result in lost bugs. We also
have the risk of multiply fixing the same bug, rather than just one of
us marking it as `I'm working on it'.  I noticed the ease-of-use
competition (http://software-carpentry.codesourcery.com/) has a bug-tracking
theme - can we wait that long? (I think not).

All the existing bug trackers fell down in some way,
* Most only accepted data via web pages, and wouldn't allow upload of
(big) source. Or they only accepted via email. Never both. (there's a comment
in bugzilla to the effect that `we really ought to implement this').
* The formating and classification didn't really fit with our needs, and/or
was hard to change. Bugzilla, for instance, is all perl which prints
the HTML. To change the categories was difficult.
* several implemented their own data base, rather than using an existing one
(jitterbug is simple by moving files around, but has limited indexing), Bugzilla
gets it right and uses Mysql.
* the emergence of sourceforge might help us, but again their bug tracker is
all web based without upload facilities. (AFAICT)

What I'd got was using mysql, modperl and mason (a neat way of embedding perl in
HTML). I found it much easier to embed the perl in the HTML than vice versa.
All the formatting of bug reports was held as metadata in the mysql database,
so it was easy to change formatting, and the cross referencing with fields.
The plan was that all the configuration was in the database, so that was the
only thing which was specific to a particular project. In fact the development
proceeded as a way of entering the metadata via the web, and as a byproduct
the bug tracker fell out!
The point at which I stopped was with acepting mail, where the CPAN package I
used caused modperl to go into an infinite loop.

I could probably get that working, or deploy a student on it, but they'll
need financial incentive, I guess.

nathan
-- 
Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org