Mike please start your proposal in a separate email thread. Thanks Animesh
On May 30, 2013, at 6:26 PM, "Mike Tutkowski" <mike.tutkow...@solidfire.com> wrote: > Here is my design document: > > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Implement+SolidFire+(storage)+plug-in+and+expose+control+of+IOPS+to+admins+and+end+users > > I apologize for not understanding the process when it comes to adding > plug-ins to CloudStack. > > Thanks for taking a look! :) > > > On Thu, May 30, 2013 at 6:21 PM, Mike Tutkowski < > mike.tutkow...@solidfire.com> wrote: > >> I have created the following JIRA ticket: >> >> https://issues.apache.org/jira/browse/CLOUDSTACK-2778 >> >> >> On Thu, May 30, 2013 at 6:11 PM, Mike Tutkowski < >> mike.tutkow...@solidfire.com> wrote: >> >>> Thanks, Animesh...I will take a look at the Design Documents link you >>> provided. >>> >>> >>> On Thu, May 30, 2013 at 5:55 PM, Animesh Chaturvedi < >>> animesh.chaturv...@citrix.com> wrote: >>> >>>> Accidently sent too soon, updated my response in-line to Mike >>>> >>>>> -----Original Message----- >>>>> From: Animesh Chaturvedi [mailto:animesh.chaturv...@citrix.com] >>>>> Sent: Thursday, May 30, 2013 4:50 PM >>>>> To: dev@cloudstack.apache.org >>>>> Subject: RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: Mike Tutkowski [mailto:mike.tutkow...@solidfire.com] >>>>>> Sent: Thursday, May 30, 2013 1:20 PM >>>>>> To: dev@cloudstack.apache.org >>>>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze >>>>>> >>>>>> Hi Animesh, >>>>>> >>>>>> I know you and I talked about this earlier in the month, but I just >>>>>> wanted to make sure we were OK with me not providing a feature >>>>>> proposal for the storage plug-in work I'm doing for 4.2. >>>>>> >>>>>> As you may recall, I have developed a storage plug-in for SolidFire, >>>>>> enhanced the storage framework, and submitted the code a couple days >>>>>> ago. >>>>>> >>>>>> Please let me know. >>>>>> >>>>>> Thanks! >>>>> [Animesh>] In your previous email you had asked on how to handle if you >>>>> are not able to complete the implementation by freeze date and I had >>>>> responded that we are on time bound release and if a logical chunk is >>>>> available by freeze date that has been tested and ready, that chunk can >>>>> come in. My bad I did not realize that feature proposal was not >>>>> submitted for your plugin. I see your patch request >>>>> https://reviews.apache.org/r/11479/ submitted on 5/28 has good >>>>> description but it's not complete as per our design documents. Here is >>>>> link to 4.2 Design Documents on wiki >>>>> https://cwiki.apache.org/confluence/x/dzXVAQ. We follow the process >>>> outlined in >>>>> >>>> https://cwiki.apache.org/confluence/display/CLOUDSTACK/Adding+new+features+and+design+documentsfor >>>> proposing new features >>>>> >>>>> Comments from anyone else in community, with the current 4.2 timeline >>>>> the proposal date is already past due, how should we suggest we proceed >>>>> on Mike's contribution? I think formal proposal and discussion needs to >>>>> happen for inclusion. >>>>> >>>>> If we move towards extending the freeze date by 4 weeks then obviously >>>>> it is not an issue. >>>>> >>>>> >>>>>> >>>>>> On Thu, May 30, 2013 at 2:11 PM, Animesh Chaturvedi < >>>>>> animesh.chaturv...@citrix.com> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>>> -----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 >>>>>>>>>>> .h >>>>>>>>>>> tml >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 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> >>>>>>>>>>>> * * >>>>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *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> >>>>>> *(tm)* >>>> >>> >>> >>> >>> -- >>> *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> >>> *™* >>> >> >> >> >> -- >> *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> >> *™* >> > > > > -- > *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> > *™*
