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 <run...@gmail.com> wrote: > > On Jul 23, 2014, at 12:30 PM, Sebastien Goasguen <run...@gmail.com> wrote: > >> >> On Jul 23, 2014, at 12:21 PM, Nate Gordon <nate.gor...@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 <run...@gmail.com> >>> wrote: >>> >>>> >>>> On Jul 23, 2014, at 11:38 AM, daan Hoogland <daan.hoogl...@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 <run...@gmail.com> >>>> wrote: >>>>>> >>>>>> On Jul 23, 2014, at 11:19 AM, Sam Schmit <sam.sch...@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 < >>>> lsim...@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 <run...@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.karut...@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 <shadow...@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.karut...@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.karut...@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.tutkow...@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.tur...@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.tutkow...@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.karut...@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.tutkow...@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.tutkow...@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.gor...@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
