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


On 7/29/14, 11:05 AM, "Nate Gordon" <nate.gordon@appcore.com> wrote:

>This might be somewhere that we can extend the basic concept of gitflow.
>If
>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
>central
>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
>you
>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?

-Alena

>
>Thanks,
>
>-Nate
>
>
>On Tue, Jul 29, 2014 at 11:59 AM, Alena Prokharchyk <
>Alena.Prokharchyk@citrix.com> wrote:
>
>> 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
>> >
>>
>>
>
>
>-- 
>
>
>*Nate Gordon*Director of Technology | Appcore - the business of cloud
>computing®
>
>Office +1.800.735.7104  |  Direct +1.515.612.7787
>nate.gordon@appcore.com  |  www.appcore.com
>
>----------------------------------------------------------------------
>
>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
>you.

Mime
View raw message