Hi,
[sorry for the long email, I hope *you* will read it never the less]
we are now getting much better at triaging bugs that users report in
bugzilla. During the weekly bug triage meetings [1] we catch the bugs
that have not been triaged yet.
Developers and Quality Assurance Engineers who are not familiar with the
Bug Triage Guidelines, should read through them [2] as it is part of the
workflow for reporting and getting bugs fixed.
Bug triage is the first step after a user reported a bug. The second step
is getting the actual development done to post a patch. There is
currently a very loose way of getting bugs assigned to developers. This
mainly relies on the maintainers of different components.
Any (starting) developer should be able to check for bugs that have been
triaged. Those bugs should contain the needed information so that
developing a fix is all the developer needs to care about. The
description of the bug should be clear, and the supporting data should
be available. The triaging focusses on preventing developers to guess
about the reported issues, and developers should not need to go
back-and-forth about getting the logs or other data from the user.
Developers are encouraged to not rely on component/subsystem maintainers
and check for NEW and Triaged bugs regularly. There are several ways of
doing this. Basically, any Bug in status=NEW and with keyword=Triaged
should be ready to get worked on. The most complete Bugzilla query looks
like this:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=Triagedkeywords_type=anywordsproduct=GlusterFS
Currently, this lists 213 bugs, for different versions and components.
It is likely that some bugs already have patches posted, and maybe
merged. Those bugs should be moved to status=POST or status=MODIFIED.
It is also possible to filter those 213 bugs in component. For example,
if I would be interested in only NFS bugs, I would add the following bit
to the URL:
component=nfs
Which results in this:
https://bugzilla.redhat.com/buglist.cgi?bug_status=NEWkeywords=Triagedkeywords_type=anywordsproduct=GlusterFScomponent=nfs
Adding multiple components is an option too, say bugs for nfs+build:
component=nfscomponent=build
You can use any component that is available under the GlusterFS product,
like the list of components while you report a bug [3].
Some people might prefer to add this list of bugs to their RSS reader.
This is as easy as copy/pasting the 'Feed' link on the bottom of each
Bugzilla list/query.
After a developer decided to start working on a bug, the status of that
bug should be changed to ASSIGNED and the Assignee should be set to the
developer that will do the work.
Once a patch is ready and has been posted for review in Gerrit, the
status of the bug should be set to POST (once all planned patches have
been posted, in case of a series).
In case there are any questions, please let me know by responding to this
email. When you are trying to construct a certain bugzilla query and
have difficulties, I can try to help out. I appreciate it if the list
can be kept on CC, others likely have similar comments/questions and
will enjoy the conversation.
Thanks,
Niels
[1] http://www.gluster.org/pipermail/gluster-devel/2015-March/044113.html
[2] http://www.gluster.org/community/documentation/index.php/Bug_triage
[3] https://bugzilla.redhat.com/enter_bug.cgi?product=GlusterFS
___
Gluster-devel mailing list
Gluster-devel@gluster.org
http://www.gluster.org/mailman/listinfo/gluster-devel
