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 8F6EA1184D for ; Fri, 8 Aug 2014 07:17:34 +0000 (UTC) Received: (qmail 37903 invoked by uid 500); 8 Aug 2014 07:17:34 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 37845 invoked by uid 500); 8 Aug 2014 07:17:34 -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 37833 invoked by uid 99); 8 Aug 2014 07:17:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Aug 2014 07:17:33 +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 daan.hoogland@gmail.com designates 209.85.213.179 as permitted sender) Received: from [209.85.213.179] (HELO mail-ig0-f179.google.com) (209.85.213.179) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Aug 2014 07:17:31 +0000 Received: by mail-ig0-f179.google.com with SMTP id h18so604216igc.0 for ; Fri, 08 Aug 2014 00:17:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding; bh=yzzfw5dVo7uiC7TvgzeTQ6/Zo3w0/3sFuiNxfLI5jNI=; b=u2FPqsTPFudbDDlHTE56aMai7hwv/9p59AugHyS/T3NyvSRom4JmFMyJJN0bn2rs/7 8tlknFF+dJfFiSgvI/QfqZ20hY55aC8pMMDFeBO6oFDAN+ZNxk7ioY3gD/RQysRrXixw /MCk/jPrw7ozlYW4waVa9+Jl41g7Yu8yt5m2Nmwibh4h8fKl0nJ3dxfqVKp7Zb78PcN3 NPqWirPKQRpJkPTAklwmfDnFC/oO3M5OurRJ/6fu27CMSkonWnQuafHzhovAq+TePoCD UmwsnKDmdaJo6GiAydtkWcJvJF0UUXjs4H9ungAIy/58iPa7XsSOLPBbvInu6/2xTn89 FLig== X-Received: by 10.50.1.17 with SMTP id 17mr2464469igi.3.1407482226589; Fri, 08 Aug 2014 00:17:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.155.79 with HTTP; Fri, 8 Aug 2014 00:16:46 -0700 (PDT) In-Reply-To: References: <20140731102839.A1876816018@nike.apache.org> <4EFCA102B2C89A43BD3D0B497BFB87841607EFDE@SJCPEX01CL01.citrite.net> <5A68D8ED-F3BB-4716-A1A4-FFFA8EFFC9DE@gmail.com> <75942ED3FD12D64EABE71209BD0F62CC72505F@SJCPEX01CL02.citrite.net> <51ACB359-5F26-4AE1-B1BB-E0B7B0EE5422@citrix.com> <252B3524-FFE0-4111-9238-E08095C85492@shapeblue.com> <9BA1B9D2-33D9-438A-8D85-F1659D5269C6@shapeblue.com> <77B337AF224FD84CBF8401947098DD873121A01A@SJCPEX01CL01.citrite.net> <50372FBC-CDDD-4DD6-B113-D4BB721B9AB2@gmail.com> <049D5CBD-0D08-4541-B61D-7EC1F7C2BDDB@gmail.com> From: Daan Hoogland Date: Fri, 8 Aug 2014 09:16:46 +0200 Message-ID: Subject: Re: [VOTE] git workflow To: dev Cc: "runseb@gmail.com" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I see a lot of confusion around the fact that the name of gitflow is being used. What was proposed was a model that could be supported by the tool gitflow, not a workflow exactly as gitflow 'prescribes' it. If we forget about gitflow for a moment and look at the branching model that we want we all agree. For instance the idea of a shift of our current master problems to develop. it is there but half of the problems are shifted beyond develop onto all those branches that we are going to create. develop is going to suffer at times but it will keep the trouble away from master, as it won't be merged when not passing bvt/ci. In gitflow master is only for releases, in our model for all potential major.minor releases, even if we don't release them. The only ones that won't be on there are the conflicting bugfix releases. As for the problem 'branch moving really fast', we can ask to only merge to develop/master if the feature branch passes some test and make it a committer responsibility to guard this. I think we have or can make automatic records of passing or failing of feature branches. this would be how we mitigate the second half of the problems, the pre-merging regression ones. For now we would rely on each other but that will alter. On Thu, Aug 7, 2014 at 11:52 PM, Mike Tutkowski wrote: > This is what I was wondering about, as well. It seems all of our 'master' > problems become 'develop' problems. > > I do like the idea of merging versus cherry picking (as a general rule), > though. > > > On Thu, Aug 7, 2014 at 3:47 PM, Alena Prokharchyk < > Alena.Prokharchyk@citrix.com> wrote: > >> Sebastian, addressing the following comment of yours >> >> >> "The main issue with master right now is that it moves really fast as a >> shared branch, people merge features without warning, we see regressions >> etc.. >> By the time we release a major version, master has moved so much that it >> feels like starting over with the next release. It's almost as if we are >> forking our own software. CI alone (even if it were really good) will no= t >> fix this.=E2=80=9D >> >> >> You will still have this problem. You cut the next release branch from t= he >> *develop branch, not from master. And the *develop branch will move with >> the same pace as the old master, after the release branch is cut. So >> =E2=80=9Cmaster moving really fast=E2=80=9D problem would become =E2=80= =9Cdevelop moving really >> fast=E2=80=9D. >> >> The problems you=E2=80=99ve mentioned - people merge features without wa= rning, we >> see regressions - can be fixed only with automation in place and the >> requirement to run this automation (CI/BVT) before the merge is done. >> Otherwise you are just shifting all existing problems from master to >> develop. >> >> >> -Alena. >> >> >> >> On 8/7/14, 2:15 PM, "Sebastien Goasguen" wrote: >> >> > >> >On Aug 7, 2014, at 4:51 PM, Alena Prokharchyk >> > wrote: >> > >> >> >> >> >> >> On 8/7/14, 1:42 PM, "Sebastien Goasguen" wrote: >> >> >> >>> >> >>> On Aug 7, 2014, at 8:33 AM, David Nalley wrote: >> >>> >> >>>> On Thu, Aug 7, 2014 at 3:38 AM, Sebastien Goasguen >> >>>> wrote: >> >>>>> >> >>>>> On Aug 6, 2014, at 7:15 PM, David Nalley wrote: >> >>>>> >> >>>>>> On Wed, Aug 6, 2014 at 5:36 PM, Alena Prokharchyk >> >>>>>> wrote: >> >>>>>>> Edison, thank you for raising the concern about the BVT/CI. >> >>>>>>>Somebody >> >>>>>>> mentioned earlier that we should separate git workflow >> >>>>>>> implementation from >> >>>>>>> the CI effort, but I do think we have to do in in conjunction. >> >>>>>>> Otherwise >> >>>>>>> what is the point in introducing staging/develop branch? If ther= e >> >>>>>>>is >> >>>>>>> no >> >>>>>>> daily automation run verifying all the code merged from >> >>>>>>> hotFixes/feature >> >>>>>>> branches (and possibly reverting wrong checkins), we can as well >> >>>>>>> merge the >> >>>>>>> code directly to master. >> >>>>>>> >> >>>>>> >> >>>>>> Yes! - please. >> >>>>>> Doing this without CI as a gating factor buys us very little. >> >>>>>> >> >>>>>> --David >> >>>>> >> >>>>> David, can you clarify. Are you going to be against any change of = git >> >>>>> workflow until we get CI/BVT in place ? >> >>>>> >> >>>> >> >>>> No, please don't take it that way. >> >>>> I understand Leo's point about Cherry-picking being for fruit, and = not >> >>>> code. But, I don't think that the workflow changes I've seen propos= ed >> >>>> affect quality. So shifting for quality's sake doesn't make a lot o= f >> >>>> sense in my mind. They could be a component of fixing the quality >> >>>> problem. >> >>>> >> >>>> --David >> >>> >> >>> Agreed, the changes don't affect quality but should support a CI inf= ra >> >>> that helps improves quality. >> >>> >> >>> I do think the changes provide >> >>> >> >>> -a stable master that represent released software >> >> >> >> >> >> You can always look at the latest release branch to get it, >> > >> >Yes I know how to get to the latest released software. >> > >> >I actually don't have good answers for your questions but I think Nate'= s >> >email (couple emails back) answers a lot of them. >> > >> >> as we are >> >> planning to keep them around to support maintenance. From the develop= er >> >> stand point, I would be more interested in getting the latest stable >> >>code, >> >> not the latest stable release. >> > >> >I think that's fine from a developer standpoint. I tend to look at thin= gs >> >from a user standpoint. >> >I think a basic user who wants to check out source (because he builds h= is >> >own packages), would like to checkout the latest master to get the late= st >> >released software (not everybody software projects works like this of >> >course). >> > >> >The main issue with master right now is that it moves really fast as a >> >shared branch, people merge features without warning, we see regression= s >> >etc.. >> >By the time we release a major version, master has moved so much that i= t >> >feels like starting over with the next release. It's almost as if we ar= e >> >forking our own software. CI alone (even if it were really good) will n= ot >> >fix this. >> > >> >So assuming we have CI in place, we do need a better workflow (let's no= t >> >call it gitflow anymore) to self-discipline ourselves. >> > >> >> >> >> I don=C2=B9t see the use of stable master branch during the release e= ither, >> >>as >> >> it reflects already released versions of the CS. And you never cut th= e >> >> release from the stable master branch; you do cut it from *develop - >> >> that=C2=B9s what the git workflow suggests. >> > >> >That's where our use case differs from gitflow. Several folks have >> >already mentioned that we are going to deviate from pure gitflow, it is >> >just a nice framework to start creating our own workflow. >> > >> >Personally, I would love to cut the release branches from master (inste= ad >> >of develop). that way you always start from a clean slate, instead of t= he >> >mess with start with right now. >> > >> >Say develop is more of a staging branch, as you have advocated. We can >> >run CI/BVT on that branch (we should run it everywhere=E2=80=A6but anyw= ay) and >> >make sure features merged in work as advertized. >> > >> >When time comes to release, we cut from master and merge the features >> >that have been merged in develop already, then go into QA, merge the >> >fixes back to develop etc=E2=80=A6.when released, we merge back to mast= er. >> > >> >If/since we don't do rolling releases, we branch out from the main >> >version tag and do a maintenance release that leaves on, assuming it >> >can't get merged back into master. >> > >> >> >> >>> -a clean way to merge features and bug fixes >> >> >> >> +1 >> >> >> >>> -a clean way to create a release that should reduce our time to rele= ase >> >> >> >> +1 Although I still think that slowness for our release was mostly >> >>caused >> >> by the last minute regression bugs caused by missing quality control = + >> >> lack of CI. >> > >> >True, but it is also due to the fact that we start a release branch fro= m >> >a messy master where regressions happen. >> > >> >> This new way would just take off the load from RM by >> >> eliminating endless cherry-picking. >> >> >> > >> >I would love to have a workflow where the RM has a very clean job (pick >> >the features that should be in the release, pick the hot fixes release)= . >> >It should just be a series of git merge and that's it. >> > >> >master branch is only released software, only touched by RMs >> > >> >released branches only touched by RMs >> > >> >develop shared but merges happen only after successful CI and guarantee >> >of no regressions. >> > >> >> >> >>> >> >> >> > >> >> > > > -- > *Mike Tutkowski* > *Senior CloudStack Developer, SolidFire Inc.* > e: mike.tutkowski@solidfire.com > o: 303.746.7302 > Advancing the way the world uses the cloud > *=E2=84=A2* --=20 Daan