24. juli 2014 06:28 skrev "Rajani Karuturi" <rajani.karut...@citrix.com> følgende: > > 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?
After feature freeze or whenever it's decided to finish a release you create a branch called release-version, e.g. release-4.6. >From then on 'develop' focus is on 4.7 or whatever the next version is called. Whenever something gets merged to release-4.6 it should also get merged to develop. > I would prefer merges to cherry-picks. A lot of the point in this workflow is visibility / traceability, so merging should really be the way we work > 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. If code is merged instead of cherry-picked it is easier to see / trace what has happened , and potentially revert. It is important though that RM's job isn't made much more difficult to manage . Erik > 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>*™* >
