Master aka 4.7 open for new features to be merged!

[Remi Bergsma <RB...@schubergphilis.com>]

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