cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sheng Yang <sh...@yasker.org>
Subject Re: [VOTE] git workflow
Date Fri, 08 Aug 2014 23:00:32 GMT
Rohit,

Thank you to bring this to a end.

Finally handling multiple maintenance release is recognized as an issue in
this model.

--Sheng

On Fri, Aug 8, 2014 at 4:28 AM, Rohit Yadav <rohit.yadav@shapeblue.com>
wrote:

> Hi,
>
> Vincent (nvie) has allowed me to share his email publicly, here you go:
>
> "
> Hi Rohit,
>
> Thanks for reaching out. I don't think git-flow suits your use case very
> well. Git flow was mainly optimized as a set of rules to help bring forth
> "forward-only" releases, and does not support multiple concurrent and
> non-chronological releases very well. The main reason is that getting all
> the details down leads to much complexity. Back when the git-flow model was
> devised it was meant to be a rule set that could be automated, and aimed at
> a single release stream. Adding multiple concurrent releases would
> significantly complicate the model.
>
> I have no advice on what model would work better for you. Of course you
> could make a variant of git-flow that works with multiple "master"
> branches, one for each release, but the exact semantics of which of those
> to merge hot fixes in, for example, are not documented somewhere formally.
>
> Cheers,
> Vincent
> “
>
> On 08-Aug-2014, at 9:23 am, Daan Hoogland <daan.hoogland@gmail.com> wrote:
>
> > Rohit, this is not a git-flow or gitflow discussion. It seems to be at
> > times but it is not. It is a discussion about how to branch in our
> > repository. That discussion should not end, but maybe so in this
> > thread.
> >
> > On Fri, Aug 8, 2014 at 9:19 AM, Rohit Yadav <rohit.yadav@shapeblue.com>
> wrote:
> >> Hi all,
> >>
> >> Let’s end this discussion thread.
> >>
> >> I asked Vincent (nvie) and some friends from google and facebook on
> this and all of them recommended that this is not for us; then I read the
> whole thread again without prejudice or ego and I think it’s not for us
> though we should pick up couple of good ideas from it:
> >>
> >> - git-flow was designed for only “forward” releases
> >> - git-flow does not support multiple concurrent and non-chronological
> releases/support very well (no nvie documentation on how to do that)
> >>
> >> Instead, if you’re interested on such topic I started a proposal
> (inspired by couple of workflows) on solving cherry-picking issue by
> adapting our release/master workflow please have a look on that. Some good
> reads on other git workflows we can get ideas from;
> >>
> >>
> http://blogs.atlassian.com/2013/11/the-essence-of-branch-based-workflows
> (my new proposal uses this idea)
> >> https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html
> (read this at least once)
> >>
> >> PS. Let me know privately if you want me to forward you Vincent’s email
> >>
> >> On 07-Aug-2014, at 11:52 pm, Mike Tutkowski <
> mike.tutkowski@solidfire.com> wrote:
> >>
> >>> This is what I was wondering about, as well. It seems all of our
> 'master'
> >>> problems become 'develop' problems.
> >>>
> >>> I do like the idea of merging versus cherry picking (as a general
> rule),
> >>> though.
> >>>
> >>>
> >>> On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk <
> >>> Alena.Prokharchyk@citrix.com> wrote:
> >>>
> >>>> Sebastian, addressing the following comment of yours
> >>>>
> >>>>
> >>>> "The main issue with master right now is that it moves really fast as
> a
> >>>> shared branch, people merge features without warning, we see
> regressions
> >>>> etc..
> >>>> By the time we release a major version, master has moved so much that
> it
> >>>> feels like starting over with the next release. It's almost as if we
> are
> >>>> forking our own software. CI alone (even if it were really good) will
> not
> >>>> fix this.”
> >>>>
> >>>>
> >>>> You will still have this problem. You cut the next release branch
> from the
> >>>> *develop branch, not from master. And the *develop branch will move
> with
> >>>> the same pace as the old master, after the release branch is cut. So
> >>>> “master moving really fast” problem would become “develop moving
> really
> >>>> fast”.
> >>>>
> >>>> The problems you’ve mentioned - people merge features without
> warning, we
> >>>> see regressions - can be fixed only with automation in place and the
> >>>> requirement to run this automation (CI/BVT) before the merge is done.
> >>>> Otherwise you are just shifting all existing problems from master to
> >>>> develop.
> >>>>
> >>>>
> >>>> -Alena.
> >>>>
> >>>>
> >>>>
> >>>> On 8/7/14, 2:15 PM, "Sebastien Goasguen" <runseb@gmail.com> wrote:
> >>>>
> >>>>>
> >>>>> On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk
> >>>>> <Alena.Prokharchyk@citrix.com> wrote:
> >>>>>
> >>>>>>
> >>>>>>
> >>>>>> On 8/7/14, 1:42 PM, "Sebastien Goasguen" <runseb@gmail.com>
wrote:
> >>>>>>
> >>>>>>>
> >>>>>>> On Aug 7, 2014, at 8:33 AM, David Nalley <david@gnsa.us>
wrote:
> >>>>>>>
> >>>>>>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen <
> runseb@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>> On Aug 6, 2014, at 7:15 PM, David Nalley <david@gnsa.us>
wrote:
> >>>>>>>>>
> >>>>>>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk
> >>>>>>>>>> <Alena.Prokharchyk@citrix.com> wrote:
> >>>>>>>>>>> Edison, thank you for raising the concern
about the BVT/CI.
> >>>>>>>>>>> Somebody
> >>>>>>>>>>> mentioned earlier that we should separate
git workflow
> >>>>>>>>>>> implementation from
> >>>>>>>>>>> the CI effort, but I do think we have to
do in in conjunction.
> >>>>>>>>>>> Otherwise
> >>>>>>>>>>> what is the point in introducing staging/develop
branch? If
> there
> >>>>>>>>>>> is
> >>>>>>>>>>> no
> >>>>>>>>>>> daily automation run verifying all the code
merged from
> >>>>>>>>>>> hotFixes/feature
> >>>>>>>>>>> branches (and possibly reverting wrong checkins),
we can as
> well
> >>>>>>>>>>> merge the
> >>>>>>>>>>> code directly to master.
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Yes! - please.
> >>>>>>>>>> Doing this without CI as a gating factor buys
us very little.
> >>>>>>>>>>
> >>>>>>>>>> --David
> >>>>>>>>>
> >>>>>>>>> David, can you clarify. Are you going to be against
any change
> of git
> >>>>>>>>> workflow until we get CI/BVT in place ?
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> No, please don't take it that way.
> >>>>>>>> I understand Leo's point about Cherry-picking being
for fruit,
> and not
> >>>>>>>> code. But, I don't think that the workflow changes I've
seen
> proposed
> >>>>>>>> affect quality. So shifting for quality's sake doesn't
make a lot
> of
> >>>>>>>> sense in my mind. They could be a component of fixing
the quality
> >>>>>>>> problem.
> >>>>>>>>
> >>>>>>>> --David
> >>>>>>>
> >>>>>>> Agreed, the changes don't affect quality but should support
a CI
> infra
> >>>>>>> that helps improves quality.
> >>>>>>>
> >>>>>>> I do think the changes provide
> >>>>>>>
> >>>>>>> -a stable master that represent released software
> >>>>>>
> >>>>>>
> >>>>>> You can always look at the latest release branch to get it,
> >>>>>
> >>>>> Yes I know how to get to the latest released software.
> >>>>>
> >>>>> I actually don't have good answers for your questions but I think
> Nate's
> >>>>> email (couple emails back) answers a lot of them.
> >>>>>
> >>>>>> as we are
> >>>>>> planning to keep them around to support maintenance. From the
> developer
> >>>>>> stand point, I would be more interested in getting the latest
stable
> >>>>>> code,
> >>>>>> not the latest stable release.
> >>>>>
> >>>>> I think that's fine from a developer standpoint. I tend to look
at
> things
> >>>>> from a user standpoint.
> >>>>> I think a basic user who wants to check out source (because he
> builds his
> >>>>> own packages), would like to checkout the latest master to get the
> latest
> >>>>> released software (not everybody software projects works like this
of
> >>>>> course).
> >>>>>
> >>>>> The main issue with master right now is that it moves really fast
as
> a
> >>>>> shared branch, people merge features without warning, we see
> regressions
> >>>>> etc..
> >>>>> By the time we release a major version, master has moved so much
> that it
> >>>>> feels like starting over with the next release. It's almost as if
we
> are
> >>>>> forking our own software. CI alone (even if it were really good)
> will not
> >>>>> fix this.
> >>>>>
> >>>>> So assuming we have CI in place, we do need a better workflow (let's
> not
> >>>>> call it gitflow anymore) to self-discipline ourselves.
> >>>>>
> >>>>>>
> >>>>>> I don¹t see the use of stable master branch during the release
> either,
> >>>>>> as
> >>>>>> it reflects already released versions of the CS. And you never
cut
> the
> >>>>>> release from the stable master branch; you do cut it from *develop
-
> >>>>>> that¹s what the git workflow suggests.
> >>>>>
> >>>>> That's where our use case differs from gitflow. Several folks have
> >>>>> already mentioned that we are going to deviate from pure gitflow,
it
> is
> >>>>> just a nice framework to start creating our own workflow.
> >>>>>
> >>>>> Personally, I would love to cut the release branches from master
> (instead
> >>>>> of develop). that way you always start from a clean slate, instead
> of the
> >>>>> mess with start with right now.
> >>>>>
> >>>>> Say develop is more of a staging branch, as you have advocated.
We
> can
> >>>>> run CI/BVT on that branch (we should run it everywhere…but anyway)
> and
> >>>>> make sure features merged in work as advertized.
> >>>>>
> >>>>> When time comes to release, we cut from master and merge the features
> >>>>> that have been merged in develop already, then go into QA, merge
the
> >>>>> fixes back to develop etc….when released, we merge back to master.
> >>>>>
> >>>>> If/since we don't do rolling releases, we branch out from the main
> >>>>> version tag and do a maintenance release that leaves on, assuming
it
> >>>>> can't get merged back into master.
> >>>>>
> >>>>>>
> >>>>>>> -a clean way to merge features and bug fixes
> >>>>>>
> >>>>>> +1
> >>>>>>
> >>>>>>> -a clean way to create a release that should reduce our
time to
> release
> >>>>>>
> >>>>>> +1 Although I still think that slowness for our release was
mostly
> >>>>>> caused
> >>>>>> by the last minute regression bugs caused by missing quality
> control +
> >>>>>> lack of CI.
> >>>>>
> >>>>> True, but it is also due to the fact that we start a release branch
> from
> >>>>> a messy master where regressions happen.
> >>>>>
> >>>>>> This new way would just take off the load from RM by
> >>>>>> eliminating endless cherry-picking.
> >>>>>>
> >>>>>
> >>>>> I would love to have a workflow where the RM has a very clean job
> (pick
> >>>>> the features that should be in the release, pick the hot fixes
> release).
> >>>>> It should just be a series of git merge and that's it.
> >>>>>
> >>>>> master branch is only released software, only touched by RMs
> >>>>>
> >>>>> released branches only touched by RMs
> >>>>>
> >>>>> develop shared but merges happen only after successful CI and
> guarantee
> >>>>> of no regressions.
> >>>>>
> >>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>>
> >>> --
> >>> *Mike Tutkowski*
> >>> *Senior CloudStack Developer, SolidFire Inc.*
> >>> e: mike.tutkowski@solidfire.com
> >>> o: 303.746.7302
> >>> Advancing the way the world uses the cloud
> >>> <http://solidfire.com/solution/overview/?video=play>*™*
> >>
> >> Regards,
> >> Rohit Yadav
> >> Software Architect, ShapeBlue
> >> M. +41 779015219 | rohit.yadav@shapeblue.com
> >> Blog: bhaisaab.org | Twitter: @_bhaisaab
> >>
> >>
> >>
> >> Find out more about ShapeBlue and our range of CloudStack related
> services
> >>
> >> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> >> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/
> >
> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> >> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> >> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
> >>
> >> This email and any attachments to it may be confidential and are
> intended solely for the use of the individual to whom it is addressed. Any
> views or opinions expressed are solely those of the author and do not
> necessarily represent those of Shape Blue Ltd or related companies. If you
> are not the intended recipient of this email, you must neither take any
> action based upon its contents, nor copy or show it to anyone. Please
> contact the sender if you believe you have received this email in error.
> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue
> Services India LLP is a company incorporated in India and is operated under
> license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is a
> company incorporated in Brasil and is operated under license from Shape
> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic of
> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue is
> a registered trademark.
> >
> >
> >
> > --
> > Daan
>
> Regards,
> Rohit Yadav
> Software Architect, ShapeBlue
> M. +41 779015219 | rohit.yadav@shapeblue.com
> Blog: bhaisaab.org | Twitter: @_bhaisaab
>
>
>
> Find out more about ShapeBlue and our range of CloudStack related services
>
> IaaS Cloud Design & Build<
> http://shapeblue.com/iaas-cloud-design-and-build//>
> CSForge – rapid IaaS deployment framework<http://shapeblue.com/csforge/>
> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/>
> CloudStack Infrastructure Support<
> http://shapeblue.com/cloudstack-infrastructure-support/>
> CloudStack Bootcamp Training Courses<
> http://shapeblue.com/cloudstack-training/>
>
> This email and any attachments to it may be confidential and are intended
> solely for the use of the individual to whom it is addressed. Any views or
> opinions expressed are solely those of the author and do not necessarily
> represent those of Shape Blue Ltd or related companies. If you are not the
> intended recipient of this email, you must neither take any action based
> upon its contents, nor copy or show it to anyone. Please contact the sender
> if you believe you have received this email in error. Shape Blue Ltd is a
> company incorporated in England & Wales. ShapeBlue Services India LLP is a
> company incorporated in India and is operated under license from Shape Blue
> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil
> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is
> a company registered by The Republic of South Africa and is traded under
> license from Shape Blue Ltd. ShapeBlue is a registered trademark.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message