Agree with you, Rohit. The changes to the git model we use, are needed indeed. But we should address only the problems that CS faces, and the main problem - quality control. The proposal should be limited just to the changes that are really needed for the CS, and that will work with the current CS model (minor maintenance releases support is a part of it)
Briefly, I think we should do this: * introduce staging branch. We can call it “develop”. Develop branch gets merged daily into master only after CI runs/passes on it. * Master branch reflects the latest changes from *develop, that passed the quality control. * release branches cut from the stable master branch only. * people working on hot fixes/features/critical bugs (where collaboration is needed), have to cut their own branch from *develop tree. And merge the fix to *develop only after running automation on their branches (BVT or CI - to be discussed). Extra daily CI run on *develop branch will ensure that fixes committed by various people to *develop branch along the day, don’t break anything. Thank you, Alena. On 8/6/14, 12:08 PM, "Rohit Yadav" <rohit.ya...@shapeblue.com> wrote: >Hi, > >If it was not clear, let me re-state — just because I’m participating in >this thread does not mean I fully support git-flow, or I am here to >defend it. > >The proposal thread warriors Rajani, Daan, Leo and others can comment and >advise? > >I like couple of good ideas in it, and I think it’s better than what we >do, especially the baseline protocol. I want to take good stuff from it >and adapt them to our workflow. As I see now, this won't change our >process/workflow a lot or that it can stop bad commits or practices from >happening in our repositories. > >I’ve emailed git-flow’s author about raised issues, will keep everyone >posted. > >Cheers. > >On 06-Aug-2014, at 8:29 pm, Alena Prokharchyk ><alena.prokharc...@citrix.com> wrote: >> >> On 8/6/14, 11:22 AM, "David Nalley" <da...@gnsa.us> wrote: >> >>> On Wed, Aug 6, 2014 at 2:06 PM, Rohit Yadav <rohit.ya...@shapeblue.com> >>> wrote: >>>> Hi, >>>> >>>> On 06-Aug-2014, at 7:30 pm, Alena Prokharchyk >>>> <alena.prokharc...@citrix.com> wrote: >>>> >>>>> Rohit, thank you for the explanation. So we cut the maintenance >>>>>release >>>>> from the master branch, not *develop as opposed to the major release >>>>> branch. >>>>> >>>>> One more open question. Its clear that we cut the maintenance release >>>>> from >>>>> the master branch, but what would be the right way to merge it back >>>>>if >>>>> this is a maintenance release for say 4.2, and 4.4 is the top of the >>>>> master branch? Where would the 4.2.1 tag appear? It can¹t be on a top >>>>> of >>>>> 4.4 >>>> >>>> You checkout a support branch from 4.2 tag (or for that matter you may >>>> keep the 4.2 release branch, it¹s same) for LTS/support. >>>> You tag 4.2.1 on the support branch. (it¹s the same way you would do >>>> like we do it now). I think git-flow is suitable for rolling releases >>>> and may not 100% work with our deployment/release process. One thing >>>> I¹ve suggested is shortening of our release cycles which can help. >>>> >>> >>> So I suspect that checking out a tag would work. I don't know that >>> once we create a tag, that we would be able to merge that back into >>> master. Especially true for maintenance releases. How and where would >>> we merge 4.5.1 back into master? Moreover, I don't see us getting out >>> of checking out the tag, and creating a branch to work in. That means >>> we'd delete a branch, check out a tag, create a branch, create a new >>> tag, delete a branch - and repeat. >>> >>> That said, we don't currently have rolling releases - and now you are >>> suggesting it may not 100% work. *sigh* >> >> Dave, you are right, we can¹t. There is no way to merge back minor >> releases back to master branch, and preserve the history. The model >>works >> only for rolling releases. So making master reflect release branch won¹t >> make sense in CS case. >> >>> >>>> The flow of commits/fixes/changes would follow the baseline protocol ‹ >>>> from firm branch to soft branches chronologically, so if there is a >>>>bug >>>> on 4.2 release you fix it on 4.2 support branch and >>>> cherry-pick/apply/merge that branch/commit(s) to 4.3 release branch >>>>and >>>> then to 4.4 support branch Š to 4.5 release branch to develop branch. >>>> >>>> I think git-flow assumes the releases will be chronological so you >>>> don¹t release 4.3.1 after 4.4 etc and you always progress? I¹m not >>>>sure. >>>> We can think of better ways of doing things, we can also learn from >>>>how >>>> other projects do it. >>>> >>>> Maintaining major versions/releases such as 4.2, 4.3, 4.4 will be >>>> painful, that always felt to me like maintaining a whole different >>>> product. If we can do something about that, we¹re going to make a lot >>>>of >>>> people happy IMO. >>>> >>>>> >>> >>> So we've set the expectation that we'll follow SemVer - and adhering >>> to that is a good thing. Rolling releases are interesting, but we are >>> a long way from being able to do anything remotely close IMO. > >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 & >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.
