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 ;-) 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.
