GNATS vs. Bugzilla

MattyT matty@chariot.net.au
Wed Nov 7 06:30:00 GMT 2001


Hi, this message got brought to my attention.  I am a member of the
Bugzilla team.

I have to say I don't have much experience with GNATS.  I am assuming it
is a dead project (which seems to be the case from the dates on the
page), and that my lack of experience is because most installations have
since transitioned to Bugzilla from other systems (like GNOME did
recently from debbugs).

Firstly, I'll deal with your requirements.  Bugzilla does not give you
much of what you have asked for (and I don't think it needs to), but it
does give you much of what you didn't ask for, but I think would be very
useful for you, which I'll cover later.

> 1. Works in a generally mail-based system: bug submission by a gccbug
> script, bugs sent to gcc-bugs / gcc-prs mailing lists, follow-ups that go
> to a bug tracking system address stored with the bug and sent on the
> gcc-prs, full audit trails of every change to a bug sent to gcc-prs.
> 2. Handles MIME in mail.
> 5. Follow-ups sent to gcc-gnats for existing PRs get filed properly in any
> new system.

I'm not really sure the benefit of this is that great.  Bugzilla has an
email interface in its contrib directory, but it is rarely used I
believe, I've never looked at it, and we don't guarantee it even works. 
People just don't care enough to want an email interface when they're
using Bugzilla.  I'm not sure if GNATS had an email interface and the
reasoning for this requirement is basically inertia, but if you rule out
Bugzilla because it doesn't do things the same, you're doing yourself a
great disservice.  Many people are probably familiar with Bugzillas
anyway, and in all likelihood they would prefer it.

Bugzilla does use email for notifying people of changes, and very
effectively.  People can choose what bugs and what changes they are
interested in.  Then it is very simple to follow a link into the web
interface if you want to do something.  Other bug systems are painful in
comparison.

You could make some small hacks to Bugzilla to generate an email for
each new bug or each change or whatever, and send it to a mailing list. 
However, you don't really need such a facility when you can set up your
own email preferences.

> 3. Where files are attached in web submissions, they appear in mail as
> MIME attachments, compressed if large, not as base64-encoded junk needing
> manual decoding (as at present).

Bugzilla does not send attachments on emails.  Bugzillas have a tendency
to have communities of people form around them because it is so easy to
help out.  Hence this would result in large amounts of useless
attachments being sent out.  I suppose it is a reasonable RFE to send
attachments in certain situations, and I will file that, but I believe
if you used a Bugzilla you would not consider this a major issue.

> 4. All existing URLs for individual PRs get redirected to the
> corresponding URLs in the new system.

Nothing to do with Bugzilla, I imagine.

> 6. No login required for browsing of bugs or submitting new bugs.

Bugzilla does not require a login for searching or browsing of bugs,
however obviously confidential bugs will not appear.  If you try to do
something that requires a login it will prompt you for a login and then
do the action.

Bugzilla does require a login for submitting bugs.  You need to create
an account.  I consider this a good thing.  Email addresses need to be
verified by bug tracking systems in the same way as mailing lists (to
prevent abuse).

> 7. Preferably possible to do all administration by mail (as with debbugs).
> (If more security than debbugs is wanted, plaintext passwords (as at
> present) or digital signatures can be used to authenticate changes.)

I have never heard anyone ask for this before, I don't think Bugzilla
admins consider it necessary.  Administration isn't and shouldn't be a
regular enough process to need to learn cumbersome administration
languages.  Bugzilla has a fairly easy web administration interface.

> 8. Either stores bug reports in a format such than non-experts can readily
> locate and fix corruption, or a commitment must be available of sysadmin
> time to fix corruption problems rapidly.  ISTR that Bugzilla uses a
> database backend - which I'm not competent to fix corruption problems
> with, and I had to deal with the last problem with PRs getting lost since
> the main sysadmins weren't interested (see
> http://sources.redhat.com/ml/overseers/2001-q2/msg00156.html and related
> messages).

Yes, Bugzilla uses a database.  No seriously functional bug tracking
system could exist without one, I believe.  I'll presume GNATS probably
works OK for GCC because you're not dealing with as many bug reports as
some other projects.  One of the reasons GNOME moved to Bugzilla was I
believe because debbugs was melting down under the strain.

You should perhaps consider moving your system elsewhere if your system
administrators are not responsive.  But I think more to the point is
asking why this is such a major issue here.  Corruption is generally not
a major issue for Bugzillas, and even when it is it is rarely serious.

Where there is a problem on your installation on all installations,
it is also worthwhile remembering that Bugzilla is a lively and
expanding project, and we generally are only too happy to help out
people, although you might occasionally need to pester some people as
most of us do it for the love not the money.

> 9. The web interface should not treat the absence of bugs matching a
> search as either an error condition or an opportunity for a silly message;  
> it should simply state the absence of matching bugs.

Well, Bugzilla's error message is "Zarro boogs found.", make of that
what you will, but perhaps more importantly is that as of the upcoming
version 2.16 this should be customisable as will be most of the
interface.

So anyway, allow me to say what I believe you're missing:

Bugzilla has a more advanced query system than GNATS, and you can store
packaged queries for later recall.
Bugzilla allows the specification of dependencies between bugs.
Bugzilla allows the charting of historical data on bug counts.
Bugzilla is more open in allowing volunteers to help out, when tends to
promote volunteerism.
Bugzilla allows voting for bugs you want fixed.
Bugzilla has a facility where a QA person can verify the resolution of
each bug.
Bugzilla allows users to easily receive email that they are interested
in and eschew email they are not interested in.
Bugzilla has an active community that can give you a good level of
support through mailing lists or IRC.
... and probably lots more I have forgotten.

So while GNATS appears to me to be nicer than something like debbugs
(which has improved a bit in recent times but is still painfully
unfunctional), there is plenty that Bugzilla can give you.  I hope the
above list seems useful to you, but even if it doesn't, let me assure
you they are all useful and are used.

I don't pretend we're perfect.  We have a long way to go.  If you do
decide to move to Bugzilla you will likely lose some things you're used
to, but I think you will gain much more.  In particular we have had
problems in the past where administrators have needed to put various
code hacks in place to customise their installations.  But there are
various improvements coming down the pipe in that department, and I
believe we are better than other systems anyway.

Please check out bugzilla.mozilla.org or bugzilla.gnome.org to get a
feel for Bugzilla.

-- 
         Matthew Tuck: Software Developer & All-Round Nice Guy        
 My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award
1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic
         Emperor 1998 Released From Smith Psychiatric Hospital



More information about the Gcc-bugs mailing list