Yes, I agree with this. CVEs need to be handled in security@ and will be added to the branches manually once they have been agreed upon there, so no PRs are needed for them.
I also agree that exceptions can be made for version changes in POMs and such because those are scripted changes which are part of the release process. We may want to update the Release Procedure documentation to include some details around the commits which Rohit made (which I highlighted earlier) as those probably fall into this type of situation as well. Not sure those can be scripted as part of cutting a release, but they are related to the release process, so detailed instructions for making those changes would be helpful to include. In general, yes, your statements are all correct. We may want to send out a bit of a notice on the dev@ list to highlight this. For the last little while we have been having the RMs handle all of the merging of code, so we may want to officially inform the dev community that if you have commit access you can commit, but you need to follow these guidelines [1]. I would even go so far as to give a summary of the process. *Example:* Create a GH PR with the change and get 2 LGTM (including proof of tests passing). Once a PR is ready, commit it with the following flow. Let's assume the change is for 4.8 and needs to be forward merged. $ git fetch origin $ git checkout 4.8 $ git rebase origin 4.8 $ git pr <pr_number> $ git log -p $ git push origin 4.8 $ git checkout 4.9 $ git rebase origin 4.9 $ git fwd-merge 4.8 $ git log -p $ git push origin 4.9 $ git checkout master $ git rebase origin master $ git fwd-merge 4.9 $ git log -p $ git push origin master You can decipher this workflow from the Release Principles [1] document, but it is not nearly this clear. I suggest we make this process more obvious so everyone knows what they are doing if they mae commits... [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Thu, Aug 4, 2016 at 12:17 PM, John Burwell <john.burw...@shapeblue.com> wrote: > Will, > > My understanding of the release principles is that all changes must have a > PR with the exception of CVE fixes. Since we must accept CVE fixes in > private, the 2 LGTM rule is applied on the security@ mailing list and on > private JIRA security ticket. I would also say that the release commits > (e.g. tags, change of Maven versions in the POMs, etc) could also be > granted an exception to the rule. Otherwise, yes, my understanding is that > everything else requires a PR. Do you agree with that interpretation? > > Thanks, > -John > > P.S. I plan to consolidate the release section of the wiki shortly as we > have a number of topics that ostensibly conflict with each other. > > > > john.burw...@shapeblue.com > www.shapeblue.com > 53 Chandos Place, Covent Garden, London VA WC2N 4HSUK > @shapeblue > > > > On Aug 4, 2016, at 12:02 PM, Will Stevens <wstev...@cloudops.com> wrote: > > > >> john.burw...@shapeblue.com > >
