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 18:20:17 GMT

On 7/29/14, 11:05 AM, "Nate Gordon" <> wrote:

>This might be somewhere that we can extend the basic concept of gitflow.
>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
>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
>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 ;-)

Agree:-) But the same can apply to *develop branch. So we should decide
for which bugs the hot fix branch should be cut, and which fixes can go
directly to *develop/*release branches. This criteria has to be defined in
the doc, and be based on the a) bug severity b) number of people who work
on the bug - if more than one, then we cut the new branch c)
feedback/review is needed for the bug d) anything else?


>On Tue, Jul 29, 2014 at 11:59 AM, Alena Prokharchyk <
>> wrote:
>> I have one more question in addition to what Sheng asked. Document
>> mentions that
>> *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
>> branch, fix the problem, and merge the fix to *release? Would the rule
>> the same for Major bug as opposed to Critical one?
>> Thank you,
>> Alena.
>> 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
>> >>gitflow
>> >> etc, but could someone already familiar with the topic give an
>> >>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
>> >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
>> >noted
>> >* not deleting release branches once releases are finished
>> >* consider using support/ branches for point releases rather than
>> >branches
>> >
>> >Note that this new workflow implies a variety of things, including:
>> >* sharing responsibility for merges among many committers (as opposed
>> >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
>> >>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
>> >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,
>> >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
>Office +1.800.735.7104  |  Direct +1.515.612.7787
>  |
>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

View raw message