Re: implementing git workflow
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 rajani.karut...@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.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan
Re: implementing git workflow
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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: That sound good to me On Tue, Aug 5, 2014 at 2:15 PM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@citrix.com wrote: On 05-Aug-2014, at 4:47 pm, Daan Hoogland daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav rohit.ya...@shapeblue.commailto:rohit.ya...@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
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 daan.hoogl...@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 rajani.karut...@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.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan
Re: implementing git workflow
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.prokharc...@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 daan.hoogl...@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 rajani.karut...@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.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan -- ~Rajani
Re: implementing git workflow
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 raj...@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.prokharc...@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 daan.hoogl...@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 rajani.karut...@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.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous. -- Daan -- ~Rajani -- ~Rajani
Re: implementing git workflow
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 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 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
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.commailto: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.commailto: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.commailto: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.orghttp://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
On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@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
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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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
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.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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
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 rajani.karut...@citrix.commailto:rajani.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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
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 santhosh.eduku...@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.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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
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 rajani.karut...@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 rajani.karut...@citrix.commailto:rajani.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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
Hi Rajani, On 05-Aug-2014, at 12:35 pm, Rajani Karuturi rajani.karut...@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 rajani.karut...@citrix.commailto:rajani.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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
On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav rohit.ya...@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
~Rajani On 05-Aug-2014, at 4:15 pm, Rohit Yadav rohit.ya...@shapeblue.com wrote: Hi Rajani, On 05-Aug-2014, at 12:35 pm, Rajani Karuturi rajani.karut...@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 rajani.karut...@citrix.commailto:rajani.karut...@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 daan.hoogl...@gmail.commailto:daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 10:52 AM, Rajani Karuturi rajani.karut...@citrix.commailto:rajani.karut...@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.ya...@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design Buildhttp://shapeblue.com/iaas-cloud-design-and-build// CSForge – rapid IaaS deployment frameworkhttp://shapeblue.com/csforge/ CloudStack Consultinghttp://shapeblue.com/cloudstack-consultancy/ CloudStack Infrastructure Supporthttp://shapeblue.com/cloudstack-infrastructure-support/ CloudStack Bootcamp Training Courseshttp://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
On 05-Aug-2014, at 4:47 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav rohit.ya...@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
That sound good to me On Tue, Aug 5, 2014 at 2:15 PM, Rajani Karuturi rajani.karut...@citrix.com wrote: On 05-Aug-2014, at 4:47 pm, Daan Hoogland daan.hoogl...@gmail.com wrote: On Tue, Aug 5, 2014 at 12:45 PM, Rohit Yadav rohit.ya...@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
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
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 h...@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 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 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
On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous.
Re: implementing git workflow
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.usmailto:da...@gnsa.us wrote: On Tue, Aug 5, 2014 at 2:51 PM, Alena Prokharchyk alena.prokharc...@citrix.commailto:alena.prokharc...@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=30738915selectedPageVersions=32selectedPageVersions=22 Agreement to do something and the following implementation are not necessarily instantaneous.
Re: implementing git workflow
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 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
