You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@cloudstack.apache.org by Leo Simons <LS...@schubergphilis.com> on 2014/08/04 15:59:22 UTC

implementing git workflow

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

Re: implementing git workflow

Posted by Rajani Karuturi <ra...@apache.org>.

below mail landed in the wrong thread. wanted to post on the git flow vote
thread. Will post again on that thread for the folks following it.


On Thu, Aug 7, 2014 at 10:08 AM, Rajani Karuturi <ra...@apache.org> wrote:

> I am not advocating that we should follow git-flow.
>
> If you see my original [proposal], it has no mention of git-flow. I just
> felt that we are abusing git and put some points which could help us
> improve.
>
> Git-flow is something which I liked and felt that it would make us treat
> git well.
>
> I am okay with any proposal which addresses those.
>
>
> I suggest not to discuss on this anymore. We had long discussions and
> still failed to reach consensus.
>
> lets put up a new one and I would be happy to vote.
>
>
> David/Alena/anyone else,
>
> Can you take this up and put a proposal for vote?
>
>
>
> [proposal] http://markmail.org/message/dawo4oannrdgpfgs
>
>
> On Wed, Aug 6, 2014 at 10:37 PM, Alena Prokharchyk <
> Alena.Prokharchyk@citrix.com> wrote:
>
>> Agree with Daan. The first vote was needed to get the peoples opinions on
>> whether we need to change our current git model (we certainly do as there
>> are so many problems in the current flow), and the article was just the
>> point of reference on how other people do it on the field. Now we have to
>> see what exactly would benefit CS from this model, and what won’t be
>> applicable or useful at all. There are many software models, and what
>> suits one, might not be applicable to another.
>>
>> So only after all the questions are cleared out and the process is
>> documented, we should start the second vote. And I think we can’t change
>> the document after the vote has started; it makes previous voting
>> obsolete. Only after the second vote passes, we can start implementing it.
>>
>>
>> Thanks,
>> Alena.
>>
>> On 8/5/14, 11:05 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>>
>> >I don't think we should hold on improving our way of working just
>> >because it is not perfect yet. Some things are unclear so we can't do
>> >those. Other things are perfectly clear and need to wait for nothing
>> >else. That doesn't mean that a second vote isn't needed. It is if not
>> >for anything else then for making sure we all want to go in the same
>> >direction. I posted a lengthy reply on the vote thread to answer any
>> >concerns and provoke more discussion. Let's see if that breeds further
>> >ideas and then decide on a next phase/vote.
>> >
>> >makes sense?
>> >
>> >On Wed, Aug 6, 2014 at 6:23 AM, Rajani Karuturi
>> ><Ra...@citrix.com> wrote:
>> >> For a proposal which got all +1’s[1] what are the next steps to do?? It
>> >>was made clear on the voting thread that required branching changes
>> >>would be done if the vote passes[2]
>> >>
>> >> Though the content in the document changed, the original proposal
>> >>hasn’t changed. Its still the same.
>> >> It is explained in details with all the commands and more details in
>> >>the wiki. Hence there is quite a bit of text changes. It is not a
>> >>diversion from what is already discussed.
>> >>
>> >> [1] http://markmail.org/message/h7nh6ozseien7ezh
>> >> [2] http://markmail.org/message/u7k6wv5kslb4ysyn
>> >>
>> >> ~Rajani
>> >>
>> >>
>> >>
>> >> On 06-Aug-2014, at 12:56 am, David Nalley
>> >><da...@gnsa.us>> wrote:
>> >>
>> >> On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
>> >> <Al...@citrix.com>>
>> >>wrote:
>> >> 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.
>> >>
>> >>
>> >> I agree with Alena - the vote was framed as opinion, not adoption.
>> >> Moreover, the document voted on has been changed ~10 times since we
>> >> started the vote, and the differences are substantial:
>> >>
>> >>
>> >>
>> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageI
>> >>d=30738915&selectedPageVersions=32&selectedPageVersions=22
>> >>
>> >> Agreement to do something and the following implementation are not
>> >> necessarily instantaneous.
>> >>
>> >
>> >
>> >
>> >--
>> >Daan
>>
>>
>
>
> --
> ~Rajani
>



-- 
~Rajani

Re: implementing git workflow

Posted by Rajani Karuturi <ra...@apache.org>.

I am not advocating that we should follow git-flow.

If you see my original [proposal], it has no mention of git-flow. I just
felt that we are abusing git and put some points which could help us
improve.

