This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Bugzilla features


On Sun, 2001-11-18 at 17:04, Neil Booth wrote:
> Hi,
> 
> I work on GCC (gcc.gnu.org) and we currently use GNATS as our bug tracking
> system.  However, it is painful in many respects; just a few examples are:

  Funny thing you should mention that.  I went to a Linux convention
last week where I got to meet Bruce Perens (pretty cool!).  He mentioned
that savannah.gnu.org needed a real bug-tracking system, and asked if
I'd look into it.  There has been conversation this last week with the
core developers about making Bugzilla work under Savannah.  However,
that's not the be-all-and-end-all of Savannah work, it may be that a
complete rewrite is easier.

> Could someone who knows Bugzilla well possibly take some time to read the
> above mail and answer his points, back to this newsgroup? If you cc:
> gcc@gcc.gnu.org that would be great, but I'm happy to gather up the
> answers and relay them if that isn't done.

  See below.  I maintain documentation on Bugzilla, so I'm fairly
familiar with the warts and features, although I'm continually
pleasantly surprised every time I download the latest version :)


> In particular, we'd like to be able to do more administration and handling
> of bugs via e-mail (like the Debian bug system can).

  Not Bugzilla's strong point right now.  I have some patches pending
(sheesh, looking now, pending for over a year) which add some more
functionality to the email interface.  Some things don't work as
expected, but I anticipate a few days of hacking by a decent coder would
fix it up.


>  And would it be easy
> to migrate the existing GNATS database in some form, or would that
> information be lost?
$BUGZILLA_HOME/contrib/gnats2bz.pl .  May need some hacking to match
current database format.  I haven't used it in years.

-------------------------------------------------

Remainder is a response to the referenced questions:

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.

  This is very do-able with Bugzilla, and is a relatively common setup. 
You would create a new Q/A contact for all new bugs in a product which
is actually an alias to a mailing list (the account should be disabled
in Bugzilla) held elsewhere.  No biggie.
  Someone would have to set up the filter on that account, but as I said
this is a very common thing to do with Bugzilla. 


2. Handles MIME in mail.

  You mean MIME attachments?  Yep, Bugzilla does it, but it doesn't
currently read MIME type really well.  If it's text, it shows up as
text, but anything that's binary is simply binary (Microsoft Word .doc
files and such) if downloaded from the web interface.  Also the binary
attachment will NOT be forwarded to the mailing list -- only the body
text will go as a comment.


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).
  As I mentioned before, rather than sucking up bandwidth by forwarding
the actual MIME attachment, bugmail sends a link to the web site and a
comment.  bugmail is *not* enabled at bugzilla.mozilla.org, however (due
to potential abuse reasons), so it's tough to try it out without setting
it up yourself.
  
4. All existing URLs for individual PRs get redirected to the
corresponding URLs in the new system.

  $BUGZILLA_HOME/contrib/gnats2bz.pl.  However, this perl script may
require some updating to match the new schema -- anybody can
confirm/deny this?  I used it once two years ago and it worked great,
but I haven't used it since.

5. Follow-ups sent to gcc-gnats for existing PRs get filed properly in
any new system.
  Hmm, mirroring a mailing list to the bugmail system?  That would be
problematical, but could be done with the right procmail filters in
place.  It's easier to say that followups to
"bugzilla-daemon@wherever.org" would go to bugmail, but not replies to
the mailing list.  Bugzilla's not a mailing list archive system, really.

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

  Browsing is easily done.  Just don't set up bug security.  If you want
some bug security, it's just as trivial.  However, if someone wants to
create a bug, they have to set up an account.  This is a major
difference with it and gnats... Bugzilla, by default, is not an "open
bug receiver".  I have a patch to enable automatic bug creation upon
emailed bug submission, but I can tell you from experience that this is
an open door for Spammers to get a large target audience.  

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

  Not available.

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

  Bugzilla is currently back-ended into MySQL (see
http://www.mozilla.org/projects/bugzilla/ ).  Dave Lawrence of Redhat
has done an oracle port, see http://bugzilla.redhat.com/.  Dawn Endico
made Bugzilla's XML DTD the industry-standard bug-tracking DTD (no
standardization committee, but most open bug-trackers support the format
now).  So you can do a mysql dump of data, export it via XML for
importation elsewhere, or export your existing data to an
easily-understood XML format for importation.
  Bugzilla includes a "sanity check" to find basic database issues with
data formats.  It's not comprehensive, however.  I recommend a good
daily backup strategy for any Bugzilla database, which is covered in
great detail at the mysql.com website.

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.

  Bugzilla says "Zarro Boogs Found" on null searches.  Fixed easily by
doing "for i in `ls`; do cat $i | sed 's/Zarro\ Boogs/No\ Bugs/g'
>$i.tmp; mv $i.tmp $i; done"

>>The current GNATS setup only fits 4, 5 and 8.  How does Bugzilla do?
  I think it does pretty well, all things considered.  Is gcc using
Savannah?  If so, we might have some nice "synergy" going here...

I am not subscribed to the "gcc@gcc.gnu.org" mailing list, so I won't
see replies there.  Reply to mozilla-webtools@mozilla.org or me
individually where I can forward stuff to the core team.

Thanks!


-- 
Matthew P. Barnson
Talk2 Technology, Inc.
"There are three kinds of people in the world.
Those who can count, and those who can't." -unknown


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]