I suppose we need a formal VOTE on this? If so, perhaps Sebastien would like to call it.
On Thu, Jul 24, 2014 at 10:06 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > Great. Well, this seems reasonable to me then. > > If there are no objections or further comments, when can this be done and > who would do it? > > Thanks > > > On Thu, Jul 24, 2014 at 10:01 PM, Rajani Karuturi < > rajani.karut...@citrix.com> wrote: > >> 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>*™* >> >> > > > -- > *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>*™*
