cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Thu, 24 Jul 2014 06:22:05 GMT
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
View raw message