Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
Subject: Re: [DISCUSS] Release principles for Apache CloudStack
From: sebgoa <runseb@gmail.com>
In-Reply-To: 
 <CAGQtxvbkWoY6Fegayt4b30ivmJgWB3R9=k5_21Es3MxTrGW6LA@mail.gmail.com>
Date: Fri, 17 Jul 2015 17:04:48 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F8EF727-52A7-49DF-A9F5-B1D22E5B7D41@gmail.com>
References: <F18BF32A-6962-4DBF-8014-E815EF19AC4A@remi.nl>
 <F9CE0436-017C-4228-8C17-B05E81318BE7@shapeblue.com>
 <CAGQtxvbkWoY6Fegayt4b30ivmJgWB3R9=k5_21Es3MxTrGW6LA@mail.gmail.com>
To: dev@cloudstack.apache.org

Finally read the thread,

It seems to me that a way forward is to have Remi and Rajani RM 4.6 =
(which is currently master).

The two of them can discuss and start RMing 4.6  (PR merge etc) and then =
we can iterate on the wiki release scenario.

@Remi @Rajani, would that work for you and you ready to get started ?

-sebastien


On Jul 10, 2015, at 8:17 PM, Daan Hoogland <daan.hoogland@gmail.com> =
wrote:

> I hate to be as opiniated as I am but here it comes ;)
>=20
> On Fri, Jul 10, 2015 at 7:39 PM, Rohit Yadav =
<rohit.yadav@shapeblue.com>
> wrote:
>=20
>> While I like the ideas generally [1], some concerns and observations
>> that I wish could be considered;
>>=20
>> - active contributor crunch:
>>=20
>> we don=E2=80=99t have large number of active people working towards =
testing,
>> fixing bugs and release, and reviewing/merging PRs on *master*; this
>> affects the agility of any process or workflow we want to put in, or =
expect
>> resolution in a certain window (3-5 days etc.);
>>=20
> =E2=80=8BThis is a very valid concern. We are a large community but =
not in any way
> big enough. One approach is to let no backporting of bugfixes happen! =
it
> sound contrary to some of your points but I think it is actually a
> mitigation (see below).
> =E2=80=8B
>=20
>=20
>> - diverse interests:
>>=20
>> our user-base may not necessarily want to upgrade to newer version of
>> CloudStack even if they can proved to be quite stable; in-fact =
commercially
>> some of us are paid to maintain stable branches and support users who =
are
>> still on 4.2/4.3/4.4/4.5 etc; based on my experience, a typical =
enterprise
>> users usually stick with a version (that works for them) for at least =
6
>> months, while smb user or in-house consumers are quite agile who may
>> upgrade as quickly as when new releases are made;
>>=20
> =E2=80=8BUser do go for bug fixes and are not concerned with any =
backwards
> compatible changes to functionality. If we guard against those, point
> releases are replaced by the minors and people can be as 'sticky' as =
they
> want. In the end it is a matter of naming and discipline. Of course we =
need
> to sell our policy.
> =E2=80=8B
>=20
>=20
>> - diverse branching/merging workflow usage and understanding:
>>=20
>> the bugfix workflow may not be acceptable (to go on master first), a =
lot
>> of people have their own way of branching/merging in their =
organisations
>> that affect how they do it in the the project
>>=20
> =E2=80=8BI do not think it is. If you want something fixed you should =
fix it on the
> oldest version it needs fixing on. No backporting at all. this only
> mystifies our git tree and =E2=80=8B
>=20
> =E2=80=8Bprohibits good administration. Bug-fixes can be merged =
forward and whether
> anyone has one of infinite other possible=E2=80=8B release management =
schemes
> internally should not influence the way they work on this project.
>=20
>=20
>> - waiting time on new changes:
>>=20
>> since we don=E2=80=99t have large number of active testers and =
developers who
>> can fix bugs rapidly, freezing master and doing the release may take =
a lot
>> of time (unless if we can put a hard deadline or have some schedule =
to
>> support that?), in which case new features and refactoring work will =
have
>> to lay hanging (and some rebase/code-rework may be needed later when =
they
>> are merged, when master is open)
>>=20
> =E2=80=8Blso very valid. No freeze, just release candidates would be a =
solution to
> that. One point in time is proposed as candidate and voted on. if it =
goes
> it goes, if it doesn't there will be new chances in the near future. =
We do
> depend on good quality control on master for this.
> =E2=80=8B
>=20
>=20
>>=20
>> - release risk:
>>=20
>> after a release x.y.0 is made and since master can receive new =
features,
>> refactoring work; the next x.y.1 can potentially add more regressions =
due
>> to those new features and refactoring/re-architectural work
>>=20
> =E2=80=8BI don't agree here; any x.y.1 will be on a branch other then =
master.=E2=80=8B
>=20
>=20
>=20
>>=20
>> - release maintenance and support demands:
>>=20
>> historically there has been an assumed or known stable release that =
is
>> fairly tested in the wild and has built trust due to usage by users
>> (through meetups, users ML, customer interactions etc), in the past =
those
>> versions were 4.2.1 then 4.3.1/4.3.2, now based on my experience the =
last
>> stable release is 4.5.1
>>=20
> =E2=80=8BYou know we don't agree on 4.4 vs 4.5 and I don't want to =
fight that fight
> here and now but how is this a concern either way? Any minor can have =
point
> releases following it if needed.
> =E2=80=8B
>=20
>=20
>=20
>>  [1]
>> =
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+=
for+Apache+CloudStack
>>=20
>> On 02-Jul-2015, at 5:16 pm, Remi Bergsma <remi@remi.nl> wrote:
>>=20
>> Hi all,
>>=20
>> We already agreed contributions should always go via a PR and require =
two
>> LGTM=E2=80=99s before we merge. Let me propose the next step on how I =
think we
>> should do release management for 4.6 and on.
>>=20
>> I talked to several people over the past weeks and wrote this wiki =
article:
>>=20
>> =
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+=
for+Apache+CloudSta
>> ck <
>> =
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Release+principles+=
for+Apache+CloudStack
>>>=20
>>=20
>> If you like this way of working, I volunteer to be your RM :-)
>>=20
>> Like folks suggested earlier, it would be nice to work on this with
>> multiple people. So, feel free to join. Maybe @dahn @bhaisaab and/or =
others
>> are willing to teach me some of their tricks.
>>=20
>>=20
> --=20
> Daan