Thanks Chip Thanks Animesh
On May 31, 2013, at 7:34 AM, "Chip Childers" <chip.child...@sungard.com> wrote: > 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> >>>>>>>>> * * >>
