Fedora bug workflow - process change

[Jon Stanley]

As many of you know, I have been working on relaunching a triage team
 within Fedora, which is coming Real Soon Now(TM). Part of the effort
 is streamlining the current Bugzilla workflow (or lack thereof). These
 workflow guidelines were approved at the FESCo meeting on January 24,
 2008. Note the use of the word guidelines, these aren't hard and fast
 rules that we are imposing on people. If you have a good reason to
 break them, feel free - but this is the mantra that the triage team
 will be going by.

 When a reporter enters a bug, the report automatically starts out in a
 NEW state. The triage team will be primarily looking at bugs in this
 state. From this state, the triage team can either change the status
 to ASSIGNED (which indicates that the bug is well defined and
 triaged), or use the NEEDINFO state to request additional information
 from the reporter, or close the bug (either as a duplicate of an
 existing one, or using other closure reasons - CANTFIX for problems
 with proprietary drivers or kernels that have such drivers loaded, for
 example).

 The ASSIGNED state is a state that has a new meaning - it used to mean
 that the bug was actually assigned to a person. Instead, it now means
 that the bug is capable of being worked on by a maintainer - i.e. the
 triage team believes that this is a complete, actionable bug - i.e.
 with a stack trace for a crasher, various log files for other
 components, complete AVC message for SELinux stuff, etc.

 When a maintainer has a fix for a bug checked into CVS, they should
 move the state of the bug to MODIFIED. This is an indication that the
 fix is indeed in CVS, and has likely had a build submitted against it.
 You may want to (though it's certainly not required) post a link to
 the koji build so that the adventuresome tester can go grab a copy and
 verify the fix.

 Once a maintainer submits an update via bodhi against a particular
 bug, and the update hits updates-testing, the state of the bug will
 transition via bodhi to ON_QA. This is a indication to the reporter of
 the bug that there is a fix for the bug available, and that they
 should test the package that's in updates-testing, and report on it
 via bodhi and/or as a comment in the Bugzilla. The comment used by
 bodhi is now more verbose as to how to give feedback via bodhi.

 The final change is that NEEDINFO bugs are eligible to be closed by
 the triage team (after review that the information has not been
 provided, that it's not the maintainer that the NEEDINFO is requested
 of, etc) after 30 days of inactivity. A stock message will be provided
 to triagers (yet to be written) with which to close these bugs.

For further information, please see
http://fedoraproject.org/wiki/BugZappers.  Contact information can be
found at the "Getting Involved" section for further discussion or
help, which is always welcome.  The workflow (complete with diagram)
can be found at
http://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow

 Sorry for such a long e-mail, I just wanted to make certain that
 everyone was informed of these changes and an impending launch of the
 BugZappers!

_______________________________________________
Fedora-devel-announce mailing list
Fedora-devel-announce at redhat.com
https://www.redhat.com/mailman/listinfo/fedora-devel-announce