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:45:54 GMT
I would rather say that the bug fix branch should be cut from *developer
branch, not master, then merged to *developer upon fixing so all the tests
are run for the fix. Only after tests pass, the merge to master from
developer should be done. If the bug doesn’t require branching out (see
the proposed criteria in my other email), it should be fixed directly in
*developer branch. Nothing should go to the master branch directly
bypassing the developer branch.

-Alena.

On 7/29/14, 11:37 AM, "sowmya samala" <skarnam14@gmail.com> wrote:

>I think it would be good if the bug fixes are delivered to the Release
>branch only if they are found in that particular Release. But if there are
>any productions fixes then a new hot fix branch should be cut out of
>Master
>and once the changes are made and released, the branch should be merged
>back to Master. All the child branches should get these latest changes
>from
>Master.
>
>Please share your thoughts on this ?
>
>
>On Tue, Jul 29, 2014 at 2:32 PM, Tanner Danzey <arkaniad@gmail.com> wrote:
>
>> For what it's worth, I support the move to a git-flow project layout. It
>> seems to have a more sensible structure than what ACS currently has,
>> although I'm not going to say that ACS's current structure has not been
>> sufficient, just that it simply seems to be the time for change. The
>> git-flow model seems to be a little easier to form a model of in one's
>> head.
>>
>>
>> On Tue, Jul 29, 2014 at 1:20 PM, Alena Prokharchyk <
>> Alena.Prokharchyk@citrix.com> wrote:
>>
>> >
>> >
>> > 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.
>> >
>> >
>>
>>
>> --
>> *Tanner Danzey*
>> Systems Engineer
>> Northstar Technology Group
>> arkaniad@gmail.com / tanner.danzey@northstar-tg.com
>> (701) 237-9096 x7122
>>

Mime
View raw message