----- Original Message -----
From: "John Poelstra" <poelstra@xxxxxxxxxx>
To: "For testers of Fedora Core development releases" <fedora-test-list@xxxxxxxxxx>
Sent: Thursday, April 02, 2009 8:00 PM
Subject: Re: Draft for 'Bugzilla processes and procedures' mail to
developers >> On Wed, 2009-04-01 at 21:22 -0700, John Poelstra wrote: >> >>>> Hi, -devel-list folks! >>>> >>>> We in the Bugzappers team (part of the QA group) are working to revise >>>> our Wiki space, and as part of that, various questions have arisen with >>>> regards to Bugzilla procedures. A lot of the same issues have come up on >>>> this list in the recent past. >>>> >>>> In general, it seems like Fedora doesn't really have a properly defined >>>> procedure for exactly how a bug should flow. Every maintainer, reporter >>>> and triager has a slightly different idea of what each status or >>>> resolution or keyword means, and when and by whom they should be >>>> applied. >>> I think you are overstating a problem that I'm not sure exists. We have >>> defined the states here: >>> https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow >>> Why not improve on what is there? >> >>> I think it is great you want to tackle and clarify these things. Having >>> gone through a round myself with this process I guess I learned that >>> some ambiguity wasn't as harmful as I first thought. :) >> >> You're right, of course. Somehow I'd forgotten about that flow. >> >> So, I will revise the draft substantially. :) Here's my quick thoughts: >> >> The obvious bit of hand-waviness in the graphic is the resolutions, we >> don't define them (and it doesn't list some at all). DUPLICATE is >> simple, and ERRATA and RAWHIDE are known: fixed bugs in official >> releases are closed as ERRATA (should be done automatically), and fixed >> bugs in Rawhide are closed as RAWHIDE (manually). Those we can write >> down into that page without any discussion, I think. >> >> We do, however, need to define what 'cantfix', 'wontfix', 'notabug', >> and 'worksforme' are for. We should also explicitly state which >> resolutions aren't used for Fedora (I think 'deferred', 'currentrelease' >> and 'nextrelease' fit into this category) so they don't get used on >> Fedora bugs by mistake. > > Yes, I agree these were never clearly defined on the wiki page and I > can't remember why, though even now I'm wondering how important it is > that we use the right reason and what we would use it for. > >> It would really be nice, in fact, if we could have Bugzilla only show >> the statuses and resolutions appropriate to the product the bug is filed >> on...not sure if that's possible, though. > > I can ask the Red Hat bugzilla team about this. > > John > > > In your schema for close, there is no indication that there should be or there is one more step, which is the return to originator (and perhaps others), with a notification that the bug is fixed, and ready for testing. The end user is required to keep tabs for as long as the bug is open. Would like email stating bug has been repaired, (if an advice has an email address). ------------------ Regards Leslie Leslie Satenstein 5752 Avenue Lockwood. Cote St. Luc Montreal Quebec H4W 1Y9 Canada voice: 514-369-1685 mailto:lsatenstein@xxxxxxxxx |
-- fedora-test-list mailing list fedora-test-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list
