Gluster intends to move to github to track features being delivered against the code base. Read the announcement here: http://lists.gluster.org/pipermail/gluster-devel/2017-February/052203.html Specifics of the github process here: https://hackmd.io/s/BkgH8sdtg# Towards the above the following change is requested: ---------------------------------------------------- Update WorkerAnt to post to a github issue as soon as a patch is posted against the same Detect patch posted against an issue using the "{Fixes|Updates} #n" or "{Fixes|Updates} gluster/glusterfs#n" in the commit message Change: https://github.com/gluster/gerrit-hooks/blob/master/patchset-created to update the issue to reflect that a patch is posted against it (just like bugzilla is updated by WorkerAnt) This is required, so that we do not have to wait till a merge of the commit, for the details to appear against the issue This needs to change to pick up commits posted against glusterfs, glusterfs-specs, as these are controlled via gerrit For glusterdocs however, only when the documentation PR is submitted and accepted, will the issue be updated (which is fine) WorkerAnt is used to state what should change, but this request may need another bot or some other means of achieving the same. Hence, do not consider WorkerAnt as the final entity that needs to change.
glusterfs/glusterfs-specs are the only repos that will have any work done. The problem here is to remove duplication. We currently push to bugzilla every time a patchset is created. For a large change, there may be multiple pushes that will create noise if we add comment on every patchset. This needs to be fixed for Bugzilla *as well*. Once that's sorted, we'll make the change for Github. Does this sound acceptable? glusterdocs is handled entirely in Github. If you mention an issue in the pull request, it will do the linking already.
Because we now get into a mix of numbers pointing to either Bugzilla or GitHub, I suggest to have the "BUG: 012345" replaced by URLs. The same approach needs to be done for GitHub issues. For someone reading the commit messages, a single well known source for bug reports and RFEs is easy, when we have two it will become confusing for many. If replacing the "BUG: .." is tricky, it may be easier to add a "Reported-on: https://bugzilla.redhat.com/1428032" and "Reported-on: https://github.com/....". matching the existing scheme for "Reviewed-on:".
Sorry, that last comment was meant to be posted in bug 1428034.
(In reply to Nigel Babu from comment #1) > glusterfs/glusterfs-specs are the only repos that will have any work done. Yes, agreed, glusterdocs is not via gerrit, and github will take care of the mention for us. > The problem here is to remove duplication. We currently push to bugzilla > every time a patchset is created. For features there will be no bug in the commit message, it will be of the rfc type, so if I read your comment here right, WorkerAnt will automagically hence post to Bugzilla or to github only and not to both, right? So the duplication problem does not exist? (or are you referring to the duplication issue as discussed in the next para by you, in which case, disregard this comment) > > For a large change, there may be multiple pushes that will create noise if > we add comment on every patchset. This needs to be fixed for Bugzilla *as > well*. Once that's sorted, we'll make the change for Github. Sigh! yes this is true and to some extent I agree that it is noise as well (hence the sigh). At the same time this repetitive posting also (sometimes) helps (maybe), that there is a new change that you may want to look at when following the bug (or in this case the issue). > > Does this sound acceptable? I would like to treat the noise and posting to github issues separately, as I would like the github issue posting to appear sooner, but that assumes I know how much effort it would take to do both. Does this answer your question on acceptability. I will also send in a mail with the various requests that have been made of the infra team with some form of priority to them, just so we are on the same page. (apologies if this is causing confusion at present) > > glusterdocs is handled entirely in Github. If you mention an issue in the > pull request, it will do the linking already. Yes, agreed.
This merged and in production: https://github.com/gluster/glusterfs-patch-acceptance-tests/commit/1119585b253a5c40e0961bc96892ffab5c87c8f9