cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erik Weber <terbol...@gmail.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Thu, 24 Jul 2014 06:57:19 GMT
24. juli 2014 08:39 skrev "Rajani Karuturi" <Rajani.Karuturi@citrix.com>
følgende:
>
>
> Hi Daan,
> here is what i propose:
>
> 1. rename 'master' to 'develop’
> 2. branch a new 'master' from '4.4’
> 3. branch 'RELEASE-4.5' from the develop
> 4. merge 'RELEASE-4.5' to master once the release voting is done.
>
> RELEASE-4.6 branch should be off develop as all the feature branches
would be merged there before freeze for 4.6 and would be merged to master
when the release is voted.
>
> The other question I have is in the step:4. how are we going to manage
fixes to 4.5 post branch cut?  ( assuming no features as the freeze is done)

Sub releases, ie. 4.4.1,  is generally just hotfixes / bugfixes, yes? In
that case you can branch it off 'master' and merge back to master as a new
release after voting, and merge to develop if the fix is applicable there.

Erik
>
> ~Rajani
>
>
>
> On 24-Jul-2014, at 11:52 am, Daan Hoogland <daan.hoogland@gmail.com>
wrote:
>
> > Mike, Rajani,
> >
> > Sebastien's point was that the current 4.4 is the closest we have to a
> > releasable branch. I don't mind enting on master but it will require
> > more fixing. In general all of this will require some RM work of all
> > committers. Please ammend my little proposal if you will.
> >
> > On Thu, Jul 24, 2014 at 6:27 AM, Rajani Karuturi
> > <Rajani.Karuturi@citrix.com> wrote:
> >> I agree with mike. I think we should start 4.5 from where master is now
> >> Also create a develop branch from master and continue future work for
4.6 there.
> >>
> >> I am not clear on how the release branches are going to be maintained.
> >> Are we saying we would create 4.5-RELEASE branch which is essentially
same as our current -FORWARD branch and continue cherry-picking?
> >>
> >> I would prefer merges to cherry-picks.
> >> Also, I think we should allow committers to commit to the RELEASE
branch after discussing about it on dev@ and have RM closely monitor them.
> >> Any commit intended for 4.5 RELEASE should be checked in after
discussion in the 4.5 Release branch and then merged to develop branch.
> >>
> >>
> >> ~Rajani
> >>
> >>
> >>
> >> On 24-Jul-2014, at 1:14 am, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:
> >>
> >>> Per earlier e-mails, I don't think we want to start 4.5 where 4.4
left off
> >>> and then merge features from develop into 4.5.
> >>>
> >>> Why don't we instead start 4.5 where master is now with the
assumption that
> >>> since we are past Feature Freeze for 4.5 that master is stable enough?
> >>>
> >>>
> >>> On Wed, Jul 23, 2014 at 12:56 PM, Daan Hoogland <
daan.hoogland@gmail.com>
> >>> wrote:
> >>>
> >>>> so to start formulate a proposal:
> >>>>
> >>>> all work shall be done in a new branch (it is advisable to prefix
your
> >>>> branches with your id)
> >>>> when working, features will be cherry-picked/merged into the release
> >>>> branch they are for and next into master.
> >>>> hotfixes will be done in <branchname>-hotfixes
> >>>>
> >>>> as transition we will
> >>>>
> >>>> rename 'master' to 'develop'
> >>>> branch a new 'master' from '4.4'
> >>>> branch '4.5' from the new 'master'
> >>>> merge any features from the new 'develop' to '4.5' and 'master'
> >>>>
> >>>>
> >>>>
> >>>> On Wed, Jul 23, 2014 at 6:39 PM, Sebastien Goasguen <runseb@gmail.com
>
> >>>> wrote:
> >>>>>
> >>>>> On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <runseb@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>>>
> >>>>>> On Jul 23, 2014, at 12:21 PM, Nate Gordon <nate.gordon@appcore.com>
> >>>> wrote:
> >>>>>>
> >>>>>>> Let me ask the question, why have master be develop and a release
> >>>> branch be
> >>>>>>> "master"? If we are going to follow gitflow, why not just stick
with
> >>>> the
> >>>>>>> norm? If master is the development branch, it might not be
stable. I
> >>>> think
> >>>>>>> the goal here is that we have an obvious stable branch. Anyone
could
> >>>> come
> >>>>>>> check out master and have the latest useable.
> >>>>>>
> >>>>>> I am in favor of following the norm, so ideally master should be
our
> >>>> stable branch (agreed).
> >>>>>>
> >>>>>> The issue is with the transition.
> >>>>>>
> >>>>>> Our latest releasable product is the 4.4 branch (4.4.0 tag), so
ideally
> >>>> we could start a stable branch of this tag and build up bug fix
releases
> >>>> all the way to 4.5 from there.
> >>>>>>
> >>>>>> But all features for 4.5 are already in master.
> >>>>>>
> >>>>>> So if we create a 'develop' branch of master and stabilize 'master'
> >>>> then develop is now started from a stable tag (4.4.0).
> >>>>>>
> >>>>>
> >>>>> *not* started from a stable tag, and merges will be tricky, no ?
> >>>>>
> >>>>>> So what's the best way to flip ? There is most likely some git
magic
> >>>> that can we do.
> >>>>>>
> >>>>>>
> >>>>>> The new git workflow and the transition process need to be part of
a
> >>>> proposal that we get consensus on.
> >>>>>>
> >>>>>> getting there :)
> >>>>>>
> >>>>>> -seb
> >>>>>>
> >>>>>>>
> >>>>>>> Also, I'm struggling to understand the benefit of cherry-pick. If
you
> >>>>>>> completely squash history, you lose a tremendous amount of
context,
> >>>> which I
> >>>>>>> use extensively to figure out why a bug is the way it is. Only
knowing
> >>>> that
> >>>>>>> the branch was merged at a given point in time doesn't give any
> >>>> context.
> >>>>>>> Seeing the individual commit history of the branch helps to
preserve
> >>>> the
> >>>>>>> rationale for why the code was written the way it was. In theory
if
> >>>> every
> >>>>>>> change starts out as a branch (feature, hotfix, release), then
why not
> >>>> just
> >>>>>>> merge the branch once it is in a good and acceptable state?
> >>>>>>>
> >>>>>>> I also agree with Mike that this will have to be a transition over
> >>>> time. It
> >>>>>>> will take some time to clean up master to the point where it can
be
> >>>>>>> considered a solid stable branch. Possibly as part of the 4.5
release.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, Jul 23, 2014 at 10:51 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>>>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <
daan.hoogland@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> Sebastien,
> >>>>>>>>>
> >>>>>>>>> It seems we can do what you are calling for is creating a branch
> >>>>>>>>> called 'release'. We can merge back into that branch from 4.4,
> >>>> master,
> >>>>>>>>> 4.3. I would like to see people that want a feature or bug fix
in a
> >>>>>>>>> branch make a fork of that branch and when that fork is working
do a
> >>>>>>>>> cherry-pick. The -forward concept is now used for that but it is
> >>>>>>>>> broken because more then for one piece of work there are
commits on
> >>>>>>>>> it. This caused me conflicts during the release. Especially
painfull
> >>>>>>>>> as not all was intended to get into the release. We can create
this
> >>>>>>>>> 'release' branch now on the basis of 4.4 and start pulling in
> >>>> changes.
> >>>>>>>>
> >>>>>>>> Yes, that's what I am thinking about too, so +1
> >>>>>>>>
> >>>>>>>> Our master would become the -develop- in gitflow terms
> >>>>>>>> The release branch you mention would become the -master- in
gitflow
> >>>> terms
> >>>>>>>>
> >>>>>>>> If we start now, indeed we can create 'release' from 4.4 release
tag
> >>>>>>>> (voted and shipped).
> >>>>>>>>
> >>>>>>>> That means that to create 4.5 we will need to merge features
back into
> >>>>>>>> 'release'. it might be messy because some of those features are
> >>>> already in
> >>>>>>>> our current master.
> >>>>>>>>
> >>>>>>>> But all of this will keep 'release' clean (we can keep track of
bugs
> >>>> and
> >>>>>>>> features that are in it in CHANGES file etc..)
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> There is a question of control. Do we allow all committers to
manage
> >>>>>>>>> the release? I am for that but can imagine not everybody is.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> At first I would say that only the RM can commit to 'release'.
As we
> >>>> get
> >>>>>>>> the CI in place  we could relax this and allow commits that pass
the
> >>>> CI to
> >>>>>>>> get into 'release', but right now I would vote for a tighter
control
> >>>> of
> >>>>>>>> 'release'.
> >>>>>>>>
> >>>>>>>>> rule number 1 will be: you are going to do something to the
code, you
> >>>>>>>>> start by creating a branch.
> >>>>>>>>>
> >>>>>>>>> right?
> >>>>>>>>>
> >>>>>>>>> On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen <
> >>>> runseb@gmail.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <
sam.schmit@appcore.com>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Hey everyone,
> >>>>>>>>>>>
> >>>>>>>>>>> I've been a developer for a handful of years and have had my
share
> >>>> of
> >>>>>>>>>>> experience with different version control systems.  I've used
(for
> >>>>>>>> better
> >>>>>>>>>>> or worse) Git, Perforce, Rational ClearCast, and SVN.
> >>>>>>>>>>>
> >>>>>>>>>>> Each of these solutions offers their own unique set of
features,
> >>>>>>>> strengths
> >>>>>>>>>>> and weaknesses.  As there are so many systems that are good at
> >>>> specific
> >>>>>>>>>>> things, it seems best to use the features that the chosen
system is
> >>>>>>>> best at.
> >>>>>>>>>>>
> >>>>>>>>>>> Git is great at branching, merging and using that structure to
> >>>>>>>> maintain and
> >>>>>>>>>>> control how changes get into the primary branches.  Git tools
even
> >>>> make
> >>>>>>>>>>> this easy by integrating directly into the "Gitflow" to make
> >>>> branching
> >>>>>>>> and
> >>>>>>>>>>> merging that much easier.  It would seem counter-intuitive to
NOT
> >>>> make
> >>>>>>>> use
> >>>>>>>>>>> of these built-in capabilities.
> >>>>>>>>>>>
> >>>>>>>>>>> In addition to that, I know that the current method of change
> >>>>>>>> management is
> >>>>>>>>>>> incredibly frustrating to work with, and works directly
against the
> >>>>>>>> way a
> >>>>>>>>>>> typical Git user would expect it to be structured.  I should
NEVER
> >>>> have
> >>>>>>>>>>> problem compiling and running something on master.  I should
not
> >>>> have
> >>>>>>>>>>> problems building anything on a release branch.  A
feature/bugfix
> >>>>>>>> branch is
> >>>>>>>>>>> where things can be, and often are, broken or unstable.
 There have