Git-flow is something which I liked and felt that it would make us treat
git well.

I am okay with any proposal which addresses those.


I suggest not to discuss on this anymore. We had long discussions and still
failed to reach consensus.

lets put up a new one and I would be happy to vote.


David/Alena/anyone else,

Can you take this up and put a proposal for vote?



[proposal] http://markmail.org/message/dawo4oannrdgpfgs


On Wed, Aug 6, 2014 at 10:37 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Agree with Daan. The first vote was needed to get the peoples opinions on
> whether we need to change our current git model (we certainly do as there
> are so many problems in the current flow), and the article was just the
> point of reference on how other people do it on the field. Now we have to
> see what exactly would benefit CS from this model, and what won’t be
> applicable or useful at all. There are many software models, and what
> suits one, might not be applicable to another.
>
> So only after all the questions are cleared out and the process is
> documented, we should start the second vote. And I think we can’t change
> the document after the vote has started; it makes previous voting
> obsolete. Only after the second vote passes, we can start implementing it.
>
>
> Thanks,
> Alena.
>
> On 8/5/14, 11:05 PM, "Daan Hoogland" <da...@gmail.com> wrote:
>
> >I don't think we should hold on improving our way of working just
> >because it is not perfect yet. Some things are unclear so we can't do
> >those. Other things are perfectly clear and need to wait for nothing
> >else. That doesn't mean that a second vote isn't needed. It is if not
> >for anything else then for making sure we all want to go in the same
> >direction. I posted a lengthy reply on the vote thread to answer any
> >concerns and provoke more discussion. Let's see if that breeds further
> >ideas and then decide on a next phase/vote.
> >
> >makes sense?
> >
> >On Wed, Aug 6, 2014 at 6:23 AM, Rajani Karuturi
> ><Ra...@citrix.com> wrote:
> >> For a proposal which got all +1’s[1] what are the next steps to do?? It
> >>was made clear on the voting thread that required branching changes
> >>would be done if the vote passes[2]
> >>
> >> Though the content in the document changed, the original proposal
> >>hasn’t changed. Its still the same.
> >> It is explained in details with all the commands and more details in
> >>the wiki. Hence there is quite a bit of text changes. It is not a
> >>diversion from what is already discussed.
> >>
> >> [1] http://markmail.org/message/h7nh6ozseien7ezh
> >> [2] http://markmail.org/message/u7k6wv5kslb4ysyn
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 06-Aug-2014, at 12:56 am, David Nalley
> >><da...@gnsa.us>> wrote:
> >>
> >> On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
> >> <Al...@citrix.com>>
> >>wrote:
> >> 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.
> >>
> >>
> >> I agree with Alena - the vote was framed as opinion, not adoption.
> >> Moreover, the document voted on has been changed ~10 times since we
> >> started the vote, and the differences are substantial:
> >>
> >>
> >>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageI
> >>d=30738915&selectedPageVersions=32&selectedPageVersions=22
> >>
> >> Agreement to do something and the following implementation are not
> >> necessarily instantaneous.
> >>
> >
> >
> >
> >--
> >Daan
>
>


-- 
~Rajani

Re: implementing git workflow

Posted by Alena Prokharchyk <Al...@citrix.com>.

Agree with Daan. The first vote was needed to get the peoples opinions on
whether we need to change our current git model (we certainly do as there
are so many problems in the current flow), and the article was just the
point of reference on how other people do it on the field. Now we have to
see what exactly would benefit CS from this model, and what won’t be
applicable or useful at all. There are many software models, and what
suits one, might not be applicable to another.

So only after all the questions are cleared out and the process is
documented, we should start the second vote. And I think we can’t change
the document after the vote has started; it makes previous voting
obsolete. Only after the second vote passes, we can start implementing it.


Thanks,
Alena.

On 8/5/14, 11:05 PM, "Daan Hoogland" <da...@gmail.com> wrote:

