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 >
