Re: Bugzilla for GCC project?

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

On Mon, 27 Jan 2003, Daniel Berlin wrote:

> Do we have an exhaustive list of versions i can use?

releases.html, then add one to the patchlevel of the last release on each
branch to get the number for head-of-branch.  But versions before 2.95
probably aren't worth including unless there are many bugs filed for egcs
1.1.2 etc..

releasing.html and branching.html will need to detail where Bugzilla gets
new version numbers (and milestones corresponding to them) added, when new
release branches are made or releases cut.

> Would you rather mark these as UNCONFIRMED, or do you want a WAITING or 
> FEEDBACK state?

Some such WAITING or FEEDBACK state - preferably different from what's
used for "suspended" bugs, so it's easy to do a search for "feedback" bugs
that haven't been touched in three months and so are good candidates for
closing.

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

It's the lack of the QA structure to distinguish these things that's why
we might as well not have these distinctions - but if we do have them, it
will just mean they aren't necessarily used very accurately, and it
shouldn't make much difference to work on GCC bugs either way.  So
probably keep the distinctions if someone wants to use them, otherwise
not.

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