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