Re: Bugzilla'd version of our gnats database

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

On Thu, 20 Dec 2001, Neil Booth wrote:

> I'm not persuaded these distinctions are necessary; I've found the
> current system just fine.  Better just to add a comment when state is
> changed.  Bugzilla makes it easier / more obvious how to annotate a
> bug, so I suspect bugs would attract more comments than in GNATS,
> judging from some Bugzilla bugs on Mozilla which have over 100
> annotations.  Only recently I realised it was possible in GNATS.

Bugzilla has variants such as WORKSFORME - but GCC should define the
bug-tracking statuses that work best in the GCC process, rather than
Bugzilla driving how GCC manages bugs.  Having a single equivalent of
"closed" - covering both fixed bugs and bugs with insufficient information
- would work, provided there is clear GCC-specific documentation (as in
gnatswrite.html at present) of all bug states and what they mean in a GCC
context, that fits how GCC works rather than how some other project works.  
One thing that would be very desirable is proper tracking of versions in
which a bug is / is not present.

> > The "Platform" and "OS" fields have contents that are wholly
> > inappropriate in a GCC context.
> 
> Maybe; but if it means too much work and makes future upgrades of
> Bugzilla too difficult, then rewording them to refer to the target
> should be good enough - it's basically what we do now.  The other
> information could go elsewhere, like now, or in extra fields.

The default value choices in these fields are still completely irrelevant
to GCC.  Since we have target triples, which are the GCC equivalent, we
should use them (though if separate fields are used for "cpu", "company",
"system"/"kernel-os", that isn't a particular problem).  Again, GCC should
drive the data structures and process, not Bugzilla.

Bugzilla's defaults may give *ideas* about useful states and data 
structures that we don't currently have.  But based on ideas from various 
bug tracking systems, and knowledge of what process works for GCC, we 
should define what the right data structures to use with Bugzilla are, and 
make it fit them, rather than making GCC fit Bugzilla.

> > Can we get rid of the Severity field?  Can we get rid of Priority?
> 
> I think at least one of them is useful in addition to Milestones,
> being somewhat similar to "change-request" etc.

But "change-request" presently goes in Class - which is something that 
would be useful to keep around.

> Why not assign?  Aside from the fact they are often miscategorised
> (though this has improved by refining the choices to include things
> like bootstrap), are you not willing to have C front end bugs assigned
> to you directly?  You're the only active maintainer I think.  I am
> willing for preprocessor ones, though admittedly there are a lot fewer
> of them 8-)

I don't know exactly what assignment or ownership means, but:

* Almost all "c" bugs are not bugs in the front end.  Remember that we
document it as "A problem with the C compiler.", and it isn't reasonable
to expect users to work out where internally the bug is.  Where enough 
analysis has been done to work out where the bug is, the common case would 
be that the bug is fixed at the same time.  Other cases of genuine "c" 
bugs are likely enough to be ones I've submitted by self to track 
technical issues and reasons for XFAILs, such as c/456, which I don't have 
any immediate plans to work on.  Assignment should indicate some actual 
intent to be the person fixing a bug, which is something that should only 
be set by the person to whom it is assigned, except in the case where an 
identified change has caused a regression and the bug about that 
regression is assigned to the person who caused it.

That is, assigning to someone other than oneself should be exceptional:  
only where they've requested it or the problem is a regression and they
have been identified as causing it.  (If you add a new feature, and the
new feature has bugs in it but they aren't regressions, that shouldn't in
itself be sufficient reason for someone else to assign the bug to you.)

* There are two C front end maintainers.

* I don't want to receive any new bug reports directly by mail (except
ideally copies from the bug tracking system of those I submit); I'll 
receive all the bug reports, comments on them, changes to them and 
attachments, for any part of the compiler, through separate list-receiving 
addresses for gcc-bugs and gcc-prs (if we make GCC drive the process and 
have everything go to mailing lists, rather than Bugzilla drive the 
process and decide that we don't want that or don't want attachments by 
mail).  I don't want to receive Bugzilla-generated messages by personal 
mail except on bug reports I've submitted, chosen myself to claim, added 
myself to the CC list on, or those marked as duplicates of such PRs 
(though people can always choose to CC other people they think relevant on 
individual messages to the lists; does Bugzilla have an equivalent of 
X-Debbugs-CC to CC someone with a bug report after it has received its 
number?).

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