> -----Original Message----- > From: Wido den Hollander [mailto:w...@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" <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> > >>>> ** > >>> > >
