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 Wed, 23 Jul 2014 18:56:26 GMT
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

Mime
View raw message