Bugzilla versioning (was Re: kudzu segfault with latest kernel)

[Will Woods]

On Thu, 2007-09-27 at 10:17 -0400, Robert P. J. Day wrote:
> On Thu, 27 Sep 2007, Chuck Anderson wrote:
> 
> > On Thu, Sep 27, 2007 at 09:40:27AM -0400, Robert P. J. Day wrote:
> > > p.s.  if i'm running a fully-updated f8t1, would that be classified as
> > > an f8t1 or f8t2 system, for the purposes of bugzilla?
> >
> > It is "devel".
> 
> um ... ok, but if that's the case, what is the value of the f8t1 or
> f8t2 selections in bugzilla?  those designations might be valid for an
> absolutely pristine install but, the instant you update, it becomes
> "devel"?
> 
> and that would seem to not match the tradition of, no matter how many
> times you update an f7 system, you would still file reports under
> "f7".
> 
> can someone clarify this?

In the Glorious Future, we will have a version called "rawhide" instead
of "devel". So it'll be a little less confusing there.

As for the value of having the test releases listed... there are
arguments on both sides. Yes, it's less confusing to have all rawhide
bugs go in once place. Unfortunately we now have 5000 rawhide bugs of
varying ages. 

I think my ideal procedure would be something like
1) File rawhide bugs against - surprise - "rawhide".
2) When the final release happens:
2a) move all open *verified* rawhide bugs to the final release version.
2b) all open *unverified* bugs get put in NEEDINFO.
3) After 2 weeks, unverified bugs from rawhide still in NEEDINFO become
CLOSED INSUFFICIENT_DATA.

Obviously, this leaves us with an unanswered question: how do we verify
bugs?

I'd suggest this: any bug you can reproduce should be moved from NEW to
VERIFIED. Except "VERIFIED" is supposed to be used for bugs that have
fixes, and the *fix* has been verified by QA. So maybe we need a
different state for this. GNOME has their new bugs start in UNCONFIRMED,
and they move to NEW once someone has verified them. 

Does anyone have experience with the GNOME bugzilla and how well that
works? And how many bug triagers does this require? How much hardware?
Can we do it with the current group of people we have doing bug
triaging?

It's still up for discussion. Suggestions are welcomed, especially if
you've got facts to back 'em up.

-w
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-test-list/attachments/20070927/6ebffdbb/attachment.sig>