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. >
