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