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
