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>*™*
