cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sebastien Goasguen <run...@gmail.com>
Subject Re: 4.6
Date Thu, 11 Jun 2015 21:43:41 GMT

> On Jun 11, 2015, at 6:43 PM, John Burwell <john.burwell@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 <runseb@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 <remi@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 <runseb@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.


Mime
View raw message