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:53:34 GMT
This seems like a reasonable use scenario, but is it not what the article
located at @ http://nvie.com/posts/a-successful-git-branching-model/
already describes?


On Tue, Jul 29, 2014 at 1:45 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> 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
> >>
>
>


-- 
*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