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
