This mail [1] and this text [2] details the new workflow that we intend to use, which is closing out of bugzilla and moving to github issues, for all feature and bug tracking needs. This bug is filed based on my understanding of things that need to change in the infrastructure (i.e scripts etc. not additional infrastructure requirements). We may need multiple people changing te various things mentioned here, in which case we can use this as the tracker bug for all changes. [1] Mail regarding movement to github: http://lists.gluster.org/pipermail/maintainers/2017-February/002195.html [2] Text detailing the github workflow: http://bit.ly/2kIoFJf Changes needed: A) rfc.sh needs: - https://github.com/gluster/glusterfs/blob/master/rfc.sh - Prompt for issue # - Prompt for Fixes or Updates for the issue - Modify commit with the details as needed B) Jenkins needs: Bug version and branch: https://github.com/gluster/glusterfs-patch-acceptance-tests/blob/master/compare-bug-version-and-git-branch.sh - This should now check and see if the issue mentioned has the label "RequiredIn: X.Y", when a commit for that branch is made. - If the commit is against master, this should also check if the issue is still open C) WorkerAnt needs: 1) patchset-created - https://github.com/gluster/gerrit-hooks/blob/master/patchset-created - Update all issues that are mentioned with the details of the patchset - Update asignee for the issues mentioned as well, based on the committer 2) patchset-merged - https://github.com/gluster/gerrit-hooks/blob/master/change-merged - Issues will get auto updated about the patchset (this is part of what github does anyway), and even closed if there is a mention of "Fixes" - We additionally need to do some label movement as follows, for all issues referenced with "Fixes" in the message (i.e issues that would get closed with this commit) - Remove: RequiredIn: X.Y (for non-master branches ONLY) - Add: Commited in: X.Y - Gets added for master as well
So 1) why is the mail sent to maintainers list, which is: " is intended to be a low-volume list and should only be used for discussions that are not appropriate/useful for the rest of the developers." . Moving the BTS is a discussion that do concern others developers. I do not think we should make any change until that discussion on -devel do happen. 2) the document listed has a bit too much "TODO" before doing any move. I would like to see them addressed. 3) one of the main reason to avoid github in other projects is the lack of private bugs and its impact on security. It is not mentioned at all right now, so I would like to at least know if it was discussed. Saying "we do not plan to have embargo" is fine by me, but I would like to make sure to have a explicit signoff by people and warn RH security team of that. Currently, I think gerrit do not have ACL, neither do jenkins so we can't do much, but having it explictely listed as a non goal would permit to later avoid setting it. 4) another huge reason to avoid github is that automation tend to be annoying. Ansible project do hit quite easily the various limit of the API. So I would like to make sure someone will be dedicated to any required automation before we embark to the move or anything. 5) gluster downstream may have automation that depend on the bug tracker. Did we contact them in advance, and if so, who did and when ?
(In reply to Michael Scherer from comment #1) > So 1) why is the mail sent to maintainers list, which is: " is intended to > be a low-volume list and should only be used for discussions that are not > appropriate/useful for the rest of the developers." . That was to gauge if we can even do this, and we have some semblance of a plan, before going to devel. > > > Moving the BTS is a discussion that do concern others developers. I do not > think we should make any change until that discussion on -devel do happen. Agreed. We will not make the change before we reach out to dev list, this bug is more preparing for the change. > > 2) the document listed has a bit too much "TODO" before doing any move. I > would like to see them addressed. Yes, we are working through that. > > > 3) one of the main reason to avoid github in other projects is the lack of > private bugs and its impact on security. > > It is not mentioned at all right now, so I would like to at least know if it > was discussed. Saying "we do not plan to have embargo" is fine by me, but I > would like to make sure to have a explicit signoff by people and warn RH > security team of that. Currently, I think gerrit do not have ACL, neither do > jenkins so we can't do much, but having it explictely listed as a non goal > would permit to later avoid setting it. - Security: This was raised by Amye as well, and we are *now* considering it - I did not understand the gerrit and Jenkins not having ACL part, how/what does that mean? - Yes, over other conversations it looks like we need to reach and get signoff before we go live with this thing (if that happens), from other RH stakeholders as well. This will be done as we solidify this plan. > > 4) another huge reason to avoid github is that automation tend to be > annoying. Ansible project do hit quite easily the various limit of the API. > So I would like to make sure someone will be dedicated to any required > automation before we embark to the move or anything. Hmmm... can we get more specifics about the problems? So that we can evaluate the same. Also, a person dedicated to the automation needs work! > > 5) gluster downstream may have automation that depend on the bug tracker. > Did we contact them in advance, and if so, who did and when ? I will reach out to Rejy downstream to get these parts moving, if maintainers come to a consensus. So we need a few ACKs and sign-offs before we go live on this, and I agree, thanks for raising those flags. Would it be possible to prototype some changes in gerrit-stage (like the hooks for example?) so that when devs experience this, it is well known what needs to be done in the future and we can get better feedback on this.
> That was to gauge if we can even do this, and we have some semblance of a > plan, before going to devel. Ok, that's fair. But the communication did look a bit more "we are gonna do that, here is the plan", due to the presence of a actual planning. It is good to have one, but this tend to make people thing a different things than a discussion :) I still think this should start on -devel, but I can see how people prefer to start small, I did in the past too (and got burned for that). > - I did not understand the gerrit and Jenkins not having ACL part, how/what > does that mean? So my point is that having private bugs is useless if the CI is public, and if gerrit is public, as they are part of the workflow for fixing security bugs. Afaik, both are public (but I can be wrong). I do not know what is the workflow for fixing bugs. Are they discussed out of gerrit, tested out of jenkins, etc ? Maybe we didn't got enough to have a process and maybe that's the time. If we decide that privates bugs are a thing we need and/or use, then we have to make sure the whole workflow is as private as the bug. If we decide that we are not gonna do embargos (which is reasonable, since RH Security Team think they should be exceptional), then the requirement for private bugs disappear. But again, I want to make sure we are clear on that, and clear with people handling bugs. > Hmmm... can we get more specifics about the problems? So that we can evaluate > the same. Also, a person dedicated to the automation needs work! So the issue they had had mostly with the API limit. Ansible seems to have a rather huge volume of requests, and github do limit them. Github issues do not scale well for a big project, either from a ressources point of view (cf limit on API) and from a design/UX point of view (ie, bugzilla is slightly more advanced). So people tend to automate lots of things there. The bot also do automated triaging (ie, adding various labels) for queries. So it has to go over all issues, etc, etc. I do not say this is not doable, but we have to take that in account. jctanner is the guy in charge of that, he can tell more. > Would it be possible to prototype some changes in gerrit-stage (like the > hooks for example?) so that when devs experience this, it is well known what > needs to be done in the future and we can get better feedback on this. Mhh I guess it is up to nigel to decide if he use it or not. We still can't give a test instance of gerrit easily and we are working on pushing that to ansible. So I would prefer we finish that, so we can scrap and reinstall if needed. But if nigel is ok, I do not have strong objection to that.
Putting this on Ice till we reach consensus and answer a series of questions posted on the maintainers list [1] Marking this as NEEDINFO from me till then. [1] http://lists.gluster.org/pipermail/maintainers/2017-February/002262.html
Going to close this bug as it doesn't have any action for the infra team. In the event we want to revive this discussion, please re-open the bug.