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 B350911D49 for ; Tue, 19 Aug 2014 17:56:28 +0000 (UTC) Received: (qmail 14378 invoked by uid 500); 19 Aug 2014 17:56:23 -0000 Delivered-To: apmail-cloudstack-dev-archive@cloudstack.apache.org Received: (qmail 14331 invoked by uid 500); 19 Aug 2014 17:56:23 -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 14319 invoked by uid 99); 19 Aug 2014 17:56:23 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Aug 2014 17:56:23 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of rohit.yadav@shapeblue.com designates 213.199.154.19 as permitted sender) Received: from [213.199.154.19] (HELO emea01-am1-obe.outbound.protection.outlook.com) (213.199.154.19) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 19 Aug 2014 17:56:18 +0000 Received: from DBXPR07MB480.eurprd07.prod.outlook.com (10.141.231.154) by DBXPR07MB478.eurprd07.prod.outlook.com (10.141.231.147) with Microsoft SMTP Server (TLS) id 15.0.1010.18; Tue, 19 Aug 2014 17:55:54 +0000 Received: from DBXPR07MB480.eurprd07.prod.outlook.com ([10.141.231.154]) by DBXPR07MB480.eurprd07.prod.outlook.com ([10.141.231.154]) with mapi id 15.00.1010.016; Tue, 19 Aug 2014 17:55:54 +0000 From: Rohit Yadav To: "dev@cloudstack.apache.org" Subject: Re: [VOTE] Adapting git workflow for release branches Thread-Topic: [VOTE] Adapting git workflow for release branches Thread-Index: AQHPuHMzAaqMkDhUmECBCNZ/lyHu55vTlzAAgAMA+xCAABNcAIAABwuAgAALoICAACJHAIAAFFQAgAAZVICAAI1LgIAACxgAgAAG8oCAAAHKgIAABegAgABY8QCAAAH7gIAABR2AgAAMl4CAAAgvAIAAAzCAgAAC9ICAAAyhgA== Date: Tue, 19 Aug 2014 17:55:54 +0000 Message-ID: <12F2389B-4889-4E19-8D83-8197D7D57574@shapeblue.com> References: <77B337AF224FD84CBF8401947098DD8731230AD7@SJCPEX01CL02.citrite.net> <4EFCA102B2C89A43BD3D0B497BFB87841608E8E1@SJCPEX01CL02.citrite.net> <8BB383DF-88F8-4FCF-93FA-A7FE3EE752B6@shapeblue.com> <0962C558-D42D-43B4-A0E8-6C319052CAA0@shapeblue.com> <60BA0B2A-340E-4BF3-A0B2-E89A9EFA5D2D@gmail.com> <18E27329-4D74-4873-BF53-0CDA594B5044@gmail.com> <2A9CBDC3-9676-4DA1-918A-8094420A497B@shapeblue.com> <8AB6CD5E-2B9C-4579-B57E-5EC947F0A3D8@citrix.com> <252A5A1A-D2E2-40DC-872C-D3F4552877A4@shapeblue.com> <53B28C48-3E93-4297-8B79-057CB07DD45E@shapeblue.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [178.199.146.103] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 0308EE423E x-forefront-antispam-report: SFV:NSPM;SFS:(10019006)(6009001)(24454002)(51704005)(52314003)(52044002)(13734003)(189002)(199003)(479174003)(377454003)(106356001)(106116001)(105586002)(561944003)(95666004)(80022001)(36756003)(66066001)(81542001)(74502001)(15202345003)(4396001)(110136001)(2351001)(93886004)(101416001)(107886001)(2656002)(85306004)(99396002)(33656002)(74662001)(107046002)(83716003)(87936001)(82746002)(85852003)(15975445006)(92726001)(86362001)(83072002)(21056001)(15395725005)(19580405001)(19580395003)(76176999)(79102001)(46102001)(81342001)(20776003)(76482001)(83322001)(54356999)(77982001)(50986999)(104396001)(2501001);DIR:OUT;SFP:1102;SCL:1;SRVR:DBXPR07MB478;H:DBXPR07MB480.eurprd07.prod.outlook.com;FPR:;MLV:sfv;PTR:InfoNoRecords;MX:1;A:1;LANG:en; Content-Type: text/plain; charset="Windows-1252" Content-ID: <0437647EC729FC4594FD10F5B86597A4@eurprd07.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: shapeblue.com X-Virus-Checked: Checked by ClamAV on apache.org tl;dr? hope you read it; On 19-Aug-2014, at 7:10 pm, Min Chen wrote: > I will hesitate on this "No enforcement" approach in the flow. I bet that > without some kind of enforcement, based on past experience, after one Stakeholder will always care. The system should be optimistic to allow thin= gs in and not to punish in advance. That=92s how many scalable opensource project such as Linux, Firefox and ou= r own Apache works (people over code that is). If you=92ve any ideas please share. We=92ve to find a =93non-strict=94 enfo= rcement to get best of all things and I don=92t have a solution right now t= o suggest. =93Strict enforcement=94 won=92t be scalable anyway, hackers always find wa= y around gaming the system. Unicorns, Santas and bug-less code perhaps don=92t exist IMHO so may never = guarantee code quality but only improve over time. Even things like pacemak= ers, realtime systems used in mining, surgery, aerospace, mars rover etc; o= penssl (heartbleed) have bugs and issues. This is not to say that we should= not have code reviews, other processes and automated build/CI/smoke-tests = are =93not=94 needed, they are needed but they =93should" come only gradual= ly. I also think improvements are better severed in small nibbles than a on= e big main course. In my past startup, last year, I helped them introduce a non-strict code re= viewing process and what it did was not to scare anyone but slowly and grad= ually everyone started using code reviews and that became a process now. Wh= at I learnt was that people like slow changes (don=92t put the frog in hot = water), processes should be effortless and invisible (you don=92t have to t= hink much on how to do it, like say driving a car or touch typing on keyboa= rd), and a cultural change is best implemented without enforcement. For exa= mple, in a many countries people don=92t honk i.e. the culture even if no o= ne gets a ticket for honking which is my point we need an understanding, a = guideline, a protocol to implement a culture not an =93enforcement=94 or te= am of police. > release, we will come together to discuss flaw in our flow again:) Sorry > if I am too pessimistic on this. To introduce an enforcement would mean take away a committer=92s privilege = to commit. If you have some ideas start a thread. IMO =93pessimistic approach" is not a good approach =97 you don't ban or re= strict people driving cars just because of accidents or ban the Internet ju= st because there are things you don=92t like on it, or put people in jail j= ust because they can commit a crime in future. I would want an open and tra= nsparent workflow/protocol/guideline that is agreeable to all/most of us an= d that does not impose any restrictions. Cheers. > > Thanks > -min > > On 8/19/14 10:00 AM, "Rohit Yadav" wrote: > >> Hi, >> >> On 19-Aug-2014, at 6:48 pm, Min Chen wrote: >> >>> In that case, we should call out this procedure >>> >>> If (you=B9re a committer) { >>> Go create a hotfix branch and ask RM to pick it up >>> } else { >>> Go upload your patch and get RM to review your request from reviewboard >>> } >>> >>> >>> in your proposal. I don't want people to have a misunderstanding that >>> with >>> this proposal, RM is not needed anymore. Actually, RM is MORE IMPORTANT >>> with this proposal. >> >> Yes. >> >>> Also, we should also call out the enforcement plan for this procedure. >> >> Subjective. All committers have privilege to commit so enforcement will >> be unnecessary, instead if you find an issue with anyone/anything you >> raise it privately or on public dev ML just like we do it now. >> >>> What happens if somebody still directly commits to release branch after >>> it >>> is cut? Ideally, based on this proposal, after RC is cut, we should onl= y >>> see branch merge/cherry-pick done by RM. If not, RM should revert it to >>> enforce the flow. >> >> At RM=92s discretion. >> >> Cheers. >> >>> >>> Thanks >>> -min >>> >>> >>> >>> >>> On 8/19/14 9:19 AM, "Rohit Yadav" wrote: >>> >>>> Hey, >>>> >>>> On 19-Aug-2014, at 5:34 pm, Pierre-Luc Dion wrote= : >>>> >>>>> Thanks Min for the comment, make sense. >>>>> >>>>> Rohit, how do we plan to managed merge request or submit one? I >>>>> don't >>>>> think using the mailing list to keep track of merge request is good, >>>>> does >>>>> https://reviews.apache.org/account/login/ is keep up to date and all >>>>> merge >>>>> request should go there ? >>>> >>>> If (you=B9re a committer) { >>>> Go create a hotfix branch and ask RM to pick it up >>>> } else { >>>> Go upload your patch and get RM to review your request from reviewboar= d >>>> } >>>> >>>>> What about using Jira to follow merge request ? maybe by having a >>>>> 'merge-request' issue type as sub-task? >>>> >>>> You may do that as long as RMs are okay with that. We don=B9t want peo= ple >>>> to attack RMs from too many of channels such as reviewboard, jira, >>>> twitter, fb, linkedin and whatnot; sticking to just using email is >>>> recommended. >>>> >>>>> Also I'm a bit confuse for some commit cases: >>>>> >>>>> Let say that I want to fix the release version display in the API doc= , >>>>> it >>>>> is not code related right not it show as 4.2.0, it's not a bugfix or = a >>>>> new >>>>> feature, so should I create branch + merge request or this type of >>>>> commit >>>>> could be push directly in the release branch (ie: 4.4) ? >>>> >>>> Such cases will =B3depend" on your chemistry with the RM, if they=B9re= cool >>>> you go ahead alongwith them and fix doc/build fixes directly on releas= e >>>> (4.4 in the example) branch. >>>> >>>> This is a reason as to why this proposal is flexible, and it does not >>>> introduce any policing but gives a guideline for people to follow. >>>> >>>> Lastly, checking out branches and working on them using git is not >>>> expensive at all, just few keyboard strokes maybe so just don=B9t be >>>> afraid. >>>> >>>> Also, for multiple fixes feel free to do several bugfixes and ask the >>>> RM >>>> to pick the fixes from that (hot/bug) fix branch. >>>> >>>> HTH, cheers. >>>> >>>>> Sorry if I add confusion... >>>>> >>>>> Pierre-Luc >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Aug 19, 2014 at 11:16 AM, Min Chen >>>>> wrote: >>>>> >>>>>> I would rather CI be considered together with this thread, since thi= s >>>>>> thread needs to decide at what condition RM can merge a hotfix/bugfi= c >>>>>> branch to release branch. >>>>>> >>>>>> Thanks >>>>>> -min >>>>>> Sent from my iPhone >>>>>> >>>>>>> On Aug 19, 2014, at 8:09 AM, "Pierre-Luc Dion" >>>>>> wrote: >>>>>>> >>>>>>> +1 , CI shouldn't be another topic? >>>>>>> >>>>>>> What is required or missing to have CI in place? >>>>>>> >>>>>>> >>>>>>> *Pierre-Luc DION* >>>>>>> Architecte de Solution Cloud | Cloud Solutions Architect >>>>>>> t 855.652.5683 >>>>>>> >>>>>>> *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Expert= s >>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 >>>>>>> w cloudops.com *|* tw @CloudOps_ >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Tue, Aug 19, 2014 at 5:50 AM, Rohit Yadav >>>>>>> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>>> On 19-Aug-2014, at 11:29 am, Sebastien Goasguen >>>>>> wrote: >>>>>>>>> Say you grab a patch from review board and stick it in a hotfix >>>>>>>>> branch, >>>>>>>> test that =8Acall for merge on release branch. >>>>>>>>> Do we *merge* to master or can we apply the patch directly to >>>>>>>>> master >>>>>>>> (git am -s=8A) ? >>>>>>>> >>>>>>>> Once the hotfix branch is merged on release branch, we would merge >>>>>>>> the >>>>>>>> release branch to master, that will bring the hotfix on master as >>>>>>>> well. >>>>>>>> >>>>>>>> We don=B9t want to encourage working on master for fixes that qual= ify >>>>>>>> for >>>>>>>> release branches directly so ideally we should not git am -s the >>>>>>>> patch >>>>>> on >>>>>>>> master. But there is scope for non-strictness for a situation >>>>>>>> needing >>>>>> git >>>>>>>> am -s on master directly, it would be at the discretion of >>>>>>>> the >>>>>> RM >>>>>>>> and committers. >>>>>>>> >>>>>>>> Regards, >>>>>>>> Rohit Yadav >>>>>>>> Software Architect, ShapeBlue >>>>>>>> M. +41 779015219 | rohit.yadav@shapeblue.com >>>>>>>> Blog: bhaisaab.org | Twitter: @_bhaisaab >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Find out more about ShapeBlue and our range of CloudStack related >>>>>> services >>>>>>>> >>>>>>>> IaaS Cloud Design & Build< >>>>>>>> http://shapeblue.com/iaas-cloud-design-and-build//> >>>>>>>> CSForge =AD rapid IaaS deployment >>>>>>>> framework>>>>>> >>>>>>>> CloudStack Consulting >>>>>>>> CloudStack Infrastructure Support< >>>>>>>> http://shapeblue.com/cloudstack-infrastructure-support/> >>>>>>>> CloudStack Bootcamp Training Courses< >>>>>>>> http://shapeblue.com/cloudstack-training/> >>>>>>>> >>>>>>>> This email and any attachments to it may be confidential and are >>>>>> intended >>>>>>>> solely for the use of the individual to whom it is addressed. Any >>>>>>>> views >>>>>> or >>>>>>>> opinions expressed are solely those of the author and do not >>>>>>>> necessarily >>>>>>>> represent those of Shape Blue Ltd or related companies. If you are >>>>>>>> not >>>>>> the >>>>>>>> intended recipient of this email, you must neither take any action >>>>>>>> based >>>>>>>> upon its contents, nor copy or show it to anyone. Please contact >>>>>>>> the >>>>>> sender >>>>>>>> if you believe you have received this email in error. Shape Blue >>>>>>>> Ltd >>>>>>>> is >>>>>> a >>>>>>>> company incorporated in England & Wales. ShapeBlue Services India >>>>>>>> LLP >>>>>> is a >>>>>>>> company incorporated in India and is operated under license from >>>>>>>> Shape >>>>>> Blue >>>>>>>> Ltd. Shape Blue Brasil Consultoria Ltda is a company incorporated >>>>>>>> in >>>>>> Brasil >>>>>>>> and is operated under license from Shape Blue Ltd. ShapeBlue SA Pt= y >>>>>>>> Ltd >>>>>> is >>>>>>>> a company registered by The Republic of South Africa and is traded >>>>>>>> under >>>>>>>> license from Shape Blue Ltd. ShapeBlue is a registered trademark. >>>>>>>> >>>>>> >>>> >>>> Regards, >>>> Rohit Yadav >>>> Software Architect, ShapeBlue >>>> M. +41 779015219 | rohit.yadav@shapeblue.com >>>> Blog: bhaisaab.org | Twitter: @_bhaisaab >>>> >>>> >>>> >>>> Find out more about ShapeBlue and our range of CloudStack related >>>> services >>>> >>>> IaaS Cloud Design & >>>> Build >>>> CSForge =AD rapid IaaS deployment >>>> framework >>>> CloudStack Consulting >>>> CloudStack Infrastructure >>>> Support >>>> CloudStack Bootcamp Training >>>> Courses >>>> >>>> This email and any attachments to it may be confidential and are >>>> intended >>>> solely for the use of the individual to whom it is addressed. Any view= s >>>> or opinions expressed are solely those of the author and do not >>>> necessarily represent those of Shape Blue Ltd or related companies. If >>>> you are not the intended recipient of this email, you must neither tak= e >>>> any action based upon its contents, nor copy or show it to anyone. >>>> Please >>>> contact the sender if you believe you have received this email in >>>> error. >>>> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue >>>> Services India LLP is a company incorporated in India and is operated >>>> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda >>>> is >>>> a company incorporated in Brasil and is operated under license from >>>> Shape >>>> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic >>>> of >>>> South Africa and is traded under license from Shape Blue Ltd. ShapeBlu= e >>>> is a registered trademark. >> >> Regards, >> Rohit Yadav >> Software Architect, ShapeBlue >> M. +41 779015219 | rohit.yadav@shapeblue.com >> Blog: bhaisaab.org | Twitter: @_bhaisaab >> >> >> >> Find out more about ShapeBlue and our range of CloudStack related servic= es >> >> IaaS Cloud Design & >> Build >> CSForge =96 rapid IaaS deployment framework >> CloudStack Consulting >> CloudStack Infrastructure >> Support >> CloudStack Bootcamp Training >> Courses >> >> This email and any attachments to it may be confidential and are intende= d >> solely for the use of the individual to whom it is addressed. Any views >> or opinions expressed are solely those of the author and do not >> necessarily represent those of Shape Blue Ltd or related companies. If >> you are not the intended recipient of this email, you must neither take >> any action based upon its contents, nor copy or show it to anyone. Pleas= e >> contact the sender if you believe you have received this email in error. >> Shape Blue Ltd is a company incorporated in England & Wales. ShapeBlue >> Services India LLP is a company incorporated in India and is operated >> under license from Shape Blue Ltd. Shape Blue Brasil Consultoria Ltda is >> a company incorporated in Brasil and is operated under license from Shap= e >> Blue Ltd. ShapeBlue SA Pty Ltd is a company registered by The Republic o= f >> South Africa and is traded under license from Shape Blue Ltd. ShapeBlue >> is a registered trademark. > Regards, Rohit Yadav Software Architect, ShapeBlue M. +41 779015219 | rohit.yadav@shapeblue.com Blog: bhaisaab.org | Twitter: @_bhaisaab Find out more about ShapeBlue and our range of CloudStack related services IaaS Cloud Design & Build CSForge =96 rapid IaaS deployment framework CloudStack Consulting CloudStack Infrastructure Support CloudStack Bootcamp Training Courses This email and any attachments to it may be confidential and are intended s= olely for the use of the individual to whom it is addressed. Any views or o= pinions expressed are solely those of the author and do not necessarily rep= resent those of Shape Blue Ltd or related companies. If you are not the int= ended recipient of this email, you must neither take any action based upon = its contents, nor copy or show it to anyone. Please contact the sender if y= ou believe you have received this email in error. Shape Blue Ltd is a compa= ny incorporated in England & Wales. ShapeBlue Services India LLP is a compa= ny incorporated in India and is operated under license from Shape Blue Ltd.= Shape Blue Brasil Consultoria Ltda is a company incorporated in Brasil and= is operated under license from Shape Blue Ltd. ShapeBlue SA Pty Ltd is a c= ompany registered by The Republic of South Africa and is traded under licen= se from Shape Blue Ltd. ShapeBlue is a registered trademark.