Mailing-List: contact dev-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Received-SPF: pass (athena.apache.org: domain of Rajani.Karuturi@citrix.com
 designates 103.14.252.240 as permitted sender)
From: Rajani Karuturi <Rajani.Karuturi@citrix.com>
To: dev <dev@cloudstack.apache.org>
Subject: Re: Release cadence
Thread-Topic: Release cadence
Thread-Index: AQHPPttjiMfaRkqmkkO64Sxm0VWQxprk/tgAgALO2YA=
Date: Wed, 19 Mar 2014 11:45:46 +0000
Message-ID: <A12696D0-DBA6-435E-B060-67284C98C8BE@citrix.com>
References: 
 <CAKprHVbAzp73uC1djt_Xcg0m8L6k_-a8oJ2Ts2X-TXXRoU3mXg@mail.gmail.com>
 <0688F941-7001-4FB7-B23A-EF4576EA6815@stratosec.co>
In-Reply-To: <0688F941-7001-4FB7-B23A-EF4576EA6815@stratosec.co>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <6D25E8967C46A147A3C10DA4DAA34E9A@citrix.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

The primary problem I feel is that we dont plan our releases.(I am fairly n=
ew here and I may be wrong)
The role of the release manager starts only during the RC creation phase as=
king for votes(again I maybe wrong).

I feel it should start much earlier. Everyone who is actively involved shou=
ld have a clear idea on what we are going to release next.
We do this to an extent by sending proposals etc. but we really dont do pla=
nning and the big picture is missing.=20

I think the RM should facilitate planning of the release and in the process=
 take feedback from the committers and users who are going to work on the r=
elease.=20
A single view of the current release status also would help immensely.=20

I like the way brackets.io does the release management through trello board=
s[1]. Probably we could explore such options. It facilities voting on featu=
res, gives a quick view of whats getting in the release which would help QA=
/anyone interested in testing to plan the testing early on instead of waiti=
ng for RC.


I am for for short release cycles. "Release early, release often"
It shows project activity and builds developer confidence as long as we do =
quality releases :)=20


[1] https://trello.com/b/LCDud1Nd/brackets


~Rajani


On 17-Mar-2014, at 10:22 pm, John Kinsella <jlk@stratosec.co> wrote:

> I am in agreement with my radical CloudStack brother.
>=20
>=20
> On Mar 13, 2014, at 9:42 AM, David Nalley <david@gnsa.us> wrote:
>=20
>> The RC7 vote thread contained a lot of discussion around release
>> cadence, and I figured I'd move that to a thread that has a better
>> subject so there is better visibility to list participants who don't
>> read every thread.
>>=20
>> When I look at things schedule wise, I see our aims and our reality.
>> We have a relatively short development window (in the schedule) and we
>> have almost 50% of our time in the schedule allocated to testing.
>> (over two months). However, it seems that a lot of testing - or at
>> least a lot of testing for  what became blockers to the release didn't
>> appear to happen until RCs were kicked out - and that's where our
>> schedule has fallen apart for multiple releases. The automated tests
>> we have were clean when we issued RCs, so we clearly don't have the
>> depth needed from an automated standpoint.
>>=20
>> Two problems, one cultural and one technical. The technical problem is
>> that our automated test suite isn't deep enough to give us a high
>> level of confidence that we should release. The cultural problem is
>> that many of us wait until the release period of the schedule to test.
>>=20
>> What does that have to do with release cadence? Well inherently not
>> much; but let me describe my concerns. As a project; the schedule is
>> meaningless if we don't follow it; and effectively the release date is
>> held hostage. Personally, I do want as few bugs as possible, but it's
>> a balancing act where people doubt our ability if we aren't able to
>> ship. I don't think it matters if we move to 6 month cycles, if this
>> behavior continues, we'd miss the 6 month date as well and push to 8
>> or 9 months. See my radical proposition at the bottom for an idea on
>> dealing with this.
>>=20
>> I also find myself agreeing with Daan on the additional complexity.
>> Increasing the window for release inherently increases the window for
>> feature development. As soon as we branch a release, master is open
>> for feature development again. This means a potential for greater
>> change at each release. Change is a risk to quality; or at least an
>> unknown that we again have to test. The greater that quantity of
>> change, the greater the potential threat to quality.
>>=20
>> Radical proposition:
>>=20
>> Because we have two problems, of different nature, we are in a
>> difficult situation. This is a possible solution, and I'd appreciate
>> you reading and considering it.  Feedback is welcome. I propose that
>> after we enter the RC stage that we not entertain any bugs as blockers
>> that don't have automated test cases associated with them. This means
>> that you are still welcome to do manual testing of your pet feature
>> and the things that are important to you; during the testing window
>> (or anytime really). However, if the automation suite isn't also
>> failing then we consider the release as high enough quality to ship.
>> This isn't something we can codify, but the PMC can certainly adopt
>> this attitude as a group when voting. Which also means that we can
>> deviate from it. If you brought up a blocker for release - we should
>> be immediately looking at how we can write a test for that behavior.
>> This should also mean several other behaviors need to become a valid
>> part of our process. We need to ensure that things are well tested
>> before allowing a merge. This means we need a known state of master,
>> and we need to perform testing that allows us to confirm that a patch
>> does no harm. We also need to insist on implementation of
>> comprehensive tests for every inbound feature.
>>=20
>> Thoughts, comments, flames, death threats? :)
>>=20
>> --David
>=20