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" <jburw...@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.vit...@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.tutkow...@solidfire.com> >>wrote: >> >>> +1 Four weeks extra would be ideal in this situation. >>> >>> >>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen >>> <run...@gmail.com>wrote: >>> >>>> >>>> >>>> On 30 May 2013, at 06:34, Chip Childers <chip.child...@sungard.com> >>>> wrote: >>>> >>>>> On May 29, 2013, at 7:59 PM, John Burwell <jburw...@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.tutkow...@solidfire.com >>> o: 303.746.7302 >>> Advancing the way the world uses the >>> cloud<http://solidfire.com/solution/overview/?video=play> >>> ** >>
