Hi Guys, Gave this thread a read - sorry i'm a bit late on this topic.
I agree with what Will, John and Rohit proposed. I also understand Rajani's hesitancy - we dont want master to become a zoo. In summary, i think the proposed workflow should avoid the zoo case and give us structure that will yield some stability. * 1 PR * 1 Test (at a minimum) - be it Blue Orangutan, Bubble, Marvin, screenshot - when tests dont apply, etc.. * 2 LGTMs -> then merge This should be a decent gating framework to avoid not well tested commits. We just need a a consistent way of determining which tests should be ran. Regards ilya On 8/4/16 10:19 AM, Will Stevens wrote: > 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 >> >> >
