Tanner, My question was about bugs happening not in production (the branch that is already released). For those hot fix branches are needed - and that described in the article. My question was about new bugs happening either in the *developer branch or *release branch that hasn’t been released yet. In CS “git commit” document we should clearly define the criteria for the bugs requiring separate branch vs bugs that can be committed to the *developer/*release branch directly.
Thanks, Alena. On 7/29/14, 11:53 AM, "Tanner Danzey" <arkan...@gmail.com> wrote: >This seems like a reasonable use scenario, but is it not what the article >located at @ http://nvie.com/posts/a-successful-git-branching-model/ >already describes? > > >On Tue, Jul 29, 2014 at 1:45 PM, Alena Prokharchyk < >alena.prokharc...@citrix.com> wrote: > >> I would rather say that the bug fix branch should be cut from *developer >> branch, not master, then merged to *developer upon fixing so all the >>tests >> are run for the fix. Only after tests pass, the merge to master from >> developer should be done. If the bug doesn’t require branching out (see >> the proposed criteria in my other email), it should be fixed directly in >> *developer branch. Nothing should go to the master branch directly >> bypassing the developer branch. >> >> -Alena. >> >> On 7/29/14, 11:37 AM, "sowmya samala" <skarna...@gmail.com> wrote: >> >> >I think it would be good if the bug fixes are delivered to the Release >> >branch only if they are found in that particular Release. But if there >>are >> >any productions fixes then a new hot fix branch should be cut out of >> >Master >> >and once the changes are made and released, the branch should be merged >> >back to Master. All the child branches should get these latest changes >> >from >> >Master. >> > >> >Please share your thoughts on this ? >> > >> > >> >On Tue, Jul 29, 2014 at 2:32 PM, Tanner Danzey <arkan...@gmail.com> >> wrote: >> > >> >> For what it's worth, I support the move to a git-flow project >>layout. It >> >> seems to have a more sensible structure than what ACS currently has, >> >> although I'm not going to say that ACS's current structure has not >>been >> >> sufficient, just that it simply seems to be the time for change. The >> >> git-flow model seems to be a little easier to form a model of in >>one's >> >> head. >> >> >> >> >> >> On Tue, Jul 29, 2014 at 1:20 PM, Alena Prokharchyk < >> >> alena.prokharc...@citrix.com> wrote: >> >> >> >> > >> >> > >> >> > On 7/29/14, 11:05 AM, "Nate Gordon" <nate.gor...@appcore.com> >>wrote: >> >> > >> >> > >This might be somewhere that we can extend the basic concept of >> >>gitflow. >> >> > >If >> >> > >there are trivial fixes (I forgot an edge case in an if >>statement), >> >>it >> >> > >probably isn't necessary to branch the release and merge back, >>but if >> >> you >> >> > >need to do some significant work (I broke one of the other >> >>hypervisors >> >> and >> >> > >need to refactor something), or want feedback/discussion it would >> >> probably >> >> > >be easier to branch from the release branch, push the branch to >>the >> >> > >central >> >> > >repo to allow feedback/testing from others, and then merge back in >> >>once >> >> it >> >> > >has been resolved. >> >> > > >> >> > >I think the general concept is to default to creating a branch any >> >>time >> >> > >you >> >> > >are doing something (I'm sure there are exceptions, but this >>would be >> >> the >> >> > >default mode of operation). That way whole >> >> > >features/fixes/releases/testing/experimentation/magic can be >>worked >> >>on >> >> in >> >> > >parallel and merged/reverted as a unit. It also encourages >> >>collaboration >> >> > >because it is easy to identify a unit of work that needs to be >> >> discussed. >> >> > > >> >> > >But really, it would be easier to cut the release if there weren't >> >>bugs >> >> > >that we had to work through ;-) >> >> > >> >> > Agree:-) But the same can apply to *develop branch. So we should >> >>decide >> >> > for which bugs the hot fix branch should be cut, and which fixes >>can >> >>go >> >> > directly to *develop/*release branches. This criteria has to be >> >>defined >> >> in >> >> > the doc, and be based on the a) bug severity b) number of people >>who >> >>work >> >> > on the bug - if more than one, then we cut the new branch c) >> >> > feedback/review is needed for the bug d) anything else? >> >> > >> >> > -Alena >> >> > >> >> > > >> >> > >Thanks, >> >> > > >> >> > >-Nate >> >> > > >> >> > > >> >> > >On Tue, Jul 29, 2014 at 11:59 AM, Alena Prokharchyk < >> >> > >alena.prokharc...@citrix.com> wrote: >> >> > > >> >> > >> I have one more question in addition to what Sheng asked. >>Document >> >> > >> http://nvie.com/posts/a-successful-git-branching-model/ mentions >> >>that >> >> > >>the >> >> > >> *hotfix branch should be created for the blocker/critical bugs >>in >> >>the >> >> > >> current production release. What about bugs happenning in the >> >>*release >> >> > >> branch (the one that hasn't been released yet)? Should we fix >>them >> >> > >> directly in the *release branch, or should we branch out off the >> >> > >>*release >> >> > >> branch, fix the problem, and merge the fix to *release? Would >>the >> >>rule >> >> > >>be >> >> > >> the same for Major bug as opposed to Critical one? >> >> > >> >> >> > >> Thank you, >> >> > >> Alena. >> >> > >> >> >> > >> >> >> > >> >> >> > >> On 7/29/14, 12:52 AM, "Leo Simons" <lsim...@schubergphilis.com> >> >> wrote: >> >> > >> >> >> > >> >On Jul 29, 2014, at 5:45 AM, Sheng Yang <sh...@yasker.org> >>wrote: >> >> > >> >> I am trying to catch up, by reading the thread and checking >> >>what's >> >> > >> >>gitflow >> >> > >> >> etc, but could someone already familiar with the topic give >>an >> >> > >>overview >> >> > >> >>of >> >> > >> >> the issue? >> >> > >> >> >> >> > >> >> For example, we can start by asking these questions: >> >> > >> >> 1. What's the issue with current development process? >> >> > >> > >> >> > >> >Right now it is quite hard to get to a stable release, or to >> >>produce >> >> > >>high >> >> > >> >quality contributions, and this happens in part because of the >>git >> >> > >> >workflow in use. >> >> > >> > >> >> > >> >Cherry-picking is an approach where git can provide 0 >>assistance >> >>with >> >> > >> >branch and merge management. Read >> >> > >> > >> >>http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html >> >> > >> >for an introduction to that subject, for example. >> >> > >> > >> >> > >> >> 2. What's the purposed new approach to the process? >> >> > >> > >> >> > >> >To use a branch/merge workflow rather than a cherry-pick >>workflow, >> >> > >> >preserving commit ids across branches. >> >> > >> > >> >> > >> >To adopt a specific well-documented workflow called git-flow >>that >> >>has >> >> > >> >tool support. Read >> >> > >> > http://nvie.com/posts/a-successful-git-branching-model/ >> >> > >> >for an introduction to git-flow. >> >> > >> > >> >> > >> >To then tune this workflow to cloudstack. In particular, so >>far, >> >>I¹ve >> >> > >> >noted >> >> > >> >* not deleting release branches once releases are finished >> >> > >> >* consider using support/ branches for point releases rather >>than >> >> > >>hotfix/ >> >> > >> >branches >> >> > >> > >> >> > >> >Note that this new workflow implies a variety of things, >> >>including: >> >> > >> >* sharing responsibility for merges among many committers (as >> >>opposed >> >> > >>to >> >> > >> >a release manager responsible for cherry picking) >> >> > >> >* distributing the Œmerge pain¹ throughout the development >> >>process as >> >> > >> >features finish up (rather than Œbig bang¹ during release time) >> >> > >> > >> >> > >> >> 3. What's the pro/con of the new process? And what's the >> >>pro/con of >> >> > >>the >> >> > >> >>old >> >> > >> >> one? >> >> > >> > >> >> > >> >This is very difficult to summarize fairly. >> >> > >> > >> >> > >> >IMHO the only advantage of the old process is that it is what >> >> everyone >> >> > >> >knows already. It¹s main downsides are that it is not using >>git¹s >> >> > >> >excellent branch management features, does not allow comparing >>or >> >> > >>merging >> >> > >> >between branches, requires contributions to be re-written for >> >> multiple >> >> > >> >branches, and encourages developers to ignore merge conflicts >> >>until >> >> > >> >release time. >> >> > >> > >> >> > >> >IMHO any workflow that does not rely on cherry-picking has only >> >> > >> >advantages compared to the current process. >> >> > >> > >> >> > >> >Git-flow has many people that like it and many people that >>don¹t. >> >> But, >> >> > >> >the people that don¹t like it usually use another branch/merge >> >>model, >> >> > >>not >> >> > >> >cherry-picking. It¹s main advantages among available >>branch/merge >> >> > >> >workflwos are being well-defined, oft-used and tool-supported. >> >> > >> > >> >> > >> >> That would make the question much more clear. >> >> > >> > >> >> > >> >Hope this helps, >> >> > >> > >> >> > >> > >> >> > >> >cheers, >> >> > >> > >> >> > >> > >> >> > >> >Leo >> >> > >> > >> >> > >> >> >> > >> >> >> > > >> >> > > >> >> > >-- >> >> > > >> >> > > >> >> > >*Nate Gordon*Director of Technology | Appcore - the business of >>cloud >> >> > >computing® >> >> > > >> >> > >Office +1.800.735.7104 | Direct +1.515.612.7787 >> >> > >nate.gor...@appcore.com | www.appcore.com >> >> > > >> >> > >> >>>>>---------------------------------------------------------------------- >> >> > > >> >> > >The information in this message is intended for the named >>recipients >> >> only. >> >> > >It may contain information that is privileged, confidential or >> >>otherwise >> >> > >protected from disclosure. If you are not the intended recipient, >>you >> >> are >> >> > >hereby notified that any disclosure, copying, distribution, or the >> >> taking >> >> > >of any action in reliance on the contents of this message is >>strictly >> >> > >prohibited. If you have received this e-mail in error, do not >>print >> >>it >> >> or >> >> > >disseminate it or its contents. In such event, please notify the >> >>sender >> >> by >> >> > >return e-mail and delete the e-mail file immediately thereafter. >> >>Thank >> >> > >you. >> >> > >> >> > >> >> >> >> >> >> -- >> >> *Tanner Danzey* >> >> Systems Engineer >> >> Northstar Technology Group >> >> arkan...@gmail.com / tanner.dan...@northstar-tg.com >> >> (701) 237-9096 x7122 >> >> >> >> > > >-- >*Tanner Danzey* >Systems Engineer >Northstar Technology Group >arkan...@gmail.com / tanner.dan...@northstar-tg.com >(701) 237-9096 x7122
