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 >
