[Gluster-devel] Mass correction of NEW and ASSIGNED bugs and how these states should be used

Niels de Vos ndevos at redhat.com
Tue Sep 30 14:36:32 UTC 2014

Hi all,

in todays Bug Triage meeting we discussed about correcting the status of
old bugs. There were several bugs assigned to non-developers who will
not write any fixes. Also, quite some bugs were in the NEW state, but
would be assigned to a (non-)developer. These states were confusing and
do not set any clear expectations for the bug reporter or anyone
following the bug.

These bugs have now been updated and corrected. A bug should walk
through the following initial stages:

1. a Bug gets reported
   - the Bug is in status NEW
   - the Bug is assigned to gluster-bugs at redhat.com [1]
2. the NEW Bug gets Triageda [2]
   - clear problem description, summary, details, etc are listed
   - correct component is selected
   - the 'Triaged' keyword is set
3. developers pick a Triaged Bug to work on
   - assign the bug to themselves
   - change the status to ASSIGNED

More details can be found in the Bug Triage Guidelines [2] and the Bug
report Life Cycle [3].

And, for anyone who wants to help out with Bug Triage (each one
counts!), here is a link with bugs that need triaging:
- http://goo.gl/hlcZFO

Do let us know if there are any questions about this process or the
state of the certain bugs. We're reachable by email or on Freenode IRC
in #gluster and #gluster-dev.


[1] until the bugs at gluster.org becomes the default assignee
[2] http://www.gluster.org/community/documentation/index.php/Bug_triage
[3] http://www.gluster.org/community/documentation/index.php/Bug_report_life_cycle

More information about the Gluster-devel mailing list