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 jburwell@basho.com designates
 209.85.128.52 as permitted sender)
Content-Type: text/plain; charset=iso-8859-1
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
From: John Burwell <jburwell@basho.com>
In-Reply-To: 
 <CALFpzo5v181er_5j4CcCK1e_DuMd4bnMkd5r-Xen8mxZFFv6hw@mail.gmail.com>
Date: Thu, 30 May 2013 12:59:43 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <DD66B74B-F486-491A-B251-441556A49DE0@basho.com>
References: <DE7A3FDC-CF61-4217-877B-859FA577E2F9@basho.com>
 <7049291235333515806@unknownmsgid>
 <CAP95EBL2piW936RMg+_suCn5DQx_XOAqOWrEje0CzdkVPg9fJw@mail.gmail.com>
 <CAKprHVZsspESyVa_h2-HHG+_eaxR-1-iSn9Qe6Dtmj6txNaJBA@mail.gmail.com>
 <DEB2697CC649A142980A3B54B3B818C309992E@SINPEX01CL02.citrite.net>
 <20130530131320.GP52702@USLT-205755.sungardas.corp>
 <07B22C5ED940BF49B3438A3983DB577502BE8E@SJCPEX01CL03.citrite.net>
 <20130530145603.GX52702@USLT-205755.sungardas.corp>
 <CALFpzo5v181er_5j4CcCK1e_DuMd4bnMkd5r-Xen8mxZFFv6hw@mail.gmail.com>
To: dev@cloudstack.apache.org

Marcus,

I think it best to defer the larger release cycle length question to =
another time and place.  As Chip stated earlier, the consensus is to =
maintain the current freeze date.  Given the time sensitivity, my =
proposal can be considered resolved.

Thanks,
-John

On May 30, 2013, at 11:34 AM, Marcus Sorensen <shadowsor@gmail.com> =
wrote:

> I think there does need to be some course correction, but perhaps we
> should look at the development cycle overall and the lessons learned
> from 4.1.  Did we not allocate enough time for bugfixing? Did we allow
> too many low-quality merges for the time allotted? Did we have issues
> with the overlap (allowing new features into master while bugfixing/QA
> needed to be focused on)? Or something else? Or maybe all of it?
>=20
> One thing that may help is to have some sort of feature review during
> the development cycle. Maybe at the halfway point we make a list if
> what will be in this release, with the intent of weeding out last
> minute bombs being dropped just before feature freeze. If a relatively
> large change isn't feature complete and its devs don't have it testing
> 3-4 weeks before feature freeze, then it gets moved to the next
> release. Sort of a sliding window for feature freeze, based on
> complexity. I know we've sort of said 'big changes can only land at
> the beginning of a cycle' once or twice, but I think making it
> official via some sort of review that pins features into releases
> would be helpful in solidifying that (as well as developer
> expectations).
>=20
> Or maybe we extend the time between feature freeze and code freeze,
> knowing that features are inevitably going to be rushed in at the last
> minute.
>=20
> I'm not sure what the correct answer is, but if we're going to talk
> about adjusting the 4.2 release, I thought it might be wise to
> consider fine-tuning the development cycle in general.
>=20
> On Thu, May 30, 2013 at 8:56 AM, Chip Childers
> <chip.childers@sungard.com> wrote:
>> On Thu, May 30, 2013 at 01:52:28PM +0000, Sudha Ponnaganti wrote:
>>> 4.2 already has lot of features ( Around 70+ features ) added and =
require hardening once feature freeze happens. This release is bigger =
than any other release.  Even though 1 round of testing is being done =
for majority of the features, there are quite a few that require =
community help to build quality. By adding more features, it would be =
that much difficult to harden the release.
>>>=20
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Thursday, May 30, 2013 6:13 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>>=20
>>> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>>>>=20
>>>>=20
>>>>> -----Original Message-----
>>>>> From: David Nalley [mailto:david@gnsa.us]
>>>>> Sent: Thursday, May 30, 2013 12:36 PM
>>>>> To: dev@cloudstack.apache.org
>>>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>>>>=20
>>>>> On Thu, May 30, 2013 at 3:02 AM, murali reddy
>>>>> <muralimmreddy@gmail.com> wrote:
>>>>>> We should do a health-check of proposed features [1] which are at
>>>>>> risk for
>>>>>> 4.2 feature freeze before deciding to re-evaluate timelines.
>>>>>>=20
>>>>>=20
>>>>> We are supposedly doing time-based release, so we don't care about
>>>>> what features make it versus don't.
>>>>=20
>>>> 4.1 was also supposed to be a time based one but got delayed due to =
various issues. So not sure what would be the right approach here. I =
think it makes sense to look at the feature list to see if some of them =
(individual features can be voted upon) can be accommodated in 4.2. If =
there are no such features then there is no need for extending the =
cutoff date.
>>>>=20
>>>=20
>>> 4.1's *feature freeze* was not extended (with the exception of =
Javelin merging in at the very end).  What delayed us were quality =
issues...
>>> and frankly the "stabilization" period isn't something that I =
personally consider to be the critical date to hit.  It's going to vary, =
based on what we find during testing.  To me, the time-based approach is =
focused on the feature merge window primarily, and (over time) getting =
some consistency in our actual release dates.  I think we are still =
learning to work with a feature freeze...  we can get better at the tail =
end after we get better at bringing in only *known good* features into =
master.
>>>=20
>>=20
>> I have to say that I'm actually surprised at the number of developers
>> that want to hold to the schedule...  and I'm happy if we stick to =
our
>> guns.  I'm also OK with extending a bit (if that had been the
>> consensus).
>>=20
>> Sounds like we are mostly agreeing that we should stick to the =
existing
>> schedule for feature freeze?
>>=20
>> -chip