GNATS vs. Bugzilla

[MattyT]

I see Matthew Barnson sent a message on the main gcc list.  I'll leave
out what he has stated already.

"Joseph S. Myers" 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.
 
> Can this be set up with a gcc-bugs or gcc-prs pseudo-user (or similar)
> that will receive messages for every new bug and every change,
> irrespective of any per-PR configuration anyone else does?

This is on a per account basis.  I seem to recall someone wanting this
before, it would likely be a one or two line hack to add an account into
consideration for all bugs.  In the near future it will probably be
possible to watch all the products in the system without any hacks.

> I'd like the audit trail send to the lists to be sufficient to both (a)
> ...

Bugzilla stores a full bug history.
 
> I do want to receive the attachments by mail on the lists.  I'm far more
> likely to look at a bug report when it is sent (rather than months later
> is at all) if everything necessary is there in front of me when reading
> mail rather than needing to look in a separate program for the
> information.

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.

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.

On Bugzilla systems many people tend to watch many bugs, and they don't
care about most attachments.  I probably watch around 1000 bugs on
bugzilla.mozilla.org, including Bugzilla and Mozilla bugs, and I
generally wouldn't wish to receive attachments on them.  If I do want to
see an attachment I'll look at its summary on the notification email and
then go into the bug system on the off case I care about the attachment.

> For GCC we decided some time ago to disallow confidential bugs.  I presume
> that Bugzilla can be configured to disallow anyone from creating
> confidential bugs or making bugs confidential as well?

If there are no groups defined to restrict a bug to, there can be no
restrictions.

> How are the rules determined for what accounts have what access to change
> what in the system?

By default users don't get to do most things, unless they are given
"editbugs" permission to do so.  Our security system needs to be more
fine grained so administrators can specify exactly who can do what, even
down to a field level.

> Ordinary users should be able to add attachments to
> their own bug reports (they complain about not being able to do it with
> GNATSweb) but should not be able to delete anything (bug reports should
> keep a full log - by all means mark an attachment as mistaken, but it
> should still be available from the system).

I'm pretty sure Bugzilla allows all this.

> ... but still not to remove information.

Comments and attachments can't be removed from Bugzilla, at least not by
users.

> ... for example, they shouldn't be able
> to set anything used to determine which bugs need fixing in a particular
> release (priority "high", in the existing GNATS system).

If a user doesn't have "editbugs" access they can't touch priority I
think.  Users with "editbugs" (and there are a lot on mozilla.org) know
what they're allowed to do for the most part.
 
> I take it Bugzilla will work properly with Lynx (which more than one of us
> currently use with GNATSweb)?  In some ways I'd also prefer to be able to
> work with basic HTTP user authentication rather than needing to enable
> cookies when manipulating bugs, but this isn't essential.

Most of the Bugzilla developers would probably use N4 or Mozilla.  From
time to time we receive reports on other browsers and they are treated
as important.  I'm not aware of any Lynx issues at present, but I can't
guarantee there aren't anyone if I don't know if anyone has tried it
recently.

> The existing GNATSweb system does not require logins to submit bugs;
> occasionally spam does get in (though probably through the gcc-gnats email
> ...

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.

> By administration I mean such things as closing mistaken bug reports or
> requesting feedback on those with insufficient information - so it should
> ...

I would assume the Bugzilla email interface does something along these
lines, but like I said I don't know anything about it.  We don't support
it yet.

> It would also be desirable if CVS commits could close bug reports.  At
> present, there's a limited system where the log_accum script can send the
> commit message to a single PR whose number appears in the log message -
> but not close the PR, and not send the message to more than one.

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.

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

> The FSF machines and sourceware
> (the current system) are the only options available (politically, if
> ...

In any case, you should be able to do everything necessary from a shell.

> What would need to be done to make it possible for anonymous users to
> obtain a consistent copy of the whole database?

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.

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