Hey folks,
Since Daan volunteered me to do some docs, I’ve updated Rohit’s page at
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git
with additional details.
I went back through all the e-mails on the subject to find questions/concerns,
addressed the ones I think have consensus and highlighted a few places where
additional decision/discussion may be needed.
Remaining topics I’m not sure about:
* when to cut over
* how to cut over
* policy for who merges to release branches
* policy for adding features in micro releases
* what to name hot fixes
Comments on each below.
When to cut over
----------------
I think docs are quite sufficient now. I’d personally suggest to just do it.
Since the vote is done I think any committer should feel free to pick up the
ball :)
How to cut over
---------------
* Someone has to make the branches and announce the flip on the mailing list.
* Everyone has to flip / git flow init / etc.
* Someone has to update jenkins.buildacloud.org to build the new develop branch.
* ???
* Profit.
Again, I’d personally suggest to just do it.
Policy for who merges to release branches
-----------------------------------------
There was some unresolved discussion about
1. when it is ok to directly commit to the release branch
2. when it is ok for other people than the release manager to merge to the
release branch
3. when/how to do a freeze of a release branch
Git flow says:
1. basically never
2. what’s a release manager?
3. never, cut release branch == feature freeze, tag release == freeze
Personally I would suggest
1. never unless you are doing release management (i.e. version bump) commits
2. always as long as you are confident and prepared to suffer the wrath of
doing it wrong, ask the release manager to do it if you are not confident
3. at the jurisdiction of the release manager
Policy for adding features onto release branches
------------------------------------------------
It has been cloudstack practice to include new features (or enable features) in
micro releases.
I did document how to do this within the git-flow model, but I strongly suggest
to simply stop doing it.
I suggest the policy is that this can be done as an exception to the rule after
discussion on the mailing list, using lazy consensus, with the release manager
doing the merge to the release branch.
what to name hotfixes
---------------------
hotfix/<jira-ticket>
the -<summary> should be descriptive and is optional.
hotfix/4.4-<jira-ticket>
for fixes to 4.4.x.
cheers,
Leo
