That's where the 4.5-hotfixes branch comes in. On Thu, Jul 24, 2014 at 8: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 >
-- Daan