> >>>>>>>> been
> >>>>>>>>>>> many times working in Cloudstack where I've had to search for
a
> >>>> stable
> >>>>>>>>>>> revision on master, and that's just plain wrong.
> >>>>>>>>>>>
> >>>>>>>>>>> I do realize that having this many developers working on so
many
> >>>>>>>> features
> >>>>>>>>>>> and bugfixes will result in a large number of branches.  I
don't
> >>>>>>>> believe
> >>>>>>>>>>> this is a good argument against using a branching method,
though -
> >>>> I
> >>>>>>>>>>> believe that the current system is even more confusing and
> >>>> difficult
> >>>>>>>> to use.
> >>>>>>>>>>>
> >>>>>>>>>>> I could pontificate on change management quite a bit more,
but my
> >>>>>>>> opinion
> >>>>>>>>>>> in summary would basically be:  use Git the way it was meant
to be
> >>>>>>>> used,
> >>>>>>>>>>> and things will be better.  Just my two cents.
> >>>>>>>>>>>
> >>>>>>>>>>> Sam
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> Sam, I think we are in agreement (at least with folks who
responded
> >>>> to
> >>>>>>>> this thread).
> >>>>>>>>>> Or maybe I am not reading your mail right and you don't agree
with
> >>>> Leo ?
> >>>>>>>>>>
> >>>>>>>>>> My own take and reason for calling for a change we are
currently
> >>>> doing
> >>>>>>>> things is mostly due to the way we release.
> >>>>>>>>>>
> >>>>>>>>>> I would like to see a stable master (and I think we are in
agreement
> >>>>>>>> with that).
> >>>>>>>>>> That means that development should not happen on master and
that
> >>>> every
> >>>>>>>> commit that lands on master should be shippable.
> >>>>>>>>>>
> >>>>>>>>>> I personally have no issues with cherry-picking. So I would be
fine
> >>>>>>>> cherry picking from a hot-fix branch into master, to fix a bug.
> >>>>>>>>>> The end result is that the next commit on master would still
mean
> >>>>>>>> master is shippable/releasable.
> >>>>>>>>>>
> >>>>>>>>>> If we agree with this basic concept. The question becomes how
do we
> >>>> get
> >>>>>>>> there, considering that master is now full of dev work and
potential
> >>>> bug.
> >>>>>>>>>> The only releasable product we have are on the 4.3, 4.4 and
previous
> >>>>>>>> release branches.
> >>>>>>>>>>
> >>>>>>>>>> Ideally, I would like to see master becomes 4.4. And work our
way
> >>>> back,
> >>>>>>>> merging the new features that are already in master into the new
> >>>> master
> >>>>>>>> (based on 4.4).
> >>>>>>>>>> This could be quite complicated but we need to do it (or
something
> >>>> like
> >>>>>>>> it).
> >>>>>>>>>>
> >>>>>>>>>> To move forward, we should make a proposal to the list and
call for
> >>>> a
> >>>>>>>> vote.
> >>>>>>>>>>
> >>>>>>>>>> Any takers to start a wiki page proposing a new git process
and how
> >>>> we
> >>>>>>>> could move to it (transition path) ?
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>> -Sebastien
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons <
> >>>>>>>> LSimons@schubergphilis.com>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>> Hey folks,
> >>>>>>>>>>>>
> >>>>>>>>>>>> With 4.4.0 tagged, is now an opportune time to go and
implement
> >>>> this?
> >>>>>>>>>>>>
> >>>>>>>>>>>> I would enthousiastically +1 and get crackin', but I’m not a
> >>>>>>>> committer so
> >>>>>>>>>>>> its not that practical for me to volunteer!
> >>>>>>>>>>>>
> >>>>>>>>>>>> I wanted to point out atlassian’s description of gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!workflow-gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> which might be easier to read.
> >>>>>>>>>>>>
> >>>>>>>>>>>> Similarly, the git-flow scripts that help out with
implementing
> >>>> this
> >>>>>>>> stuff
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://github.com/nvie/gitflow
> >>>>>>>>>>>>
> >>>>>>>>>>>> they also describe the relationship between gitflow and
dealing
> >>>> with
> >>>>>>>>>>>> multiple remotes
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.atlassian.com/git/workflows#!pull-request
> >>>>>>>>>>>>
> >>>>>>>>>>>> Finally note atlassian’s free sourcetree GUI has built-in
support
> >>>> for
> >>>>>>>>>>>> git-flow
> >>>>>>>>>>>>
> >>>>>>>>>>>> http://www.sourcetreeapp.com/
> >>>>>>>>>>>>
> >>>>>>>>>>>> Because cloudstack currently is full of rebasing and
squashing and
> >>>>>>>>>>>> cherry-picking, you get very little benefit from a tree
> >>>> visualization
> >>>>>>>> tool
> >>>>>>>>>>>> (like this or gitk or ...) right now, but it would be
*great* to
> >>>> have
> >>>>>>>> going
> >>>>>>>>>>>> forward.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> cheers,
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Leo
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen <
runseb@gmail.com
> >>>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> I would like to re-start this discussion.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Rajani made some good points and someone mentioned Gitflow:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Thinking about our release procedure, we clearly need more
tests
> >>>> and
> >>>>>>>> a
> >>>>>>>>>>>> CI. However it looks like this is going to take some time.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In the meantime I think there is nothing preventing us from
> >>>> agreeing
> >>>>>>>> to
> >>>>>>>>>>>> 'git practices', we don't need tests or new infra, we just
need to
> >>>>>>>> agree on
> >>>>>>>>>>>> the git workflow.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Right now Master is really a development branch, we should
make
> >>>> it a
> >>>>>>>>>>>> stable branch for production with very few commits.
> >>>>>>>>>>>>> This does not mean that we would release less, in contrary
this
> >>>> would
> >>>>>>>>>>>> ensure that a commit to master means it's a production
release.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> In addition gitflow [1] does not do cherry-picks (gets back
to
> >>>>>>>> Rajani's
> >>>>>>>>>>>> point) everything is based on merges.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I am of the opinion that git flow provides a nice process.
It
> >>>>>>>> basically
> >>>>>>>>>>>> freezes master. Development happens in a 'develop' branch,
> >>>> releases
> >>>>>>>>>>>> branches are branched off of that and merged into master and
back
> >>>> into
> >>>>>>>>>>>> develop….etc
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Please read [1] it's a good read.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> And let's discuss,
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Sebastien
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi <
> >>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> There is also the problem of cherry-picking.
> >>>>>>>>>>>>>> As a contributor, I always endup creating multiple patches
for
> >>>> each
> >>>>>>>>>>>> branch as they don’t cleanly apply on the upward branches.
which
> >>>> means
> >>>>>>>>>>>> distinct commits for each branch and I don’t easily know
which all
> >>>>>>>> branches
> >>>>>>>>>>>> my commit exists unless I do grep.
> >>>>>>>>>>>>>> if we follow merging strategy properly, apart from the
first
> >>>> merge
> >>>>>>>> of
> >>>>>>>>>>>> the branch, everything else on top of it should be a painless
> >>>> merge.
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 02-Jun-2014, at 10:51 pm, Marcus <shadowsor@gmail.com>
> >>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I think many of the bullet points are what we are
currently
> >>>> doing
> >>>>>>>>>>>>>>> (guidelines for commit comments, feature branches need to
stay
> >>>> in
> >>>>>>>> sync
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>> master, no back-merging). I also think that much of what
we do
> >>>> now
> >>>>>>>> is
> >>>>>>>>>>>> done
> >>>>>>>>>>>>>>> the way it is simply because there *are* vast changes
between
> >>>>>>>> versions.
> >>>>>>>>>>>>>>> Classes are getting shuffled around and changed all the
time.
> >>>> If
> >>>>>>>> its
> >>>>>>>>>>>>>>> feasible to merge branch fixes to master, that's fine,
but some
> >>>>>>>> quick
> >>>>>>>>>>>> tests
> >>>>>>>>>>>>>>> seem to indicate that this will be messy getting started.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> That leaves us with how we do releases. I'm fine with
having
> >>>> single
> >>>>>>>>>>>>>>> branches for major releases(4.3) and tagging the commits
where
> >>>> each
> >>>>>>>>>>>>>>> incremental release (4.3.x) is done. I'm trying to
remember
> >>>> why we
> >>>>>>>> went
> >>>>>>>>>>>>>>> with the -forward, I'm sure it's in the mailing list
> >>>> somewhere, but
> >>>>>>>>>>>> one of
> >>>>>>>>>>>>>>> the nice things it provides is the ability for the release
> >>>> manager
> >>>>>>>> to
> >>>>>>>>>>>>>>> control what changes are made during code freeze while
giving
> >>>>>>>> people a
> >>>>>>>>>>>>>>> place to stage fixes (though admittedly this is not always
> >>>>>>>> followed).
> >>>>>>>>>>>>>>> Without -forward, would the flow be for each dev to have
their
> >>>> own
> >>>>>>>>>>>> repo and
> >>>>>>>>>>>>>>> issue pull requests for bugfixes?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Any other suggestions/objections/comments??
> >>>>>>>>>>>>>>>> Can we discuss this in detail and agree to a process??
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi <
> >>>>>>>>>>>> Rajani.Karuturi@citrix.com>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Yes as mike said, if its a one-off case we can do a
empty
> >>>>>>>>>>>> merge(merge -s
> >>>>>>>>>>>>>>>> ours) for it and git will assume its merged but will not
> >>>> bring in
> >>>>>>>> any
> >>>>>>>>>>>>>>>> changes.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> If the branches diverged a lot, for example after a
major
> >>>>>>>> rewrite, we
> >>>>>>>>>>>>>>>> could stop merging to that branch and above and make the
fix
> >>>>>>>> manually.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski <
> >>>>>>>>>>>>>>>> mike.tutkowski@solidfire.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Yep, that's what I was referring to in that a
particular fix
> >>>>>>>> for an
> >>>>>>>>>>>> old
> >>>>>>>>>>>>>>>>>> release may not apply to newer versions. That does
happen.
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> We used to mark those as "don't need to merge to
branch x"
> >>>> in
> >>>>>>>> SVN
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>> then
> >>>>>>>>>>>>>>>>>> you handed it however made sense on the applicable
> >>>> branch(es).
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner <
> >>>>>>>>>>>>>>>> Stephen.Turner@citrix.com>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> What happens if a fix isn't relevant for newer
versions, or
> >>>>>>>> has to
> >>>>>>>>>>>> be
> >>>>>>>>>>>>>>>>>>> rewritten for newer versions because the code has
changed?
> >>>>>>>> Don't
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>>>> branches diverge and you end up cherry-picking after
that?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Stephen Turner
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>> From: Mike Tutkowski [mailto:
mike.tutkowski@solidfire.com]
> >>>>>>>>>>>>>>>>>>> Sent: 30 May 2014 18:48
> >>>>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org
> >>>>>>>>>>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I think this flow is something we should seriously
> >>>> consider.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I find cherry picking from branch to branch to be
error
> >>>> prone
> >>>>>>>> in
> >>>>>>>>>>>> that
> >>>>>>>>>>>>>>>> it's
> >>>>>>>>>>>>>>>>>>> easy for someone to forget to cherry pick to all
applicable
> >>>>>>>>>>>> branches
> >>>>>>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>> you don't have any easy way to see the cherry picks
are
> >>>>>>>> related.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> When I worked at HP, we had automated tools check to
see
> >>>> if you
> >>>>>>>>>>>>>>>> checked a
> >>>>>>>>>>>>>>>>>>> fix into a prior release, but not later releases. In
such a
> >>>>>>>>>>>> situation,
> >>>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>> either 1) forgot to perform the check-in or 2) the
check-in
> >>>>>>>> was no
> >>>>>>>>>>>>>>>> longer
> >>>>>>>>>>>>>>>>>>> applicable in the later release(s), so you needed to
mark
> >>>> it as
> >>>>>>>>>>>>>>>>>>> un-necessary (SVN supported this ability...not sure
about
> >>>> Git).
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi <
> >>>>>>>>>>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Our current git workflow is confusing with the
*forward
> >>>>>>>> branches
> >>>>>>>>>>>> and
> >>>>>>>>>>>>>>>>>>>> cherry-picking. Its hard to track on what all
releases the
> >>>>>>>> commit
> >>>>>>>>>>>> has
> >>>>>>>>>>>>>>>>>>>> gone into unless I do some git log greping. Also, as
a
> >>>>>>>>>>>> contributor, I
> >>>>>>>>>>>>>>>>>>>> endup creating patches for each branch as it doesn’t
> >>>> cleanly
> >>>>>>>>>>>> apply on
> >>>>>>>>>>>>>>>>>>>> different branches.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> I think we should have some guidelines. Here is what
I
> >>>>>>>> propose.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> 1.  There should be branch for every major
release(ex:
> >>>> 4.3.x,
> >>>>>>>>>>>> 4.4.x,
> >>>>>>>>>>>>>>>>>>>> 5.0.x,5.1.x) and the minor releases should be tagged
> >>>>>>>> accordingly
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> the respective branches.
> >>>>>>>>>>>>>>>>>>>> 2.  The branch naming convention is to be followed.
Many
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> with 4.3, 4.3.0, 4.3.1 etc. is confusing
> >>>>>>>>>>>>>>>>>>>> 3.  Cherry-picking should be avoided. In git, when we
> >>>>>>>> cherry-pick,
> >>>>>>>>>>>>>>>>>>>> we have two physically distinct commits for the same
> >>>> change or
> >>>>>>>>>>>> fix and
> >>>>>>>>>>>>>>>>>>>> is difficult to track unless you do cherry-pick -x
> >>>>>>>>>>>>>>>>>>>> 4.  There should always be a continous flow from
release
> >>>>>>>> branches
> >>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>>>>> master. This doesn’t mean cherry-picking. They
should be
> >>>>>>>>>>>> merged(either
> >>>>>>>>>>>>>>>>>>>> ff or no-ff) which retains the commit ids and easily
> >>>> trackable
> >>>>>>>>>>>> with
> >>>>>>>>>>>>>>>>>>>> git branch --contains
> >>>>>>>>>>>>>>>>>>>> *   Every bug fix should always flow from minimal
release
> >>>>>>>> uptill
> >>>>>>>>>>>>>>>>>>>> master. A bug isnt fixed until the fix reaches
master.
> >>>>>>>>>>>>>>>>>>>> *   For ex. A bug 4.2.1 should be committed to
> >>>>>>>>>>>>>>>>>>>> 4.2.x->4.3.x->4.4.x->master
> >>>>>>>>>>>>>>>>>>>> *   If someone forgets to do the merge, the next
time a
> >>>> new
> >>>>>>>> commit
> >>>>>>>>>>>>>>>>>>> is
> >>>>>>>>>>>>>>>>>>>> done this will also get merged.
> >>>>>>>>>>>>>>>>>>>> 5.  There should always be a continuous flow from
master
> >>>> to
> >>>>>>>>>>>> feature
> >>>>>>>>>>>>>>>>>>>> branches. Meaning all feature branch owners should
> >>>> proactively
> >>>>>>>>>>>> take
> >>>>>>>>>>>>>>>>>>>> any new commits from master by doing a merge from
master
> >>>>>>>>>>>>>>>>>>>> 6.  The commits from feature branch will make to
master on
> >>>>>>>> code
> >>>>>>>>>>>>>>>>>>>> complete through a merge.
> >>>>>>>>>>>>>>>>>>>> 7.  There should never be a merge from master to
release
> >>>>>>>> branches
> >>>>>>>>>>>>>>>>>>>> 8.  Every commit in LTS branch(targetted to any minor
> >>>> release)
> >>>>>>>>>>>>>>>>>>>> should have atleast bug id and correct author
information
> >>>>>>>>>>>>>>>>>>>> *   Cassandra's template: patch by <author>;
reviewed by
> >>>>>>>>>>>>>>>> <committer>
> >>>>>>>>>>>>>>>>>>>> for CASSANDRA-<ticket>
> >>>>>>>>>>>>>>>>>>>> 9.  Once the release branch is created(after code
freeze),
> >>>>>>>> any bug
> >>>>>>>>>>>>>>>>>>>> in jira can be marked with fix version current
> >>>> release(4.4)
> >>>>>>>> only
> >>>>>>>>>>>> on
> >>>>>>>>>>>>>>>>>>>> RM's approval and only they can go to the release
branch.
> >>>>>>>> This
> >>>>>>>>>>>> can be
> >>>>>>>>>>>>>>>>>>>> done through jira and with certain rules.(may be
using
> >>>> jira
> >>>>>>>> vote?)
> >>>>>>>>>>>>>>>>>>>> this would save the cherry-picking time and another
branch
> >>>>>>>>>>>>>>>> maintenance.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Please add your thoughts/suggestions/comments.
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ref:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html
> >>>>>>>>>>>>>>>>>>>> https://www.youtube.com/watch?v=AJ-CpGsCpM0
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> ~Rajani
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> *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
>*™*
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>> *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>*™*
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Daan
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>>
> >>>>>>>
> >>>>>>> *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.
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> 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>*™*
> >>
> >
> >
> >
> > --
> > Daan
>

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