cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rajani Karuturi <>
Subject Re: implementing git workflow
Date Tue, 05 Aug 2014 08:52:56 GMT
I think we should do the branch related changes[1] and make the switch. Are we waiting for
a RM for 4.5?



On 05-Aug-2014, at 1:01 pm, Daan Hoogland <<>>

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
<<>> wrote:
Hi Leo,
Thanks for the detailed wiki.

shouldn’t we use git flow support for LTS releases?


On 04-Aug-2014, at 7:29 pm, Leo Simons <<>>

Hey folks,

Since Daan volunteered me to do some docs, I’ve updated Rohit’s page at

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<> 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

the -<summary> should be descriptive and is optional.


for fixes to 4.4.x.




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