[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Draft for 'Bugzilla processes and procedures' mail to developers

----- Original Message -----
From: "John Poelstra" <poelstra redhat com>
To: "For testers of Fedora Core development releases" <fedora-test-list redhat com>
Sent: Thursday, April 02, 2009 8:00 PM
Subject: Re: Draft for 'Bugzilla processes and procedures' mail to developers

> Adam Williamson said the following on 04/02/2009 01:29 PM Pacific Time:
>> 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).



Leslie Satenstein
5752 Avenue Lockwood.
Cote St. Luc Montreal Quebec H4W 1Y9  Canada
voice:  514-369-1685   

mailto:lsatenstein yahoo com

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]