cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [DISCUSS][PROPOSAL] git workflow
Date Fri, 25 Jul 2014 04:21:08 GMT
I suppose we need a formal VOTE on this?

If so, perhaps Sebastien would like to call it.


On Thu, Jul 24, 2014 at 10:06 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Great. Well, this seems reasonable to me then.
>
> If there are no objections or further comments, when can this be done and
> who would do it?
>
> Thanks
>
>
> On Thu, Jul 24, 2014 at 10:01 PM, Rajani Karuturi <
> Rajani.Karuturi@citrix.com> wrote:
>
>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski <mike.tutkowski@solidfire.com>
>> wrote:
>>
>> > I believe I agree with these steps.
>> >
>> > A couple questions:
>> >
>> > Is 'master' simply always going to be equal to what's the most recent
>> > version of the code that's in production?
>>
>> I think so. master will always be at the latest release and all the
>> previous releases properly tagged. The release branches would be deleted
>> once release is done.
>>
>> >
>> > Also, would 'develop' be for 4.6 code then and 4.5 code would go
>> directly
>> > into RELEASE-4.5?
>> >
>>
>> Yes. 4.6 work should be done on develop branch and any 4.5 bug fixes
>> should be done on the 4.5 branch.
>>
>>
>>
>> ~Rajani
>>
>>
>> >
>> > On Thu, Jul 24, 2014 at 12:39 AM, Rajani Karuturi <
>> > Rajani.Karuturi@citrix.com> wrote:
>> >
>> >>
>> >> 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)
>> >>
>> >> ~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
>> >>
>> >>
>> >
>> >
>> > --
>> > *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>*™*
>



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