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'd version of our gnats database


Joseph S. Myers wrote:-

> We should probably have statuses meaning:

Bugzilla seems to indicate status by 2 fields - the combination of
status and resolution, which is more flexible but does seem to cause
some overlap and meaningless combinations.

> * 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.
> 
> * Closed because not a genuine bug - present "closed".

These already exist, as indicated by
http://bugzilla.mozilla.org/queryhelp.cgi#status

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

Similarly, this already exists; further you can do proper linking of
bugs and their tracking I believe.  You can also mark bugs as
dependent on others being fixed, and view dependency relations.

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

Something equivalent doesn't appear to exist, I agree it would be a
useful addition.

> * 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 of insufficient information - present "closed".
>
> * 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.

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.

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

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

Yes, and I don't think we want all the snapshots either.  Just "3.1
snapshot" would be enough IMO, possibly with the excruciating detail
elsewhere.  Presently it's just noisy.

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

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

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

Neil.


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