Re: GNATS vs. Bugzilla [Get raw message]

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

On Tue, 20 Nov 2001, MattyT wrote:

> > Grep and the existing search engine work fine for searching the list
> > archives for past discussions (on any list) of an issue - whether bug
> > reports, patches, or other discussions - having everything go to the lists
> > avoids the need to use multiple search mechanisms.
> 
> I cringe at this statement.  We often find our search mechanism fails to
> find what we are looking for, so a grep would be even worse (or
> slower).  I can only assume you deal with a lot less bugs than Bugzilla
> has been designed to handle.

The basis is that there are about 700Mbyte of past discussions on the gcc,
gcc-bugs and gcc-patches lists (and egcs, egcs-bugs, egcs-patches before
them) since 1997, most of which was not sent to any filed bug report (the
GNATS database is less than 250Mbyte).  There's also a lot more on other
mailing lists which however receive less discussion, that might
occasionally be useful to search (e.g. gcc-testresults, gcc-regression).  
A search only of the bug database would miss most of this.  If everything
goes to the lists, then searching the lists only continues to suffice
(though we could do with a better search engine for many gigabytes of list
archives than htdig - however, whatever search engine is used needs to be
free software).  The problem with finding stuff is generally one of 
remembering precise wording that appeared in the messages I want to find 
and not elsewhere - having read essentially all those messages, and 
remembering that there was a particular relevant one without remembering 
its contents verbatim with enough accuracy.

> I would imagine a good deal of resistance to sending megabyte
> attachments over a mailing list.  Megabyte attachments have been known
> to happen at mozilla.org.  So that's probably why this hasn't happened
> to Bugzilla.

The message size limit on gcc-prs is 2Mbyte (imposed after someone sent a
25Mbyte attachment, which was problematic); that on gcc-bugs is smaller
(maybe 400kbyte).  Given these limits, message sizes don't seem to be a
problem; very few attachments were over 2Mbyte anyway.  The system mailing
them out just needs to handle bounces gracefully (quite likely by simply
discarding them, or filing them somewhere that can be investigated if
there's a problem, but not attaching them to the bug reports in question).

> There is probably a difference of process here.  Most attachments at
> mozilla.org are patches to fix bugs, which are then reviewed, and later
> versions might then be attached.  Testcases, demonstrations, etc, are a
> relatively small fraction of the attachments.

Most attachments are testcases for GCC.  For patches, we want them all to
go to gcc-patches, in the body of the message rather than as an
attachment, which is the most convenient way for everyone to comment on
them.  The right way for them to be joined to bug reports in the GCC 
context would simply be for people sending patches to CC the appropriate 
Bugzilla address and include the appropriate magic naming the bug report 
in the subject line (or mail a per-bug address, if appropriate), not 
anything involving explicitly attaching them to bug reports.

> think.  Users with "editbugs" (and there are a lot on mozilla.org) know
> what they're allowed to do for the most part.

This seems to work fine for GCC at present as well (without anything more
fine-grained).

> If its a hard and fast requirement this script does not break you would
> definitely have to modify and/or tack code on to do necessary
> conversion, and someone would have to write this.  I don't see any
> particular problem with auto-creating accounts server-side if you're
> willing to do the legwork.

We do need the existing deployed gccbug script to work (with some
converter) and for such submission (maybe with a new script) by mail from 
a script to continue to work.

> This gets thrown around occasionally but never seems to get
> implemented.  One thing that needs to be considered is a bug might need
> several cvs commits to be closed.

If the mail interface can close bugs, it should be possible to adapt
log_accum.  At present it looks for text "PR foo/9876" and sends a message
to the bug, but it could look for other forms such as "Fixes Bug#98765"
and "Partly fixes Bug#98765" (with appropriately precise definition of the
format accepted).  (I think Debian has some such system for package
uploads to close bug reports there.  In general I think the idea of
closing a bug report when the relevant change is made is desirable.)

> > Are there multiple administrators on the FSF machines familiar with
> > Bugzilla and the underlying database?
> 
> I couldn't answer this.  I'm not familiar with FSF politics and such. 
> GNOME is an FSF project isn't it?  They seem to run Bugzilla fine.

It seems to be hosted by Red Hat.  I don't know whether the people
concerned are available to help with any Bugzilla installation on
sourceware.

> I'm not sure.  This might require a lock on the database, although I
> think MySQL has the ability to replicate to other MySQL machines.  I
> can't answer this question for sure.
> 
> The FSF's backup strategy must be terrible for this to even be an issue.

It's sourceware's (past lack of a) backup strategy that's the problem
rather than the FSF's - and the political point that we shouldn't go less
open, so since the bug database is now anon-rsyncable we shouldn't lose
this ability.

-- 
Joseph S. Myers
jsm28@cam.ac.uk