cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Will Stevens <wstev...@cloudops.com>
Subject Re: 4.10.0 release
Date Thu, 04 Aug 2016 17:19:00 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message