cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Date Fri, 31 May 2013 00:21:31 GMT
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.tutkowski@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.chaturvedi@citrix.com> wrote:
>
>> Accidently sent too soon, updated my response in-line to Mike
>>
>> > -----Original Message-----
>> > From: Animesh Chaturvedi [mailto:animesh.chaturvedi@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.tutkowski@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.chaturvedi@citrix.com> wrote:
>> > >
>> > > >
>> > > >
>> > > > > -----Original Message-----
>> > > > > From: Wido den Hollander [mailto:wido@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" <jburwell@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.Vittal@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.tutkowski@solidfire.com>
>> > > > > >>> wrote:
>> > > > > >>>
>> > > > > >>>> +1 Four weeks extra would be ideal in this situation.
>> > > > > >>>>
>> > > > > >>>>
>> > > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien
Goasguen
>> > > > > >>>> <runseb@gmail.com>wrote:
>> > > > > >>>>
>> > > > > >>>>>
>> > > > > >>>>>
>> > > > > >>>>> On 30 May 2013, at 06:34, Chip Childers
>> > > > > >>>>> <chip.childers@sungard.com>
>> > > > > >>>>> wrote:
>> > > > > >>>>>
>> > > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
>> > > > > >>>>>> <jburwell@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.tutkowski@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.tutkowski@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.tutkowski@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.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message