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