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:32:19 GMT
24. juli 2014 06:28 skrev "Rajani Karuturi" <Rajani.Karuturi@citrix.com>
følgende:
>
> 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?

After feature freeze or whenever it's decided to finish a release you
create a branch called release-version, e.g. release-4.6.

>From then on 'develop' focus is on 4.7 or whatever the next version is
called.

Whenever something gets merged to release-4.6 it should also get merged to
develop.

> I would prefer merges to cherry-picks.

A lot of the point in this workflow is visibility / traceability, so
merging should really be the way we work

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

If code is merged instead of cherry-picked it is easier to see / trace what
has happened , and potentially revert.

It is important though that RM's job isn't made much more difficult to
manage .

Erik

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

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