cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Burwell <jburw...@basho.com>
Subject Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Date Thu, 30 May 2013 20:57:13 GMT
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


On Thu, May 30, 2013 at 4:46 PM, Sudha Ponnaganti <
sudha.ponnaganti@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.chaturvedi@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: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.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.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>
> > >>>> * *
> > >>>
> > >
>

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