cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Sorensen <shadow...@gmail.com>
Subject Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Date Thu, 30 May 2013 20:04:06 GMT
That's why I brought up the cycle. If we make an exception, it feels
like bending the rules, which everyone can point to in the future. I'd
rather change the rules, and in the process attempt to head-off future
attempts to bend the rules, but at some point I suppose it's just
academic. Change is change, whether temporary or permanent.

On Thu, May 30, 2013 at 11:43 AM, Chiradeep Vittal
<Chiradeep.Vittal@citrix.com> 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.
>
> 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.html
>>>
>>>
>>> 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