The request is summarized @ [1] and [2] The needs are: a) Create a branch at the current release-3.8 named release-3.8-fb b) Add gerrit User ID 1000583 (Shreyas), and "Richard Wareing <rwareing>" (I do not have the User ID for this account yet) to have merge rights on the branch if possible, and also if not possible, add them to the maintainers group, so that they get the merge rights as needed to maintain this branch. There is one other person to be granted merge rights, but I am unsure if I have his github ID (kvigor) [1] http://www.gluster.org/pipermail/gluster-infra/2016-November/002978.html [2] http://www.gluster.org/pipermail/maintainers/2016-November/001664.html
I think I've got this setup correctly. Could you have them check if all is well with regards to permissions? The branch is release-3.8-fb
We have confirmation from some of them, and it is working as needed. Keeping this open possibly for one more week so that I can ack for all concerned.
FB has now merged 2 patches, so things look good for users kvigor and Shreyas Siravara <shreyas.siravara>. There has been one more request from FB regarding the regression triggers for this branch as follows, let me know if you need a separate bug filed for tracking this request/change. Regression run trigger changes requested on release-3.8-fb branch: FB would ideally want a continuous integration run on this branch, so that they can keep merging and look back to correct things as the continuous integration reports failure at some point. This to my knowledge requires dedicated machines etc. and also is not what our systems are geared up to do. Hence, requesting if we can possibly satisfy some of the following requests, we will let you know what is preferred once we present the possibility to the FB team (IOW, I need to understand the possibility first and then get an ack from FB if it suits them before implementing the same). 1) Ability to submit without running regressions Can a patch not wait for Verified +1 and also not wait for the regression score, but still be merged. 2) Ability to run regression on some patches, if Verified +1 is marked For some patches, FB folks would like the regression runs, so we need a way by which they can trigger the same (hence trigger on Verified +1 as the request). 3) Worst case if (1) and (2) are not possible, can we turn off regression runs for this branch only?
@nigelb, so in discussions with the facebook engineers, it was decided that we can go ahead with the following (as per our conversation that CI was possible). a) Enable CI on the fb branch - So this sort of runs back to back, and reports run details somewhere. We possibly need to know where and how, so that facebook folks can track and take action as needed b) Disable per commit regression, smoke runs for this branch. IOW, merge requires +2 CR and +1 Verified, no voting from the regression runs. I have added Shreyas to this bug, for any further conversation in this regard.
For a) I assume we want both netbsd and centos runs? For b) I think having Smoke test is useful. It'll ensure that you don't land bustage on top of bustage, especially compilation failures. Shreyas and Shyam, let me know what you think?
I've disabled regression check for the fb branches. Shreyas. If you do a recheck centos or recheck netbsd, you should get a green almost instantly now. I haven't yet started running a reasonably regular job that checks for regressions passing across on the branch, but I'll set one up shortly.
Thanks Nigel, this is a good setup for us.