Hi Seb, Great way of wording it, and I completely agree! You should be able to pick up master and roll it out into production and keep running with it!
Cheers, Funs > On 11 Jun 2015, at 23:43, Sebastien Goasguen <run...@gmail.com> wrote: > > >> On Jun 11, 2015, at 6:43 PM, John Burwell <john.burw...@shapeblue.com> wrote: >> >> All, >> >> Why are we averse to cutting a release stabilization branch? In the past, >> we have cut release stabilization branches to ensure that the flow >> contributions was not interrupted. > > I disagree. > > We have cut branches that way because that’s how Citrix delivers software. It > develops on master, cuts a branch and put a QA team to work to stabilize and > make a release. > > I believe it’s a broken model for an open source community made of mostly > volunteers. We don’t have the luxury to QA a release branch and loose that > effort (because it does not go back to master). > > In addition, this process has led to many regression, because there is/was a > disconnect between the Qa team and the guys developing on master. Plus bad > practice when bugs gets fixed. i.e we fix a bug in a release branch but don’t > port it in master. > > That’s why we have talked about this at length for almost a year now, alas > without resolution ( I thought we had, but your email indicates otherwise, > too bad you did not chime in earlier). > > I am advocating for us to stabilize master and gate master. So that whenever > we release we can do it starting from a stabilized branch. Instead of having > to reinvest time in lengthy QA. > > I want us to be able to release at anytime, when we feel like it and as soon > as someone says I want this fix/feature that was just merged in master. Right > no we cannot do that. > > So yes call me crazy, I want the developers to take it onto themselves to > keep their forks in sync with master, develop on their fork. And I want > master to be the release branch. We will be able to build up a release > through PR from devs with limited merge conflicts. So that we reach a point > where master is QA at all time and we don’t loose any investment made in QA. > > >> For committers, it is not a big deal since they can manage their branches in >> the cloudstack repo. However, for non-committers, this freeze could cause >> unnecessary frustration and discourage further contributions. > > A freeze means only the RMs will commit on master. any PR from anyone welcome > and let the discussions happen on whether to merge or not…no frustration. > > >> >> Thanks, >> -John >> >> ________________________________________ >> From: sebgoa <run...@gmail.com> >> Sent: Wednesday, June 10, 2015 6:33 AM >> To: dev@cloudstack.apache.org >> Subject: Re: 4.6 >> >> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <r...@remi.nl> wrote: >> >>> Hi, >>> >>> I can jump in and work with Rohit and Daan to make 4.6 happen. >>> >>> +1 for the QA on master. It would be best if we could then all focus on >>> stabilizing 4.6 aka master and wait with refactor stuff and new features >>> until 4.6 is out, which is the start of 4.7. >>> >>> On the other hand, building new features in the mean time isn't a big >>> issue, as rebasing to a master that gets more stable every day is much >>> easier than it is today I'd say. You just cannot merge new stuff until 4.6 >>> is out. >>> >>> Let's write down some guidelines and see if this approach makes sense. >>> >> >> Maybe that's something that you can do at the meetup today and bring it back >> to the list as a proposal ? >> >> When I talk about freeze I am thinking just letting the RMs commit on >> master, everyone who wants something in 4.6 should submit a PR. >> >> >> >>> Regards, Remi >>> >>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <run...@gmail.com> wrote: >>>> >>>> Folks, >>>> >>>> We need to freeze 4.6 asap. >>>> >>>> I originally agreed to RM 4.6 and Daan also stepped up. >>>> >>>> But I would like to work on doing a release of ec2stack and gcestack, so I >>>> will step down from 4.6 RM. >>>> >>>> Anybody wants to jump in. >>>> >>>> There is already a ton of things in 4.6 and we need to release. >>>> >>>> Ideally we also need to QA directly on master, so that we can build 4.7 on >>>> top of a stable release. >>>> >>>> >>>> -sebastien >> 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 – rapid IaaS deployment framework<http://shapeblue.com/csforge/> >> CloudStack Consulting<http://shapeblue.com/cloudstack-consultancy/> >> CloudStack Software >> Engineering<http://shapeblue.com/cloudstack-software-engineering/> >> 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 Pty 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. > — =Funs
