Bugzilla'd version of our gnats database

[Joseph S. Myers]

On Thu, 20 Dec 2001, Daniel Berlin wrote:

> I've put up the current version (no attachments, no bug activity, and the
> users need to be pruned) at http://www.dberlin.org/bugzilla-2.14
> 
> 
> Please only modify new bugs you create, unless you are sure it's only
> going to send mail to people who won't care.
> Otherwise, go wild.

Initial observations, I'm sure there will be more later:

How do GNATS PR statuses map into Bugzilla ones?  The GCC-specific meaning
of GNATS statuses is described in gnatswrite.html.  I suspect we want to
define our own set of statuses and allowed transitions for GCC - does
Bugzilla allow this?  (For example, I don't consider WONTFIX a reasonable
way of resolving a bug, though we do need an equivalent of the current
"suspended".)  We should probably have statuses meaning:

* New (unconfirmed) - present "open".

* Confirmed (present "analyzed"), with or without a person responsible.  
A version and platform on which it was confirmed should be an integral
part of this status, though they'll be unknown for existing bugs being
converted.

* Insufficient information in bug report - present "feedback".

* Closed for insufficient information, none provided after enough time in 
previous state - present "closed".

* Information sought from submitter on whether bug is now fixed - present 
"feedback".

* Closed because maintainers believe the problem is now fixed - present
"closed".  Should have attached version in which the problem is found to
be fixed.  However, I don't think we need separate statuses for before /
after particular versions ship - the only special cases is where a bug is
fixed on the release branch but not on mainline, in which case the bug
report must remain basically open even if it is noted to be fixed in a
release branch version, or where it has been fixed on the mainline but
should be considered for a release branch fix before finally fully closing
the bug.

* Closed because of insufficient information - present "closed".

* Closed because not a genuine bug - present "closed".

* Duplicate of some other PR - the lack of this is one of the serious 
deficiencies in GNATS.

The Bugzilla documentation also describes a system for QA people to verify
the fixedness of bugs, which seems unnecessary in a GCC context.

The "Platform" and "OS" fields have contents that are wholly inappropriate
in a GCC context.  Rather than having these, we should have the
host/build/target fields from the bug reports - and, separately, an
indication of systems (normally targets) on which the bug has been
verified or believed to apply (might be "all", might be a list of
several), or maybe a list of (system, version) pairs.  (We should also
split the "target" category into separate categories for each CPU, but
that's another matter.  PRs that don't belong in "target" may still only
show up on a subset of architectures.)

I looked at a PR with various status changes,
open->analyzed->closed->analyzed, other/895.  The converter seems not to
have converted all the status change messages properly.  It has produced
links like "mailto:rodrigc", which should have @gcc.gnu.org in them.  
Comment#3 in the bug report has a subsequent status change message, which
ought to be a separate comment, appended to it.

I looked at the converstion of web/1646.  That also seem to have problems.  
The reporter is given as "anonymous@sourceware.cygnus.com" in Bugzilla - 
this is wrong, gnatsweb shows it as neil@gcc.gnu.org.  Some comments I 
emailed to that PR, which show up in the audit trail in gnatsweb, do not 
show up in Bugzilla.

There are problems with the Version field values.  "CVS" isn't a useful 
value, it should change to "unknown".  The 3.1 values should merge to 
3.1-pre.  There are "2.96 (redhat)" and "2.97 (redhat)" values - but there 
is no 2.97 (Red Hat) version, and 2.96 (FSF) and 2.96 (Red Hat) ought to 
be distinguished in the list.  Also, where is the original value of the 
Release field visible in the bug report?

Where is the value of Environment visible in the Bugzilla bug reports?  
What about that of Class?

Can we get rid of the Severity field?  Can we get rid of Priority?  I
think Milestones are more useful - and all "high" PRs should get a
"3.1-to-confirm" Milestone (needing someone to verify that this is a bug,
and a regression from 3.0 or 2.95, then set to "3.1"), other a "after-3.0"
Milestone, to change to "after-3.1" or "3.1".  (Every release cycle, all
bug reports with an indeterminate "after-last-version" Milestone need to
be checked to see whether they have been fixed in the meantime, and if not
whether they ought to be fixed for the next release.  Using
"after-VERSION" Milestones for this seems like one plausible method.  The
default should be equivalent to "after-V" where V is the last version.)

There's a "Reassign bug to owner of selected component" on the form, how
are these owners defined?  I think there should be none, except where we
currently have a default assignment, which I think is just currently
"gerald" for "web" bugs.

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