Re: Bugzilla'd version of our gnats database

[Daniel Berlin <dan at cgsoftware dot com>]

On Thu, 20 Dec 2001, Joseph S. Myers wrote:

> 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?
Well, right now, it's a bit of magic based on state and class.
> 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?
Sure, i can rename that statuses to whatever you like/add more, etc.
> (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.

Yup, which is why it's off (it's configurable whether to use it or not).

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

Yes yes, i know.
I just fixed that bug.

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

Yes, I'm aware. It's trickier to handle, because the emails are just
*there* in the audit trail, intermixed with status changes.
So to avoid putting in duplicate data, you have to skip the email if we
just saw a status change, but otherwise, append it as a comment.
I'll do this tomorrow.
>
> 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.
Yes, I know.
>  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.
Sigh.
> Also, where is the original value of the
> Release field visible in the bug report?
Nowhere yet.
I haven't readded it since i had it merge versions.
I will though.
>
> Where is the value of Environment visible in the Bugzilla bug reports?
Nowhere yet.
> What about that of Class?
Class is pointless, it becomes severity.
>
> Can we get rid of the Severity field?
If you like, but it's used to determine the font style/color that is used
in the bug list, so you can visually tell the enhancement requests from
critical bugs, for instance.
 >  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.)

So then the only priority is that of either "targeted to a milestone" or
not?
How do you know the order to  work on bugs for a given milestone?
It's still useful to know the severity of a bug regardless of what
milestone it's targeted to.
Not everyone is always working on the next release, and it's silly to not
be able to prioritize non-relesae bugs.

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

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