>I don't think we should hold on improving our way of working just
>because it is not perfect yet. Some things are unclear so we can't do
>those. Other things are perfectly clear and need to wait for nothing
>else. That doesn't mean that a second vote isn't needed. It is if not
>for anything else then for making sure we all want to go in the same
>direction. I posted a lengthy reply on the vote thread to answer any
>concerns and provoke more discussion. Let's see if that breeds further
>ideas and then decide on a next phase/vote.
>
>makes sense?
>
>On Wed, Aug 6, 2014 at 6:23 AM, Rajani Karuturi
><Ra...@citrix.com> wrote:
>> For a proposal which got all +1’s[1] what are the next steps to do?? It
>>was made clear on the voting thread that required branching changes
>>would be done if the vote passes[2]
>>
>> Though the content in the document changed, the original proposal
>>hasn’t changed. Its still the same.
>> It is explained in details with all the commands and more details in
>>the wiki. Hence there is quite a bit of text changes. It is not a
>>diversion from what is already discussed.
>>
>> [1] http://markmail.org/message/h7nh6ozseien7ezh
>> [2] http://markmail.org/message/u7k6wv5kslb4ysyn
>>
>> ~Rajani
>>
>>
>>
>> On 06-Aug-2014, at 12:56 am, David Nalley
>><da...@gnsa.us>> wrote:
>>
>> On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
>> <Al...@citrix.com>>
>>wrote:
>> 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.
>>
>>
>> I agree with Alena - the vote was framed as opinion, not adoption.
>> Moreover, the document voted on has been changed ~10 times since we
>> started the vote, and the differences are substantial:
>>
>> 
>>https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageI
>>d=30738915&selectedPageVersions=32&selectedPageVersions=22
>>
>> Agreement to do something and the following implementation are not
>> necessarily instantaneous.
>>
>
>
>
>-- 
>Daan

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

I don't think we should hold on improving our way of working just
because it is not perfect yet. Some things are unclear so we can't do
those. Other things are perfectly clear and need to wait for nothing
else. That doesn't mean that a second vote isn't needed. It is if not
for anything else then for making sure we all want to go in the same
direction. I posted a lengthy reply on the vote thread to answer any
concerns and provoke more discussion. Let's see if that breeds further
ideas and then decide on a next phase/vote.

makes sense?

On Wed, Aug 6, 2014 at 6:23 AM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> For a proposal which got all +1’s[1] what are the next steps to do?? It was made clear on the voting thread that required branching changes would be done if the vote passes[2]
>
> Though the content in the document changed, the original proposal hasn’t changed. Its still the same.
> It is explained in details with all the commands and more details in the wiki. Hence there is quite a bit of text changes. It is not a diversion from what is already discussed.
>
> [1] http://markmail.org/message/h7nh6ozseien7ezh
> [2] http://markmail.org/message/u7k6wv5kslb4ysyn
>
> ~Rajani
>
>
>
> On 06-Aug-2014, at 12:56 am, David Nalley <da...@gnsa.us>> wrote:
>
> On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
> <Al...@citrix.com>> wrote:
> 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.
>
>
> I agree with Alena - the vote was framed as opinion, not adoption.
> Moreover, the document voted on has been changed ~10 times since we
> started the vote, and the differences are substantial:
>
> https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=30738915&selectedPageVersions=32&selectedPageVersions=22
>
> Agreement to do something and the following implementation are not
> necessarily instantaneous.
>



-- 
Daan

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

For a proposal which got all +1’s[1] what are the next steps to do?? It was made clear on the voting thread that required branching changes would be done if the vote passes[2]

Though the content in the document changed, the original proposal hasn’t changed. Its still the same.
It is explained in details with all the commands and more details in the wiki. Hence there is quite a bit of text changes. It is not a diversion from what is already discussed.

[1] http://markmail.org/message/h7nh6ozseien7ezh
[2] http://markmail.org/message/u7k6wv5kslb4ysyn

~Rajani



On 06-Aug-2014, at 12:56 am, David Nalley <da...@gnsa.us>> wrote:

On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
<Al...@citrix.com>> wrote:
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.


I agree with Alena - the vote was framed as opinion, not adoption.
Moreover, the document voted on has been changed ~10 times since we
started the vote, and the differences are substantial:

https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=30738915&selectedPageVersions=32&selectedPageVersions=22

Agreement to do something and the following implementation are not
necessarily instantaneous.

Re: implementing git workflow

Posted by David Nalley <da...@gnsa.us>.

On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk
<Al...@citrix.com> wrote:
> 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.
>

I agree with Alena - the vote was framed as opinion, not adoption.
Moreover, the document voted on has been changed ~10 times since we
started the vote, and the differences are substantial:

https://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=30738915&selectedPageVersions=32&selectedPageVersions=22

Agreement to do something and the following implementation are not
necessarily instantaneous.

Re: implementing git workflow

Posted by Alena Prokharchyk <Al...@citrix.com>.

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

+1

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.

Regards.


On 31-Jul-2014, at 12:43 pm, Hugo Trippaers <hu...@trippaers.nl> wrote:

