Ah. I simply misunderstood. That sounds very reasonable to me.
On Tue, Jul 29, 2014 at 1:59 PM, Alena Prokharchyk < alena.prokharc...@citrix.com> wrote: > 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 > > -- *Tanner Danzey* Systems Engineer Northstar Technology Group arkan...@gmail.com / tanner.dan...@northstar-tg.com (701) 237-9096 x7122
