Return-Path: X-Original-To: apmail-cloudstack-dev-archive@www.apache.org Delivered-To: apmail-cloudstack-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 9908E10AA6 for ; Wed, 23 Jul 2014 15:52:47 +0000 (UTC) Received: (qmail 15816 invoked by uid 500); 23 Jul 2014 15:52:47 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 15772 invoked by uid 500); 23 Jul 2014 15:52:47 -0000 Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cloudstack.apache.org Delivered-To: mailing list dev@cloudstack.apache.org Received: (qmail 15760 invoked by uid 99); 23 Jul 2014 15:52:46 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jul 2014 15:52:46 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of runseb@gmail.com designates 209.85.220.47 as permitted sender) Received: from [209.85.220.47] (HELO mail-pa0-f47.google.com) (209.85.220.47) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 23 Jul 2014 15:52:44 +0000 Received: by mail-pa0-f47.google.com with SMTP id kx10so1971548pab.34 for ; Wed, 23 Jul 2014 08:52:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=YJ92TdCZx27dz5Ld+HhNX5+tSF1/r2UjUn7/igVZJYc=; b=mC3Tq/N5arZ3CiKclW+GTy8NcvHRo84+ynhbxgydjIXZzFPAXg+a7maXW/VIiQ4dmD 1xYYj4SSWBWkAtcjwy69opA7Hqp3qX8kNKTD5EtG3vZQaV3G/LJc+Zeiym1+po7W6Db2 MMZ9JCYnu/fq32bR8/sHVChw8X9XYmiV5t82CyI8mcAZDGY5JbZb0U7sgzzjwkHiBChR NMz4o+McBndvvUeAMQExr0Hpp1sznvUqhl81330bqashhnUL8ocspuiY/sq0XKfPk7lQ qjZJaovKT/4pVZVPZlbLVwr1hyig8Nk7l7bV2JfrrUaq9pQ12QhSnIfZqeltCe3LBUGH NCww== X-Received: by 10.66.122.36 with SMTP id lp4mr3021285pab.82.1406130739169; Wed, 23 Jul 2014 08:52:19 -0700 (PDT) Received: from [10.10.2.140] ([67.139.178.66]) by mx.google.com with ESMTPSA id qj1sm2767480pbb.24.2014.07.23.08.52.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 23 Jul 2014 08:52:17 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Subject: Re: [DISCUSS][PROPOSAL] git workflow From: Sebastien Goasguen In-Reply-To: Date: Wed, 23 Jul 2014 11:51:43 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <080A05D2-DD56-4737-A5C7-48DD11D0E30F@gmail.com> References: <85B56B1AEDD2674A82DEC8B61E12182930D691@AMSPEX01CL01.citrite.net> <3A3E69CA-D21B-4F3E-835D-EAD91765A7CC@citrix.com> <02D48BBC-A209-418D-9263-BDEF88E77A10@gmail.com> <18633580-1245-430C-A4DF-5853177F9C97@gmail.com> To: dev@cloudstack.apache.org X-Mailer: Apple Mail (2.1510) X-Virus-Checked: Checked by ClamAV on apache.org On Jul 23, 2014, at 11:38 AM, daan Hoogland = wrote: > Sebastien, >=20 > 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..)=20 > 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. >=20 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. >=20 > right? >=20 > On Wed, Jul 23, 2014 at 5:28 PM, Sebastien Goasguen = wrote: >>=20 >> On Jul 23, 2014, at 11:19 AM, Sam Schmit = wrote: >>=20 >>> Hey everyone, >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> Sam >>>=20 >>>=20 >>=20 >> 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 ? >>=20 >> My own take and reason for calling for a change we are currently = doing things is mostly due to the way we release. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> 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). >>=20 >> To move forward, we should make a proposal to the list and call for a = vote. >>=20 >> Any takers to start a wiki page proposing a new git process and how = we could move to it (transition path) ? >>=20 >>=20 >> -Sebastien >>=20 >>=20 >>>=20 >>> On Wed, Jul 23, 2014 at 5:16 AM, Leo Simons = >>> wrote: >>>=20 >>>> Hey folks, >>>>=20 >>>> With 4.4.0 tagged, is now an opportune time to go and implement = this? >>>>=20 >>>> I would enthousiastically +1 and get crackin', but I=92m not a = committer so >>>> its not that practical for me to volunteer! >>>>=20 >>>> I wanted to point out atlassian=92s description of gitflow >>>>=20 >>>> https://www.atlassian.com/git/workflows#!workflow-gitflow >>>>=20 >>>> which might be easier to read. >>>>=20 >>>> Similarly, the git-flow scripts that help out with implementing = this stuff >>>>=20 >>>> https://github.com/nvie/gitflow >>>>=20 >>>> they also describe the relationship between gitflow and dealing = with >>>> multiple remotes >>>>=20 >>>> https://www.atlassian.com/git/workflows#!pull-request >>>>=20 >>>> Finally note atlassian=92s free sourcetree GUI has built-in support = for >>>> git-flow >>>>=20 >>>> http://www.sourcetreeapp.com/ >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> cheers, >>>>=20 >>>>=20 >>>> Leo >>>>=20 >>>> On Jul 1, 2014, at 12:09 AM, Sebastien Goasguen = wrote: >>>>=20 >>>>> I would like to re-start this discussion. >>>>>=20 >>>>> Rajani made some good points and someone mentioned Gitflow: >>>>>=20 >>>>> http://nvie.com/posts/a-successful-git-branching-model/ >>>>>=20 >>>>> Thinking about our release procedure, we clearly need more tests = and a >>>> CI. However it looks like this is going to take some time. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> In addition gitflow [1] does not do cherry-picks (gets back to = Rajani's >>>> point) everything is based on merges. >>>>>=20 >>>>> 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=85.etc >>>>>=20 >>>>> Please read [1] it's a good read. >>>>>=20 >>>>> And let's discuss, >>>>>=20 >>>>> [1] http://nvie.com/posts/a-successful-git-branching-model/ >>>>>=20 >>>>> -Sebastien >>>>>=20 >>>>> On Jun 2, 2014, at 11:58 PM, Rajani Karuturi = >>>> wrote: >>>>>=20 >>>>>> There is also the problem of cherry-picking. >>>>>> As a contributor, I always endup creating multiple patches for = each >>>> branch as they don=92t cleanly apply on the upward branches. which = means >>>> distinct commits for each branch and I don=92t 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. >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> ~Rajani >>>>>>=20 >>>>>>=20 >>>>>>=20 >>>>>> On 02-Jun-2014, at 10:51 pm, Marcus wrote: >>>>>>=20 >>>>>>> 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. >>>>>>>=20 >>>>>>> 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? >>>>>>>=20 >>>>>>>=20 >>>>>>> On Mon, Jun 2, 2014 at 3:17 AM, Rajani Karuturi < >>>> Rajani.Karuturi@citrix.com> >>>>>>> wrote: >>>>>>>=20 >>>>>>>> Any other suggestions/objections/comments?? >>>>>>>> Can we discuss this in detail and agree to a process?? >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> ~Rajani >>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> On 02-Jun-2014, at 9:32 am, Rajani Karuturi < >>>> Rajani.Karuturi@citrix.com> >>>>>>>> wrote: >>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>> 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. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> ~Rajani >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On 30-May-2014, at 11:26 pm, Mike Tutkowski < >>>>>>>> mike.tutkowski@solidfire.com> wrote: >>>>>>>>>=20 >>>>>>>>>> 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. >>>>>>>>>>=20 >>>>>>>>>> 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). >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> On Fri, May 30, 2014 at 11:53 AM, Stephen Turner < >>>>>>>> Stephen.Turner@citrix.com> >>>>>>>>>> wrote: >>>>>>>>>>=20 >>>>>>>>>>> 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? >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> Stephen Turner >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -----Original Message----- >>>>>>>>>>> From: Mike Tutkowski [mailto:mike.tutkowski@solidfire.com] >>>>>>>>>>> Sent: 30 May 2014 18:48 >>>>>>>>>>> To: dev@cloudstack.apache.org >>>>>>>>>>> Subject: Re: [PROPOSAL] git workflow >>>>>>>>>>>=20 >>>>>>>>>>> I think this flow is something we should seriously consider. >>>>>>>>>>>=20 >>>>>>>>>>> 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. >>>>>>>>>>>=20 >>>>>>>>>>> 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). >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> On Fri, May 30, 2014 at 10:49 AM, Rajani Karuturi < >>>>>>>>>>> Rajani.Karuturi@citrix.com> wrote: >>>>>>>>>>>=20 >>>>>>>>>>>> Hi all, >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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=92t = cleanly >>>> apply on >>>>>>>>>>>> different branches. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> I think we should have some guidelines. Here is what I = propose. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> 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=92t 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 ; reviewed by >>>>>>>> >>>>>>>>>>>> for CASSANDRA- >>>>>>>>>>>> 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. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Please add your thoughts/suggestions/comments. >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>> Ref: >>>>>>>>>>>>=20 >>>> http://www.draconianoverlord.com/2013/09/07/no-cherry-picking.html >>>>>>>>>>>> https://www.youtube.com/watch?v=3DAJ-CpGsCpM0 >>>>>>>>>>>>=20 >>>>>>>>>>>> ~Rajani >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>>=20 >>>>>>>>>>> -- >>>>>>>>>>> *Mike Tutkowski* >>>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>>>>>>> e: mike.tutkowski@solidfire.com >>>>>>>>>>> o: 303.746.7302 >>>>>>>>>>> Advancing the way the world uses the cloud >>>>>>>>>>> *=99* >>>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>>=20 >>>>>>>>>> -- >>>>>>>>>> *Mike Tutkowski* >>>>>>>>>> *Senior CloudStack Developer, SolidFire Inc.* >>>>>>>>>> e: mike.tutkowski@solidfire.com >>>>>>>>>> o: 303.746.7302 >>>>>>>>>> Advancing the way the world uses the cloud >>>>>>>>>> *=99* >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>=20 >>>>>>=20 >>>>>=20 >>>>=20 >>>>=20 >>=20 >=20 >=20 >=20 > --=20 > Daan