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 Wed, 23 Jul 2014 17:01:55 GMT
Must it start today, or when (if) the vote passes? Feature freeze for 4.5
has theoretically passed, so basically master branch should now be work in
progress towards a stable branch.

So I'd say; create a 'develop' branch off the current master.

Keep master as is, and only merge bugfixes until it is deemed stable and
4.5 is released.

4.6 development and new features goes into branches of 'develop'.

Erik
23. juli 2014 18:30 skrev "Sebastien Goasguen" <runseb@gmail.com> følgende:

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

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