cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alena Prokharchyk <Alena.Prokharc...@citrix.com>
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
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" <LSimons@schubergphilis.com> wrote:

>On Jul 29, 2014, at 5:45 AM, Sheng Yang <sheng@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
>


Mime
View raw message