24. juli 2014 08:39 skrev "Rajani Karuturi" <rajani.karut...@citrix.com> følgende: > > > 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)
Sub releases, ie. 4.4.1, is generally just hotfixes / bugfixes, yes? In that case you can branch it off 'master' and merge back to master as a new release after voting, and merge to develop if the fix is applicable there. Erik > > ~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 >
