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.