>Rajani,
>
>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.
>
>Cheers,
>
>Hugo
"


-Alena.



On 8/4/14, 6:59 AM, "Leo Simons" <LS...@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 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
>

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

Santhosh, Though in principle you are right I hardly think this can be
called suddenly.

On Tue, Aug 5, 2014 at 11:52 AM, Santhosh Edukulla
<sa...@citrix.com> wrote:
> Post the proposal vote, we should have given some time buffer, or prior intimation of a day or two before this switch i believe. There were still people using master till today for their development purpose, holding on it at sudden may not be appropriate.
>
> Regards,
> Santhosh
> ________________________________________
> From: Rajani Karuturi [Rajani.Karuturi@citrix.com]
> Sent: Tuesday, August 05, 2014 5:46 AM
> To: dev@cloudstack.apache.org
> Subject: Re: implementing git workflow
>
> Hi Daan,
>
> I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.
>
>
> I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
> Release Procedure wiki mention a script to change to version number. [1]
> Is it safe to just run it?
>
> Should we wait for 4.5 RM to create the release the branch?
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>
>
>
>
> ~Rajani
>
>
>
> On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:
>
> On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
> <Ra...@citrix.com>> wrote:
> 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
>
>
> No Rajani, We don't need an RM to make the switch (as Leo pointed
> out). Yours the honor as you came up with the idea. Let's go for it.
> I'll model the 4.4 work as much as possible towards your example.
>
> --
> Daan
>



-- 
Daan

RE: implementing git workflow

Posted by Santhosh Edukulla <sa...@citrix.com>.

Post the proposal vote, we should have given some time buffer, or prior intimation of a day or two before this switch i believe. There were still people using master till today for their development purpose, holding on it at sudden may not be appropriate.

Regards,
Santhosh
________________________________________
From: Rajani Karuturi [Rajani.Karuturi@citrix.com]
Sent: Tuesday, August 05, 2014 5:46 AM
To: dev@cloudstack.apache.org
Subject: Re: implementing git workflow

Hi Daan,

I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.

I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
Release Procedure wiki mention a script to change to version number. [1]
Is it safe to just run it?

Should we wait for 4.5 RM to create the release the branch?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure

~Rajani

On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
<Ra...@citrix.com>> wrote:
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

No Rajani, We don't need an RM to make the switch (as Leo pointed
out). Yours the honor as you came up with the idea. Let's go for it.
I'll model the 4.4 work as much as possible towards your example.

--
Daan

Re: implementing git workflow

Posted by David Nalley <da...@gnsa.us>.

> > we have two open questions to answer before that:
> > 1. Can we enable a git hook to prevent the commits to master post the switch?
>
> It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).
>

Let me preemptively say that Infra will not implement one-off commit
hooks for a repo. These become difficult to maintain at scale (we have
close to 300 writable repos) and is often causes a performance problem
at scale, which becomes difficult to watch for.

--David

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

~Rajani



On 05-Aug-2014, at 4:15 pm, Rohit Yadav <ro...@shapeblue.com> wrote:

> Hi Rajani,
> 
> On 05-Aug-2014, at 12:35 pm, Rajani Karuturi <Ra...@citrix.com> wrote:
> 
>> The switch to the new git flow is postponed to 7th aug.
> 
> Thanks for that, this means you’ll do it again on 7th August 00:00UTC?

I am planning to do this 48 hrs from now, which would be around 5:00PM IST on 7th august.

> 
> Meanwhile this means we’re to follow our normal workflow and commit on master.
> 
>> we have two open questions to answer before that:
>> 1. Can we enable a git hook to prevent the commits to master post the switch?
> 
> It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).
> 
>> 2. should we create the release branch as well or wait for RM to do it?
> 
> Since, you’re implementing the gitflow worflow, you should do it (create all the necessary branches).
> 
> Regards.
> 
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 05-Aug-2014, at 3:16 pm, Rajani Karuturi <Ra...@citrix.com>> wrote:
>> 
>> Hi Daan,
>> 
>> I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.
>> 
>> 
>> I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
>> Release Procedure wiki mention a script to change to version number. [1]
>> Is it safe to just run it?
>> 
>> Should we wait for 4.5 RM to create the release the branch?
>> 
>> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>> 
>> 
>> 
>> 
>> ~Rajani
>> 
>> 
>> 
>> On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:
>> 
>> On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
>> <Ra...@citrix.com>> wrote:
>> 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
>> 
>> 
>> No Rajani, We don't need an RM to make the switch (as Leo pointed
>> out). Yours the honor as you came up with the idea. Let's go for it.
>> I'll model the 4.4 work as much as possible towards your example.
>> 
>> --
>> Daan
>> 
>> 
> 
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
> 
> 
> 
> 
> Find out more about ShapeBlue and our range of CloudStack related services
> 
> IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>
> 
> This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

