cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Animesh Chaturvedi <animesh.chaturv...@citrix.com>
Subject Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Date Fri, 31 May 2013 02:35:22 GMT



On May 30, 2013, at 1:57 PM, "John Burwell" <jburwell@basho.com> wrote:

> All,
> 
> I apologize for a lack of clarity in the original proposal, but I intended
> for 4 week extension on the feature freeze to be added onto the release and
> not encroach on the test window.
> 
> Thanks,
> -John
> 

[Animesh] So what is the final call are we extending the release by 4 weeks?

> 
> On Thu, May 30, 2013 at 4:46 PM, Sudha Ponnaganti <
> sudha.ponnaganti@citrix.com> wrote:
> 
>> +1  on limiting feature proposals for 1 week so scope would not increase
>> dramatically.
>> 
>> +1 on the time line proposed - The extension proposed by Animesh would
>> help to close feature which are almost ready for check-in but need quality
>> checks. This would help for overall quality.
>> 
>> -----Original Message-----
>> From: Animesh Chaturvedi [mailto:animesh.chaturvedi@citrix.com]
>> Sent: Thursday, May 30, 2013 1:12 PM
>> To: dev@cloudstack.apache.org
>> Subject: RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>> 
>> 
>> 
>>> -----Original Message-----
>>> From: Wido den Hollander [mailto:wido@widodh.nl]
>>> Sent: Thursday, May 30, 2013 11:42 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>> 
>>> 
>>> 
>>> On 05/30/2013 07:43 PM, Chiradeep Vittal wrote:
>>>> I'm actually OK with delaying the release (as you pointed out, 4.1
>>>> impacted 4.2 in a big way). *I* like flexibility. But it behooves
>>>> the community to have a stable set of rules.
>>>> 
>>>> It is the cognitive dissonance that bothers me. Theoretically a
>>>> time-based release doesn't care about such impacts, but reality is
>>>> that if someone has been working on a feature for 4 months and it
>>>> doesn't make it because of the cut-off, they are going to feel
>>>> aggrieved, especially if at some point in the past the community
>>> agreed to make an exception.
>>> 
>>> I ack on this one. A lot of work went into the object store branch
>>> (since that's what discussion seems to be pointing at) and it would be
>>> a nightmare for the developers to merge this into 4.3.
>>> 
>>> John had valid points on the merge of the branch, but imho those can
>>> be fixed after it's merged in.
>>> 
>>> It's feature freeze, but it doesn't mean that we can't do any
>>> squashing of bugs.
>>> 
>>> Other developers are also waiting on merging their stuff in after the
>>> freeze so it will hit 4.3
>>> 
>>> I wouldn't open the window for features longer since that might bring
>>> more stuff into 4.2 which needs QA as well.
>>> 
>>> Wido
>> [Animesh>] Like in the original schedule for 4.1 / 4.2 feature proposals
>> are closed 3-4 weeks before the freeze date, we can still go with
>> compromise of 4 weeks extension in feature freeze date but limit feature
>> proposal to come in by June 1st week
>> 
>>>> On 5/30/13 3:49 AM, "John Burwell" <jburwell@basho.com> wrote:
>>>> 
>>>>> Chiradeep,
>>>>> 
>>>>> As I understood that conversation, it was about permanently
>>>>> changing the length of release cycles.  I am proposing that we
>>>>> acknowledge the impact of the longer than anticipated 4.1.0
>>>>> release, and push out 4.2.0.  4.3.0 would still be a four month
>>>>> release cycle, it would just start X weeks later.
>>>>> 
>>>>> I like Chip's compromise of 4 weeks.  I think it would be a great
>>>>> benefit to the 4.2.0 release if the community had the opportunity
>>>>> to completely focus on its development for some period of time.
>>>>> 
>>>>> Finally, to David's concern that other features might be added
>>>>> during such an extension.  I think that would be acceptable
>>>>> provided they pass review.  The goal of my proposal is not permit
>>>>> more features but to give the community time to review and
>>>>> collaborate on changes coming into the release.  If additional high
>>>>> quality feature implementations happen to get merged in during that
>>>>> period then I consider that a happy side effect.
>>>>> 
>>>>> Thanks,
>>>>> -John
>>>>> 
>>>>> 
>>>>> On May 30, 2013, at 1:51 AM, Chiradeep Vittal
>>>>> <Chiradeep.Vittal@citrix.com> wrote:
>>>>> 
>>>>>> This topic was already discussed here:
>>>>>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.htm
>>>>>> l
>>>>>> 
>>>>>> 
>>>>>> The consensus then was "revisit *after* 4.2". I won't rehash the
>>>>>> pros and cons, please do familiarize yourself with that thread.
>>>>>> 
>>>>>> 
>>>>>> On 5/29/13 10:10 PM, "Mike Tutkowski"
>>>>>> <mike.tutkowski@solidfire.com>
>>>>>> wrote:
>>>>>> 
>>>>>>> +1 Four weeks extra would be ideal in this situation.
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>>>>> <runseb@gmail.com>wrote:
>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On 30 May 2013, at 06:34, Chip Childers
>>>>>>>> <chip.childers@sungard.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jburwell@basho.com>
>>> wrote:
>>>>>>>>> 
>>>>>>>>>> All,
>>>>>>>>>> 
>>>>>>>>>> Since we have taken an eight (8) week delay completing
the
>>>>>>>>>> 4.1.0
>>>>>>>> release, I would like propose that we re-evaluate the timelines
>>>>>>>> for the
>>>>>>>> 4.2.0 release.  When the schedule was originally conceived,
it
>>>>>>>> was intended that the project would have eight (8) weeks
to
>>>>>>>> focus exclusively on
>>>>>>>> 4.2.0
>>>>>>>> development.  Unfortunately, this delay has created an
>>>>>>>> unfortunate conflict between squashing 4.1.0 bugs and completing
>>>>>>>> 4.2.0 features.  I propose that we acknowledge this schedule
>>>>>>>> impact, and push back the 4.2.0 feature freeze date by eight
(8)
>>>>>>>> weeks to 2 August 2013.  This delay will give the project
time
>>>>>>>> to properly review merges and address issues holistically,
and,
>>>>>>>> hopefully, relieve a good bit of the stress incurred by the
>>>>>>>> simultaneous
>>>>>>>> 4.1.0 and 4.2.0 activities.
>>>>>>>>>> 
>>>>>>>>>> Thanks,
>>>>>>>>>> -John
>>>>>>>>> 
>>>>>>>>> This is a reasonable idea IMO. I'd probably only extend
by a
>>>>>>>>> month personally, but your logic is sound.  I'd much
rather
>>>>>>>>> have reasoned discussions about code than argue procedural
>>>>>>>>> issues about timing any day. This might help facilitate
that on
>>>>>>>>> some of the features folks are scrambling to complete.
>>>>>>>>> 
>>>>>>>>> Others?
>>>>>>>> 
>>>>>>>> I am +1 on this, 4 weeks maybe ?
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> *Mike Tutkowski*
>>>>>>> *Senior CloudStack Developer, SolidFire Inc.*
>>>>>>> e: mike.tutkowski@solidfire.com
>>>>>>> o: 303.746.7302
>>>>>>> Advancing the way the world uses the
>>>>>>> cloud<http://solidfire.com/solution/overview/?video=play>
>>>>>>> * *
>> 

Mime
View raw message