This thread does *not* appear to have reached a consensus. As a project, we typically work to achieve consensus without any sort of formal VOTE. However, I believe that we are going to need one.
I'll kick one off momentarily. On Fri, May 31, 2013 at 02:35:22AM +0000, Animesh Chaturvedi wrote: > > > > On May 30, 2013, at 1:57 PM, "John Burwell" <jburw...@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.ponnaga...@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.chaturv...@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: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.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.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> > >>>>>>> * * > >> >
