cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: implementing git workflow
Date Tue, 05 Aug 2014 18:51:08 GMT
I think we should hold on with the git workflow implementation till all
the decisions on the items written by Leo, are discussed and finalized.

The very beginning of ³git workflow vote² shows that the vote was just to
get people opinion on the proposal. Before adopting it and cutting the
develop branch, all the questions should be cleared out.

"Rohit Yadav


Hugo, I think we started this voting thread to get opinion on the
proposal. I feel it may need some iteration and community agreement before
we adopt it.

Suggestions, flames and opinions are welcome.


On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <> wrote:

>To make it clear for everyone. This is the vote to adopt this new way of
>working right? Or is it just to get an opinion on the proposal?
>If it is indeed the vote to adopt this way of working it means that all
>committers will change how we interact with the branches in the
>CloudStack git.
>It¹s is a good thing in my book, but we need to be clear what the
>expected result is when this vote has concluded in 72 hours.


On 8/4/14, 6:59 AM, "Leo Simons" <> wrote:

>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
>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
>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
>* Everyone has to flip / git flow init / etc.
>* Someone has to update to build the new develop
>* ???
>* 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)
>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
>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.

View raw message