I added a pre push hook to the [wiki page] which rejects any commits which doesn’t start with ‘Merge branch’ on master


[wiki page] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Git#Git-githooks


~Rajani



On 05-Aug-2014, at 6:48 pm, Daan Hoogland <da...@gmail.com>> wrote:

That sound good to me

On Tue, Aug 5, 2014 at 2:15 PM, Rajani Karuturi
<Ra...@citrix.com>> wrote:

On 05-Aug-2014, at 4:47 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav <ro...@shapeblue.com>> wrote:
1. Can we enable a git hook to prevent the commits to master post the switch?

It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).


Let's not do this. Next problem will be who and when can commit on
master. Committers have responsibility to do this and to do it at the
right time.


agreed. Will try to update the wiki with some pre-commit hook which committers can use locally.

--
Daan

~Rajani



--
Daan

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

That sound good to me

On Tue, Aug 5, 2014 at 2:15 PM, Rajani Karuturi
<Ra...@citrix.com> wrote:
>
> On 05-Aug-2014, at 4:47 pm, Daan Hoogland <da...@gmail.com> wrote:
>
>> On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>>> 1. Can we enable a git hook to prevent the commits to master post the switch?
>>>
>>> It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).
>>>
>>
>> Let's not do this. Next problem will be who and when can commit on
>> master. Committers have responsibility to do this and to do it at the
>> right time.
>>
>
> agreed. Will try to update the wiki with some pre-commit hook which committers can use locally.
>
>> --
>> Daan
>
> ~Rajani



-- 
Daan

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

On 05-Aug-2014, at 4:47 pm, Daan Hoogland <da...@gmail.com> wrote:

> On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>>> 1. Can we enable a git hook to prevent the commits to master post the switch?
>> 
>> It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).
>> 
> 
> Let's not do this. Next problem will be who and when can commit on
> master. Committers have responsibility to do this and to do it at the
> right time.
> 

agreed. Will try to update the wiki with some pre-commit hook which committers can use locally. 

> -- 
> Daan

~Rajani

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav <ro...@shapeblue.com> wrote:
>> 1. Can we enable a git hook to prevent the commits to master post the switch?
>
> It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).
>

Let's not do this. Next problem will be who and when can commit on
master. Committers have responsibility to do this and to do it at the
right time.

-- 
Daan

Re: implementing git workflow

Posted by Rohit Yadav <ro...@shapeblue.com>.

Hi Rajani,

On 05-Aug-2014, at 12:35 pm, Rajani Karuturi <Ra...@citrix.com> wrote:

> The switch to the new git flow is postponed to 7th aug.

Thanks for that, this means you’ll do it again on 7th August 00:00UTC?

Meanwhile this means we’re to follow our normal workflow and commit on master.

> we have two open questions to answer before that:
> 1. Can we enable a git hook to prevent the commits to master post the switch?

It’s possible theoretically but to do that in less than 48 hours could be a challenge, you can open a ticket on JIRA/ASF-infra or contact the fine folks on ASF infra such as humbledooh (irc etc.).

> 2. should we create the release branch as well or wait for RM to do it?

Since, you’re implementing the gitflow worflow, you should do it (create all the necessary branches).

Regards.

>
>
> ~Rajani
>
>
>
> On 05-Aug-2014, at 3:16 pm, Rajani Karuturi <Ra...@citrix.com>> wrote:
>
> Hi Daan,
>
> I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.
>
>
> I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
> Release Procedure wiki mention a script to change to version number. [1]
> Is it safe to just run it?
>
> Should we wait for 4.5 RM to create the release the branch?
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>
>
>
>
> ~Rajani
>
>
>
> On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:
>
> On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
> <Ra...@citrix.com>> wrote:
> 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
>
>
> No Rajani, We don't need an RM to make the switch (as Leo pointed
> out). Yours the honor as you came up with the idea. Let's go for it.
> I'll model the 4.4 work as much as possible towards your example.
>
> --
> Daan
>
>

Regards,
Rohit Yadav
Software Architect, ShapeBlue
M. +41 779015219 | rohit.yadav@shapeblue.com
Blog: bhaisaab.org | Twitter: @_bhaisaab

