cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <>
Subject Re: [DISCUSS] git commit proces
Date Tue, 29 Jul 2014 16:59:37 GMT
I have one more question in addition to what Sheng asked. Document 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,

On 7/29/14, 12:52 AM, "Leo Simons" <> wrote:

>On Jul 29, 2014, at 5:45 AM, Sheng Yang <> wrote:
>> I am trying to catch up, by reading the thread and checking what's
>> etc, but could someone already familiar with the topic give an overview
>> 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
>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
>for an introduction to git-flow.
>To then tune this workflow to cloudstack. In particular, so far, I¹ve
>* not deleting release branches once releases are finished
>* consider using support/ branches for point releases rather than hotfix/
>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
>> 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,

View raw message