Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Sender: Funs Kessen <fozzielumpkins@gmail.com>
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
Subject: Re: 4.6
From: Funs Kessen <funs@barred.org>
In-Reply-To: <F5445D51-26C3-4FBF-8CFC-11CF5A3BB452@gmail.com>
Date: Fri, 12 Jun 2015 14:10:28 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1471F953-5383-46D0-A974-E166A92E3965@barred.org>
References: <BA2D8004-2453-4399-96EF-2E061C646237@gmail.com>
 <178BF23C-5671-4D74-B559-AD45786C5004@remi.nl>
 <403A6AA5-9116-4156-9093-20A2209091BF@gmail.com>
 <DB5PR07MB077470A3886FDFCDB86424C89EBC0@DB5PR07MB0774.eurprd07.prod.outlook.com>
 <F5445D51-26C3-4FBF-8CFC-11CF5A3BB452@gmail.com>
To: dev@cloudstack.apache.org

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 <runseb@gmail.com> wrote:
>=20
>=20
>> On Jun 11, 2015, at 6:43 PM, John Burwell =
<john.burwell@shapeblue.com> wrote:
>>=20
>> All,
>>=20
>> 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.
>=20
> I disagree.
>=20
> We have cut branches that way because that=E2=80=99s how Citrix =
delivers software. It develops on master, cuts a branch and put a QA =
team to work to stabilize and make a release.
>=20
> I believe it=E2=80=99s a broken model for an open source community =
made of mostly volunteers. We don=E2=80=99t have the luxury to QA a =
release branch and loose that effort (because it does not go back to =
master).
>=20
> 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=E2=80=99t port it in master.
>=20
> That=E2=80=99s 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).
>=20
> 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.
>=20
> 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.
>=20
> 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=E2=80=99t loose =
any investment made in QA.
>=20
>=20
>> 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.
>=20
> 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=E2=80=A6=
no frustration.
>=20
>=20
>>=20
>> Thanks,
>> -John
>>=20
>> ________________________________________
>> From: sebgoa <runseb@gmail.com>
>> Sent: Wednesday, June 10, 2015 6:33 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: 4.6
>>=20
>> On Jun 8, 2015, at 11:45 PM, Remi Bergsma <remi@remi.nl> wrote:
>>=20
>>> Hi,
>>>=20
>>> I can jump in and work with Rohit and Daan to make 4.6 happen.
>>>=20
>>> +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.
>>>=20
>>> 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.
>>>=20
>>> Let's write down some guidelines and see if this approach makes =
sense.
>>>=20
>>=20
>> Maybe that's something that you can do at the meetup today and bring =
it back to the list as a proposal ?
>>=20
>> 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.
>>=20
>>=20
>>=20
>>> Regards, Remi
>>>=20
>>>> On 08 Jun 2015, at 21:43, Sebastien Goasguen <runseb@gmail.com> =
wrote:
>>>>=20
>>>> Folks,
>>>>=20
>>>> We need to freeze 4.6 asap.
>>>>=20
>>>> I originally agreed to RM 4.6 and Daan also stepped up.
>>>>=20
>>>> But I would like to work on doing a release of ec2stack and =
gcestack, so I will step down from 4.6 RM.
>>>>=20
>>>> Anybody wants to jump in.
>>>>=20
>>>> There is already a ton of things in 4.6 and we need to release.
>>>>=20
>>>> Ideally we also need to QA directly on master, so that we can build =
4.7 on top of a stable release.
>>>>=20
>>>>=20
>>>> -sebastien
>> Find out more about ShapeBlue and our range of CloudStack related =
services
>>=20
>> IaaS Cloud Design & =
Build<http://shapeblue.com/iaas-cloud-design-and-build//>
>> CSForge =E2=80=93 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/>
>>=20
>> 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.
>=20

=E2=80=94=20
	=3DFuns