|| ||"Jon Stanley" <jonstanley-AT-gmail.com>|
|| ||Fedora bug workflow - process change|
|| ||Mon, 25 Feb 2008 15:05:36 -0500|
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
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
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
Fedora-devel-announce mailing list
fedora-devel-list mailing list
to post comments)