We already agreed contributions should always go via a PR and require two LGTM’s before we merge. This is the next step: How we should do release management for 4.6 and on.
Contents:
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).
*Coverage may go down if code that was covered is deleted
The release process would work like this (x=major, y=minor):
Important
Starting in 4.6, we no longer use cherry-picking to get commits from master to release branches.
Instead, we merge a PR to a release branch, then merge it forward to the next release and finally master. See image for example.
The biggest discussion we had when writing up these principles, was the choice between either:
The benefit of 1) is that we know everything will be in master. The downside is that cherry-picking changes the commit hashes which makes it hard to find in which releases a given commit is.
The big benefit of 2) is that when we merge a pull request to the oldest release and merge it forward, the commit hashes stay the same all the time. We also automatically make sure that bugs are fixes in supported releases.
As a bonus of 2), when we work like this, GitHub will much better detect we merged certain pull requests that now stay "open", even when we write "This closes #1234.
That's why we decided to go for option number 2.
Git commands:
# Get the exact same commits from the pull-request (the commit hashes must not change) git fetch origin pull/${prId}/head:pr/${prId} # Commit it without fast-forwarding. Type the commit message as detailed below. git merge --no-ff --log pr/${prId} # Finally, sign the merge commit. git commit --amend -s --allow-empty-message -m ''
An optional helper script with detailed usage and help can be found here.
# Make sure you're on the branch you want to merge into git checkout ${branch} # Merge to the next branch and type the commit message as described below. git merge --no-ff --log ${branch_to_merge}
An optional helper script with detailed usage and help can be found here.
The commit message for a merging a pull request, should look like this:
Merge pull request #{pr number} from @ {user name of pr author}
* pr/{pr number}: {list of commit messages} Signed-off-by: {name and email of ACS committer that merges the pr}
It is important the pull request is merged to the branch. This script will help you do that (it will be added to the CloudStack repository).
Usage:
./merge-pr.sh 1234
Detailed usage and help can be found here.
The commit message for forward merging, should look like this:
Merge fix release {source branch} to {current branch} * {source branch}: {list of commit messages}
It is important the pull request is forward merged to the next branch. This script will help you do that (it will be added to the CloudStack repository).
Usage:
./forward-merge.sh some-branch
Detailed usage and help can be found here.
Important
We should all use the same tools to merge pull requests and do forward merges!
When using these tools and this way of working on Apache CloudStack keep in mind that you work with two origins:
If you merge on a clone of one of them while it is behind on the other (or with its origin) you are merging on a commit that is no longer a HEAD. You will get an error when you push due to conflicts. At this point it is safest to throw away your merge, update (git fetch) you local clones and merge the PR again.
Based on these principles, Rajani Karuturi and Remi Bergsma volunteered to be the Release Managers of Apache CloudStack 4.6.
This is the original diagram of the release process that was included on which we started the DISCUSS (added for archiving purposes)
Thanks to Rajani Karuturi, Daan, Miguel Ferreira, Wilder Rodrigues and all others for working on this with me (Remi Bergsma).