This work intends to make the development process more efficient by automating aspects of the Red Hat Bugzilla workflow.
This is part of the ongoing process improvements that were discussed in the maintainers meeting and are recorded here.
How is bugzilla and github used right now?
Today, GlusterFS project uses bugzilla for tracking the bugs, and github for tracking feature requests.
At present, the workflow of a bug involves a large degree of manual intervention. The lifecycle of bugzilla is something like below:
- Anyone can file a bug, and it starts its life at status ‘NEW’
- When a developer starts working on it, {s,}he changes it to ‘ASSIGNED’.
- When the patch is posted to review, the bug should be moved to ‘POST’ state.
- When the final patch (a bug can have more than 1 patch required to fix it) is merged, the bug status should be changed to ‘MODIFIED’.
- When the release happens, the bugs should be closed with ‘CLOSED’ ‘CURRENTRELEASE’ with a comment saying which release has the fix.
Today, other than the last step, other things are manual, and hence a high chance of missing proper updates on bugzilla. This also causes problems when a user files a bug, and it is not updated at all for long time, but the fixes are present in release, because someone has already worked on it.
What are we changing?
We are proposing the similar tags used in github issues for handling the bugs automatically. In ./rfc.sh we will ask one more question, if the patch is the final patchset in the series, and it will use fixes: or updates: appropriately.
For those using other forms of code submission than rfc.sh, the tags to add in the commit message are,
- <fixes/updates>: #<num>
- If you are referencing a github issue, from another repository use, <fixes/updates>: gluster/glusterfs#<num>, IOW <fixes/updates>: <repo-location in github>#<num>
Considering the gluster specific bugzilla started around 743000 number, around October 11th, 2011, we will treat any number below 743000 as github issue for now.
While github issues would take significant time to reach upto 743000 number, we think this model would be simple and straight forward to implement, and also to understand for users/developers.
This change involves changes in glusterfs, build-jobs and glusterfs-patch-acceptance-tests repositories. Appreciate reviews and comments on these changes.
ETA for this changes to be in action are March 31st, 2018. So, please voice your concerns soon, if any. If the points you have against these changes are agreed upon, we are happy to revert too, so, regardless of dates, do let us know what your opinions are.
----_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
