Re: Bugzilla for GCC project?

[Daniel Berlin <dberlin at dberlin dot org>]

On Monday, January 27, 2003, at 01:56  PM, Joseph S. Myers wrote:

> On Mon, 27 Jan 2003, Daniel Berlin wrote:
>
> > If you want to see the current bugzilla, it's at
> > http://www.dberlin.org/bugzilla-2.17.3/
> It generally looks fine (and looks better with Lynx than some older
> Bugzilla versions - except Lynx complains "Accept invalid cookie
> path=/bugzilla-2.17.3/ as a prefix of '/bugzilla-2.17.3'" about it, I
> don't know what this is a bug in; GNATSweb also used to have such a
> problem, which got fixed).
I probably wrote the prefix wrong, it's in the parameters. I just did 
what it said to write.

> Residual conversion issues (losing information in the conversion, so
> preferably to be resolved before transition - though as previously
> discussed GNATS is also losing information as long as it runs, the MIME
> headers on messages people send to PRs):
Sure.

> * The full version number string (with the exact compiler date) is 
> still
> getting lost in the conversion.
Oh yeah, i'll just append it to the report string (since we don't want 
8 million versions listed in the version box).
>   (The specific version numbers listed are
> also missing numbers used for head-of-release-branch bug reports - 
> 2.95.4,
> 3.0.5, 3.1.2, 3.2.2 - as well as 2.95.1.)
Do we have an exhaustive list of versions i can use?

I just regex search for every version that popped into my head as 
having seen, so i'm sure i just missed them.
> * "feedback" PRs show up as RESOLVED/FIXED.  They clearly aren't 
> resolved,
> though in the absence of feedback they'll get closed eventually as 
> INVALID
> / WORKSFORME.
Would you rather mark these as UNCONFIRMED, or do you want a WAITING or 
FEEDBACK state?
I've added a WAITING state in anticipation, i'll make it use it in the 
next conversion.
T
> 		
> * Do people think the information in "Class" (doc-bug, 
> ice-on-legal-code,
> ...) is useful?  (I don't care much about it, but perhaps it should 
> end up
> as a keyword in the new database or something.)
>
>
> Conversion issues that can be dealt with afterwards but shouldn't be
> forgotten (bugs can always be opened in the new database to track 
> them):
>
> + "suspended" PRs show up as RESOLVED/LATER which means they don't 
> appear
> in default searches, even though they are logically open bugs.  Past
> discussion suggests they should be kept open but the information about 
> why
> they are suspended be kept in other fields, e.g. dependencies.  (Though
> the bug I opened for suspended C++ parser bugs to depend on, in the
> expectation this transition would be done before the new parser, has 
> been
> fixed by the new parser.)
I'll mark them WAITING.
> + What's the logic in which bugs show up as RESOLVED, and which as 
> CLOSED,
> and is the distinction useful?  (None show up as VERIFIED, so we 
> probably
> don't need that status.)
VERIFIED is for verified by some qa person. RESOLVED means the 
developer thinks it's fixed now. CLOSED means the bug was fixed and the 
released that fixed it shipped.
In effect, you could archive and remove old closed bugs, but you don't 
want to remove any resolved/verified bugs, since they may be reopened 
if something doesn't really fix the bug.

We *could* use VERIFIED, but i don't think it matters for our purposes, 
since the only time we'd have a distinction is when a developer 
*thinks* a patch fixes a bug, but isn't sure.
I'm not sure that people would use it.
> --
> Joseph S. Myers
> jsm28@cam.ac.uk