[Gluster-devel] Update on Process Automation initiatives

[Amar Tumballi]

Hi all,

As a step towards achieving our promise on Goals for the year 2018 [1], we
have taken up automating some of the work flow of glusterfs development
cycle.

Below is the update on one such effort.

----

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
<https://docs.google.com/document/d/1AFkZmRRDXRxs21GnGauieIyiIiRZ-nTEW8CPi7Gbp3g/edit?usp=sharing>
.
<https://hackmd.io/os2Kmd6iTpuG4hO6Qcvc2A?both#How-is-bugzilla-and-github-used-right-now>How
is bugzilla and github used right now?

Today, GlusterFS project uses bugzilla <https://bugzilla.redhat.com/> for
tracking the bugs, and github <https://github.com/gluster/glusterfs/issues> 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.
<https://hackmd.io/os2Kmd6iTpuG4hO6Qcvc2A?both#What-are-we-changing>What
are we changing?

We are proposing the similar tags used in github issues
<https://help.github.com/articles/closing-issues-using-keywords/> 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 <https://review.gluster.org/19564>
, build-jobs <https://review.gluster.org/19565> and
glusterfs-patch-acceptance-tests
<https://github.com/gluster/glusterfs-patch-acceptance-tests/pull/121>
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.
----

[1] -
http://lists.gluster.org/pipermail/gluster-devel/2018-January/054122.html

Regards,
Amar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20180312/e39aa27a/attachment.html>