cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tanner Danzey <arkan...@gmail.com>
Subject Re: [DISCUSS] git commit proces
Date Tue, 29 Jul 2014 18:32:24 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message