cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [VOTE] git workflow
Date Thu, 07 Aug 2014 21:11:41 GMT
I admit that I'm a bit confused, as well, regarding the value of 'master'
if it only points to the most recently released version of CloudStack.

If you want the most recently released version, you can just go back in
time - as necessary - to arrive at the applicable commit.

I think the problem we really want to solve relates to the constant
instability of our work-in-progress branch (currently called 'master').
Without consideration for CI, our new 'develop' branch simply assumes all
of the faults currently associated with 'master'.

The way I see us taking a step toward solving the real problem is via what
Alena mention:

 * develop branch as a staging branch
 * merging develop branch to master on a regular basis after the CI test
passes
 * cut release branch from the stable master branch when its time for the
release


On Thu, Aug 7, 2014 at 2:44 PM, Alena Prokharchyk <
Alena.Prokharchyk@citrix.com> wrote:

> Daan, thank you. Please see my comments inline.
>
>
> On 8/7/14, 1:19 PM, "Daan Hoogland" <daan.hoogland@gmail.com> wrote:
>
> >On Thu, Aug 7, 2014 at 7:23 PM, Alena Prokharchyk
> ><Alena.Prokharchyk@citrix.com> wrote:
> >> Plus if you read the discussion below the article, you will see that
> >> people agree that this model doesn’t work well for the case when the
> >> product support maintenance for older releases, like CS does.
> >
> >Not at all, Alena. I don't agree that this model won't work for CS and
> >I think you are over estimating the amount of people that think so.
> >This model does work using support branches. It will work very well in
> >the CS case and is not very far removed from what we are doing right
> >now. There will always be port work when fixes in older versions need
> >to be made. You don't merge back support branches to tag the
> >maintainance release on the master branch. The fix-release-tag can
> >remain on the branche whether it is merged back or not. The witch hunt
> >on cherry picking is only perceived. There will be occasions it is
> >necessary but seldom so.
>
>
> Does it mean that our master branch will miss the fixes from support
> branches? Or you say we should cherry-pick them all on the top of the
> master branch.
>
> Again, I don’t see how maintaining master branch to reflect the latest
> release branch, can stabilize our release process. You will still continue
> to cut the release branches from *develop, which you can’t really call
> “stable” with this model.
>
>
> I’m still convinced that the best solution in our case would be
> introducing:
>
>  * develop branch as a staging branch
>  * merging develop branch to master on a regular basis after the CI test
> passes
>  * cut release branch from the stable master branch when its time for the
> release
>
>
> I’m really trying to find the advantages of git-flow model where master
> reflects the latest release branch, and can’t find any considering that in
> the CS we are still going to keep those release/support branches, and if
> people need the latest release code, they can simply get it from there.
>
> From the developer stand point, I would be more interested in getting the
> latest stable code, not the latest stable release. And with the model I
> propose, that would be the master branch you get the latest stable code
> from.
>
> From release management perspective, I would be more interested in cutting
> the release branches from the stable branch - gitflow suggests to cut it
> them from *develop branch rather than master - and *develop is not a
> stable branch. I don’t see the use of stable master branch during the
> release, as it reflects already released versions of the CS.
>
> May be I am missing the point. Would appreciate people explaining the
> purpose of a git-flow way of keeping master branch, to solve the existing
> CS problems. Just because “its a best practice for others” doesn’t sound
> very convincing.
>
>
> >
> >>
> >> "I think this model does not work for bugfixing in older releases,
> >>though.
> >> It messes up the neat ordering.
> >>
> >> 1. Say we have released Version 1.0.1 and later added features and
> >> released 1.1.0.
> >> 2. We discover a bug in 1.0.1 and want to fix it in both version
> >> 3. We have to add 1.0.2 after 1.1.0 in master and then directly atfer
> >>(or
> >> before) also 1.1.1.”
> >
> >No this is not true. You can branch 1.0.1 to make 1.0.2 and merge
> >after it is done,
>
>
>
>
> >
>
> Merge on a top of 1.1.0, which is the top of master branch?
>
>
>
>
> >next you can branch from 1.1.0 to make 1.1.1  and
> >merge that.
> >the commits that point to 1.0.2 and 1.1.1 wil not be
> >removed when deleting the branches and when the fixes are the same and
> >the merge of 1.0.2 is clean they 1.1.0 doesn't even have to be
> >branched. if 1.0.1 or 1.0.2 is a conflicting fix then yes. that is the
> >one exception. you don't merge back. you keep the support branch.
> >
> >This is not to far from what we do right now except that we keep old
> >branches preemptively right now.
> >
> >>
> >>
> >> Thanks,
> >> Alena.
> >>
> >> On 8/7/14, 10:19 AM, "Alena Prokharchyk" <Alena.Prokharchyk@citrix.com>
> >> wrote:
> >>
> >>>Not quite. That’s what the article suggests:
> >>>
> >>>"If you want to fix bugs for older releases or do any other develop
> >>>there,
> >>>you will fork a support branch from the appropriate commit in master
> >>>(you
> >>>will have all versions ever created there). These branches are just
> >>>started and not intended to be merged back to master nor develop. This
> >>>is
> >>>usually fine, as fixes to "ancient" releases or features requested by
> >>>customers to be implemented in "ancient" releases can't or should not go
> >>>back into master. If you still think, you want to port a fix to your
> >>>main
> >>>development line (represented by master and develop), just start a
> >>>hotfix,
> >>>cherry-pick your changes and finish the hotfix."
> >>>
> >>>
> >>>That doesn’t seem right to me - that NOT ALL the fixes done to
> >>>4.2.1/4.3.1
> >>>maintenance releases for example, will go back to master/develop? Plus
> >>>it
> >>>suggests “cherry-picking” stuff if we decide that some fixes worth being
> >>>back ported. Cherry-picking again? :) Defeats our cherry-pick witch hunt
> >>>purpose. I think ALL fixes done to any forked branch, should make it
> >>>into
> >>>master via merge.
> >>>
> >>>
> >>>On 8/7/14, 6:39 AM, "Tracy Phillips" <tracphil@weberize.com> wrote:
> >>>
> >>>>Alena,
> >>>>
> >>>>Check this out and see if it would resolve your concern regarding
> >>>>maintaining multiple releases
> >>>>
> >>>>
> http://stackoverflow.com/questions/16562339/git-flow-and-master-with-mu
> >>>>lt
> >>>>i
> >>>>ple-parallel-release-branches
> >>>>
> >>>>git-flow uses support branches to support releases that are not on
> >>>>master.
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>
> >>>>On Wed, Aug 6, 2014 at 6:28 PM, Alena Prokharchyk <
> >>>>Alena.Prokharchyk@citrix.com> wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 8/6/14, 3:18 PM, "Sebastien Goasguen" <runseb@gmail.com>
wrote:
> >>>>>
> >>>>> >[top posting, apologies in advance]
> >>>>> >
> >>>>> >I am on vacation, so I will go straight to it :)
> >>>>> >
> >>>>> >This all discussion is not about gitflow specifically, it is
about
> >>>>> >modifying our git workflow and our commit practices to something
> >>>>>more
> >>>>> >standard that can:
> >>>>> >
> >>>>> >- ultimately help improve quality (in itself it won't but it
can
> >>>>>help
> >>>>>lay
> >>>>> >a foundation)
> >>>>> >- provide a stable master (it keeps breaking, it has regressions,
it
> >>>>> >moves really fast etc..)
> >>>>> >- help cut releases
> >>>>> >
> >>>>> >Any committer has write privileges and can do whatever it wants
to
> >>>>>the
> >>>>> >repos, so we need to get a nice big consensus on what problems
we
> >>>>>are
> >>>>> >trying to solve, and how best to get there. So let's not make
this a
> >>>>> >debate of yeah or neah gitflow.
> >>>>> >
> >>>>> >A better CI is coming but it's not yet there and we have no
ETA.
> >>>>>Even
> >>>>> >with a CI infra in place, we will need commit discipline to
improve
> >>>>> >quality (covertity, unitests, simulator tests). Changing our
git
> >>>>>commit
> >>>>> >practices has no cost (just emails and self discipline), so
can we
> >>>>>agree
> >>>>> >to do that first ?
> >>>>> >
> >>>>> >Here are couple high level things that I have in mind ( and
I
> >>>>>confess
> >>>>>I
> >>>>> >have not read the entire threads on this yet and ti ma conflict
with
> >>>>> >gitflow).
> >>>>> >
> >>>>> >-Master: what goes in master is only something that has been
put
> >>>>>into
> >>>>>a
> >>>>> >release (aside from the maintenance releases fixes maybe...).
Master
> >>>>>is
> >>>>> >the base for any release branch (until we get to 4.5, master
will
> >>>>>still
> >>>>> >see some high churn to stabilize it, after 4.5 release branch
is cut
> >>>>>we
> >>>>> >should enter into a stable master mode).
> >>>>>
> >>>>>
> >>>>> Sebastian, we can’t adopt this particular high level thing - when
> >>>>>master
> >>>>> reflects the latest stable release with the tags for all previous
> >>>>>releases
> >>>>> - because support maintenance releases for multiple CS versions
in
> >>>>> parallel. And while master’s latest version is 4.4, 4.2.1 and
4.3.1
> >>>>>can
> >>>>>be
> >>>>> released. And there is no way to merge them back to master w/o
> >>>>>breaking
> >>>>> the branch history.
> >>>>>
> >>>>> The model when master reflects the latest released branch, can be
> >>>>>used
> >>>>>for
> >>>>> the systems with rolling upgrades only, no maintenance releases
for
> >>>>> previous versions of the software.
> >>>>>
> >>>>> To get more details, please read the latest email exchange (today’s)
> >>>>>on
> >>>>> git workflow between me/Rohit and Dave Nalley.
> >>>>>
> >>>>>
> >>>>>
> >>>>> >
> >>>>> >-Release: from the time a release branch is cut, features are
only
> >>>>>merged
> >>>>> >by RM. hot fixes are only merged by RM. the RM is responsible
for
> >>>>>the
> >>>>> >entire release process. Since he defines the scope and is the
> >>>>>primary
> >>>>> >person responsible to check BVT for the release branch he should
be
> >>>>>able
> >>>>> >to release on-time. Major release gets merged back into master.
> >>>>> >
> >>>>> >-Devs: folks working on features and fixes are responsible to
merge
> >>>>>into
> >>>>> >the develop branch and call the RM for a merge into a release
branch
> >>>>> >(this may vary with gitflow, where release branch is cut from
> >>>>>develop)
> >>>>> >
> >>>>> >Once we have CI, it should run on every branch.
> >>>>> >
> >>>>> >-sebastien
> >>>>> >
> >>>>> >
> >>>>> >On 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.
> >>>>> >>
> >>>>> >> -Alena.
> >>>>> >>
> >>>>> >> On 8/6/14, 2:30 PM, "Edison Su" <Edison.su@citrix.com>
wrote:
> >>>>> >>
> >>>>> >>>
> >>>>> >>>
> >>>>> >>>> -----Original Message-----
> >>>>> >>>> From: Alena Prokharchyk [mailto:Alena.Prokharchyk@citrix.com]
> >>>>> >>>> Sent: Wednesday, August 06, 2014 12:59 PM
> >>>>> >>>> To: dev@cloudstack.apache.org
> >>>>> >>>> Subject: Re: [VOTE] git workflow
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>> On 8/6/14, 12:52 PM, "Erik Weber" <terbolous@gmail.com>
wrote:
> >>>>> >>>>
> >>>>> >>>>> On Wed, Aug 6, 2014 at 9:21 PM, Alena Prokharchyk
<
> >>>>> >>>>> Alena.Prokharchyk@citrix.com> wrote:
> >>>>> >>>>>
> >>>>> >>>>>> Agree with you, Rohit. The changes to the
git model we use,
> >>>>>are
> >>>>> >>>>>> needed  indeed. But we should address only
the problems that
> >>>>>CS
> >>>>> >>>>>>faces,
> >>>>> >>>>>> and the  main problem - quality control.
The proposal should
> >>>>>be
> >>>>> >>>>>> limited just to the  changes that are really
needed for the
> >>>>>CS,
> >>>>>and
> >>>>> >>>>>> that will work with the  current CS model
(minor maintenance
> >>>>> >>>>>>releases
> >>>>> >>>>>> support is a part of it)
> >>>>> >>>>>>
> >>>>> >>>>>>
> >>>>> >>>>>
> >>>>> >>>>> Theoretically you don't really have to change
anything other
> >>>>>than
> >>>>> >>>>> merging instead of cherry picking.
> >>>>> >>>>> That is the main issue from a release perspective.
> >>>>> >>>>>
> >>>>> >>>>> But I still think there are good reasons to
do so;
> >>>>> >>>>>
> >>>>> >>>>> 1) using a well known way of handling code/releases
instantly
> >>>>>tells
> >>>>> >>>>>new
> >>>>> >>>>> contributors / committers how we work. add
to the fact that
> >>>>>there
> >>>>> >>>>> exists tools to help doing this correctly is
a bonus.
> >>>>> >>>>> 2) having a known stable (atleast in theory)
release as master
> >>>>>is
> >>>>> >>>>>good
> >>>>> >>>>> practice. although not many users will be running
from git, i
> >>>>>still
> >>>>> >>>>> consider it to be good practice.
> >>>>> >>>>> 3) there is a huge belief in this thread/discussion
that as
> >>>>>long
> >>>>>as
> >>>>> >>>>> something passes CI / BVT it is considered
stable. The fact is
> >>>>>that
> >>>>> >>>>>it
> >>>>> >>>>> is not. Take the recent 4.4 release as a good
example, where a
> >>>>>new
> >>>>> >>>>> install was not working at all at the point
of release. Now,
> >>>>>this
> >>>>>is
> >>>>> >>>>> more a CI / test coverage issue than git workflow
issue, but i
> >>>>>find
> >>>>> >>>>>it
> >>>>> >>>>> weird to use as an argument for not improving
the workflow.
> >>>>> >>>>>
> >>>>> >>>>> --
> >>>>> >>>>> Erik
> >>>>> >>>>
> >>>>> >>>> I¹m not arguing against keeping master release
stable; I
> >>>>>advocate
> >>>>>for
> >>>>> >>>> it.
> >>>>> >>>
> >>>>> >>> +1, we need to take action to make sure master is stable.
Frankly
> >>>>> >>> speaking,
> >>>>> >>> I don't want to fix the regression on the master, I
assume nobody
> >>>>>want
> >>>>> >>>to
> >>>>> >>> do that.
> >>>>> >>> Here is the list of regression issues(not introduced
by myself) I
> >>>>>fixed
> >>>>> >>> on master after 4.4:
> >>>>> >>>
> >>>>> >>> CLOUDSTACK-7123
> >>>>> >>> CLOUDSTACK-7110
> >>>>> >>> CLOUDSTACK-7166
> >>>>> >>> CLOUDSTACK-7164
> >>>>> >>> Most of this issues will be caught even by a simulator
BVT. I
> >>>>>want
> >>>>>to
> >>>>> >>> make it clear, that,
> >>>>> >>> If we don't take action to reduce/eliminate the regression
as
> >>>>>much
> >>>>>as
> >>>>> >>> possible in the future, I will not fix any of this
regression
> >>>>>issues.
> >>>>> >>> I remember there is discussion about setting up a staging
branch,
> >>>>>run
> >>>>> >>>BVT
> >>>>> >>> against it for each commit, what's the conclusion if
any? Why so
> >>>>> >>> difficult to make it happen? Is there anything I can
help to make
> >>>>>it
> >>>>> >>> happen?
> >>>>> >>>
> >>>>> >>>> But we can¹t adopt git workflow way of keeping
master branch to
> >>>>>be
> >>>>>a
> >>>>> >>>> reflection of the latest release branch. It will
not work with
> >>>>>our
> >>>>>way
> >>>>> >>>> of
> >>>>> >>>> handling maintenance releases for multiple versions
of CS - see
> >>>>> >>>>another
> >>>>> >>>> thread.
> >>>>> >>>
> >>>>> >>>
> >>>>> >>> +1, I'll -1 on any of proposal, if it doesn't solve
problem most
> >>>>>of
> >>>>>us
> >>>>> >>> are concerning about.
> >>>>> >>>
> >>>>> >>>>
> >>>>> >>>> Instead, master branch should reflect the latest
code that
> >>>>>passed
> >>>>>the
> >>>>> >>>> CI test
> >>>>> >>>> (the code merged from *develop after CI passes).
The release
> >>>>>branches
> >>>>> >>>> should be cut from stable master branch - it will
ensure that we
> >>>>>won¹t
> >>>>> >>>> face
> >>>>> >>>> last minute blockers as for 4.4, because master
IS a stable
> >>>>>branch.
> >>>>> >>>> And yes, we should do merges instead of cherry
picking.
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>
> >>>>> >>>>>
> >>>>> >>>
> >>>>> >>
> >>>>> >
> >>>>>
> >>>>>
> >>>
> >>
> >
> >
> >
> >--
> >Daan
>
>


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

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