cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From ilya <ilya.mailing.li...@gmail.com>
Subject Re: 4.10.0 release
Date Tue, 09 Aug 2016 02:11:33 GMT
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.burwell@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.burwell@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 <wstevens@cloudops.com> wrote:
>>>
>>>> john.burwell@shapeblue.com
>>
>>
> 

Mime
View raw message