That seems to handle my concern :-) Erik 25. juli 2014 13:16 skrev "Rajani Karuturi" <rajani.karut...@citrix.com> følgende:
> branches will be deleted after the release or hotfix if you use the > git-flow commands. > > This would be the flow for a hotfix: > 1. branch off from the release tag on master. in this case it would be > release/4.4.0 > 2. commit the fixes in hotfix/4.4.1 > 3. do the release > 4. merge to develop > 5. merge to master and update tags > 6. delete hotfix branch > > But, I agree that there can be a problem when we wish to do 4.4.2 if we > delete the hotfix branch > > may be we should use git-flow support instead of hotfix which doesn’t > delete the branch > http://stackoverflow.com/a/16866118/201514 > > ~Rajani > > > > On 25-Jul-2014, at 12:31 pm, Daan Hoogland <daan.hoogl...@gmail.com> > wrote: > > > Rightful question Erik, > > > > Rajani mentioned that release branches will be deleted. This will only > > happen once the release is no longer supported. Any hotfix branch will > > still have to merged on that (and master possibly) until we stop > > supporting that branch. > > > > On the other hand you can branch from any commit. > > > > btw 4.4.1 is a bad example of you as we will still maintain that > > without gitflow. But it is valid for for instance 4.5.2 or 5.0.1. > > > > On Fri, Jul 25, 2014 at 8:04 AM, Erik Weber <terbol...@gmail.com> wrote: > >> This is out of my git league, but how do you handle minor versions that > way? > >> > >> Assuming 4.8.0 is the latest stable release and HEAD on master. > >> > >> Then you want to release 4.4.1. > >> > >> First of all can you develop bugfixes for 4.4 along the way, when both > >> develop and master HEAD might be hugely different? > >> > >> Second, can you commit behind HEAD? You don't want the 4.4.1 release > >> instead of 4.8.0 to be HEAD > >> > >> Someone might have good solutions to this, but if not I would propose to > >> keep the release branches for future bugfixes. > >> > >> Erik > >> 25. juli 2014 06:02 skrev "Rajani Karuturi" <rajani.karut...@citrix.com > > > >> følgende: > >> > >>> On 24-Jul-2014, at 10:25 pm, Mike Tutkowski < > mike.tutkow...@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.karut...@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.hoogl...@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.karut...@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.tutkow...@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.hoogl...@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 < > >>> 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 > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> *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 > >>>>> > >>>>> > >>>> > >>>> > >>>> -- > >>>> *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 > >
