cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remi Bergsma <RBerg...@schubergphilis.com>
Subject Master aka 4.7 open for new features to be merged!
Date Tue, 17 Nov 2015 08:46:16 GMT
Hi all,

TL;DR: Features that are have a code review AND integration tests executed against them (resulting
in 2x LGTM) can now be merged to master (note “merged”, NO direct commits). Please read
[1]. I think it is wise to have one of the RMs do the merge. The window for new features is
about 2 weeks, after which we will start releasing again. Bug fixes should go to 4.6 branch
instead of master (will be merged to master once in 4.6).


Details:
Master has been prepared and is now on 4.7.0-SNAPSHOT. We also prepared the 4.6 release branch
and did the first forward merge (thanks Rajani!). That PR I just merged (1071). We can now
merge the features that will become 4.7.0.

Dates:
Mon Dec  7: 4.7.0 Feature freeze
(Let’s plan some QA Days around Dec 7-14)
Mon Dec 14: 4.7.0 RC1
Aiming for a release before this Christmas.

About the Release Process:

Goal written in “Scrum”-style story:
As a RM I want master to be stable at all times
so that I can create release candidates of high quality
that require little QA and can thus be released fast and often.

Master needs to be stable at all times
Stable master means all code can be cleanly compiled, all automated tests are passing (giving
enough room for exceptions when automated test are flakey), and test coverage does not go
down (otherwise that would render the automated testing less useful every time).
* Pull requests will be merged after 2x LGT,  no –1 and comments addressed
* When a release is being prepared, master will be “frozen” for new features (we aim to
keep this window as short as possible)
* Release branch will be branched off of master as soon as a release candidate (RC) vote passes
(no more QA on release branches before release)
* Bug fixes should be fixed on a release branch first, then merged forward to the next release
(if any) and finally to master.
  Important: The commit hashes from the Pull Request should stil be the same in all branches
this commit is in (cherry-picking cannot do this).
* Only bug fixes will be fixed in release branches, there will be no back porting of new features
* We should all use the same scripts to merge pull requests and do forward merges. The tools
are located in the CloudStack repository (/tools/git).

About LGTM:
LGTM, "Looks Good To Me" is given once a reviewer of a Pull Requests gives an OK to proceed.
* At least one of the reviews needs to run the Marvin integration tests and post output of
a successful run. This is to prevent regression. Another review can then focus on the code
itself, for example.
* Should running the Marvin tests make no sense (for example when the Pull Request only changes
the UI), the reviewer should post other "proof" that it worked for him, like a screenshot
* Any LGTM without details on what the reviewer did, will not be considered in the LGTM count
* Before merging, any open questions and comments should be addressed
* Pull Requests that fail the above requirements and are merged anyway, will be reverted

Please read [1] for full process.

Let’s make another great release, soon! :-)

Regards,
Remi


[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+for+Apache+CloudStack+4.6+and+up

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message