Find out more about ShapeBlue and our range of CloudStack related services

IaaS Cloud Design & Build<http://shapeblue.com/iaas-cloud-design-and-build//>
CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
CloudStack Infrastructure Support<http://shapeblue.com/cloudstack-infrastructure-support/>
CloudStack Bootcamp Training Courses<http://shapeblue.com/cloudstack-training/>

This email and any attachments to it may be confidential and are intended solely for the use of the individual to whom it is addressed. Any views or opinions expressed are solely those of the author and do not necessarily represent those of Shape Blue Ltd or related companies. If you are not the intended recipient of this email, you must neither take any action based upon its contents, nor copy or show it to anyone. Please contact the sender if you believe you have received this email in error. Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue Services India LLP is a company incorporated in India and is operated under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is a registered trademark.

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

ad 1. Git hooks in the central repo require assistence of apache
infra. I think all committers should be able to do this. If people
don't comply their work should be reverted.
ad 2. We shouldn't need an RM. The gitflow model implies that
committers share the load of RM.

On Tue, Aug 5, 2014 at 12:35 PM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> The switch to the new git flow is postponed to 7th aug.
>
> we have two open questions to answer before that:
> 1. Can we enable a git hook to prevent the commits to master post the switch?
> 2. should we create the release branch as well or wait for RM to do it?
>
>
> ~Rajani
>
>
>
> On 05-Aug-2014, at 3:16 pm, Rajani Karuturi <Ra...@citrix.com>> wrote:
>
> Hi Daan,
>
> I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.
>
>
> I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
> Release Procedure wiki mention a script to change to version number. [1]
> Is it safe to just run it?
>
> Should we wait for 4.5 RM to create the release the branch?
>
> [1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure
>
>
>
>
> ~Rajani
>
>
>
> On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:
>
> On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
> <Ra...@citrix.com>> wrote:
> 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
>
>
> No Rajani, We don't need an RM to make the switch (as Leo pointed
> out). Yours the honor as you came up with the idea. Let's go for it.
> I'll model the 4.4 work as much as possible towards your example.
>
> --
> Daan
>
>



-- 
Daan

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

The switch to the new git flow is postponed to 7th aug.

we have two open questions to answer before that:
1. Can we enable a git hook to prevent the commits to master post the switch?
2. should we create the release branch as well or wait for RM to do it?


~Rajani



On 05-Aug-2014, at 3:16 pm, Rajani Karuturi <Ra...@citrix.com>> wrote:

Hi Daan,

I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.


I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
Release Procedure wiki mention a script to change to version number. [1]
Is it safe to just run it?

Should we wait for 4.5 RM to create the release the branch?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure




~Rajani



On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
<Ra...@citrix.com>> wrote:
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


No Rajani, We don't need an RM to make the switch (as Leo pointed
out). Yours the honor as you came up with the idea. Let's go for it.
I'll model the 4.4 work as much as possible towards your example.

--
Daan

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

Hi Daan,

I created develop branch on commit cc725e53e304781148a6bf077e05d844fe88207c and pushed it.


I am trying to create the  4.5 branch. For this, I need to change the version number in develop branch.
Release Procedure wiki mention a script to change to version number. [1]
Is it safe to just run it?

Should we wait for 4.5 RM to create the release the branch?

[1] https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+Procedure




~Rajani



On 05-Aug-2014, at 2:27 pm, Daan Hoogland <da...@gmail.com>> wrote:

On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
<Ra...@citrix.com>> wrote:
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


No Rajani, We don't need an RM to make the switch (as Leo pointed
out). Yours the honor as you came up with the idea. Let's go for it.
I'll model the 4.4 work as much as possible towards your example.

--
Daan

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi
<Ra...@citrix.com> wrote:
> 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

No Rajani, We don't need an RM to make the switch (as Leo pointed
out). Yours the honor as you came up with the idea. Let's go for it.
I'll model the 4.4 work as much as possible towards your example.

-- 
Daan

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

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 <da...@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
<Ra...@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 <LS...@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.

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

Again, I’d personally suggest to just do it.

Git flow says:
1. basically never
2. what’s a release manager?
3. never, cut release branch == feature freeze, tag release == freeze

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

Re: implementing git workflow

Posted by Daan Hoogland <da...@gmail.com>.

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
<Ra...@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 <LS...@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 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

Re: implementing git workflow

Posted by Rajani Karuturi <Ra...@citrix.com>.

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 <LS...@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 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
>