Daan, I think we should do the branch related changes[1] and make the switch. Are we waiting for a RM for 4.5?
[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-Movetogit-flow ~Rajani On 05-Aug-2014, at 1:01 pm, Daan Hoogland <daan.hoogl...@gmail.com<mailto:daan.hoogl...@gmail.com>> wrote: Leo, great work. I should volunteer you more often. (volunteer me back at will) Rajani, Yes you are absolutaly right on the one hand. No, the community had decided that it couldn't support beyond the next release as it is to small, on the other hand. In the middle: By just saying this you have provided a model for parties that base products on ACS to support based on the apache source tree. I think we should adhere to it. I will look into it to see if we can for 4.4 (to replace the model I have been proposing in mails over the last couple of days. On Tue, Aug 5, 2014 at 6:38 AM, Rajani Karuturi <rajani.karut...@citrix.com<mailto:rajani.karut...@citrix.com>> wrote: Hi Leo, Thanks for the detailed wiki. shouldn’t we use git flow support for LTS releases? http://stackoverflow.com/a/16866118/201514 ~Rajani On 04-Aug-2014, at 7:29 pm, Leo Simons <lsim...@schubergphilis.com<mailto:lsim...@schubergphilis.com>> wrote: 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<http://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 -- Daan
