On Jul 8, 2014, at 2:20 PM, Nate Gordon <nate.gor...@appcore.com> wrote:
> As someone who has worked with a number of different version control > systems (and have far more love for git than any other), I'm curious as to > why we would want to fight what I've always seen as the core feature of > git. Branching and merging. The gitflow model is incredibly useful for > keeping track of a number of different development paths concurrently. > Branches remained organized and have a clear destination and workflow that > they need to go through as part of the merging process. We use it > internally (on a much smaller team) with great success. And with the > difficulties I've seen on the mailing list around the -forward branches and > cherry-picking,I'm curious as to why this is the preferred method. I don't think it's the preferred method. I see it as 'the method currently used'. I think we need to change. > From > everything I've read about git and cherry-picking, it is a copy of the > commit, not a reference to the original commit. This makes it hard to track > down an individual change to find the original source. > > Thanks, > > -Nate > > > On Tue, Jul 8, 2014 at 11:04 AM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> Thanks for bringing this up again, Sebastien. >> >> I've had http://nvie.com/posts/a-successful-git-branching-model/ up in >> Chrome since you sent that link and been reading through it a bit here and >> there, but have just been too busy as of late to give it a bunch of >> thought. >> >> I agree, though, that we should really think about moving to another model >> of using Git as it is not un-common for master to be broken, which leads to >> a lot of lost development time for many people. >> >> >> On Mon, Jun 30, 2014 at 4:09 PM, 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>*™* >>>>>>> >>>>>> >>>>>> >>>> >>> >>> >> >> >> -- >> *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>*™* >> > > > > -- > > > *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.
