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
