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

Re: Fedora bug workflow - process change

Jóhann B. Guðmundsson pisze:
Nils Philippsen wrote:
On Mon, 2008-02-25 at 15:05 -0500, Jon Stanley wrote:
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.

IMO this is bad, as we don't differentiate between "this is a bug" and
"someone is actually working on it" then; ASSIGNED should mean what it
says, that a bug is assigned to a person or group of persons to work on
+1 Aggreed..
Perhaps another state (TRIAGED, VERIFIED?) should be
introduced/re-used for that.

I suggest Confirmed ( as in confirmed as a bug ) then moved to Assign.

If there is no response from upstream in ( let's say week/2 weeks/ a
month ) given time.
( Some thing that gives something back to the bug reporter on the status
of the bug
EVEN if it is just working on or still working on it ) .
That component will be marked "upstream dead" and removed from bz due to
no responce
and removed from next release of Fedora..

Best regards.
Johann B.

I can only confirm that some bug trackers have UNCONFIRMED/NEW and CONFIRMED/VERIFIED.

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