You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by John Burwell <jb...@basho.com> on 2013/05/30 01:59:03 UTC
[PROPOSAL] Pushback 4.2.0 Feature Freeze
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
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Donal Lafferty <do...@citrix.com>.
Compromise without change?
Bring 4.3 forward by two months, leave 4.2 as it is.
DL
> -----Original Message-----
> From: Wei ZHOU [mailto:ustcweizhou@gmail.com]
> Sent: 30 May 2013 8:27 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>
> +1
> two weeks delay for feature freeze,
> no extension for 4.3 release
>
> -Wei
>
>
> 2013/5/30 John Burwell <jb...@basho.com>
>
> > 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
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Wei ZHOU <us...@gmail.com>.
+1
two weeks delay for feature freeze,
no extension for 4.3 release
-Wei
2013/5/30 John Burwell <jb...@basho.com>
> 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
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Marcus Sorensen <sh...@gmail.com>.
That's why I brought up the cycle. If we make an exception, it feels
like bending the rules, which everyone can point to in the future. I'd
rather change the rules, and in the process attempt to head-off future
attempts to bend the rules, but at some point I suppose it's just
academic. Change is change, whether temporary or permanent.
On Thu, May 30, 2013 at 11:43 AM, Chiradeep Vittal
<Ch...@citrix.com> 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.
>
> On 5/30/13 3:49 AM, "John Burwell" <jb...@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
>><Ch...@citrix.com> wrote:
>>
>>> This topic was already discussed here:
>>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
>>>
>>>
>>> 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" <mi...@solidfire.com>
>>>wrote:
>>>
>>>> +1 Four weeks extra would be ideal in this situation.
>>>>
>>>>
>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>> <ru...@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com>
>>>>> wrote:
>>>>>
>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>>>> * *
>>>
>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
Thanks Chip
Thanks
Animesh
On May 31, 2013, at 7:34 AM, "Chip Childers" <ch...@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" <jb...@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.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" <jb...@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
>>>>>>> <Ch...@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"
>>>>>>>> <mi...@solidfire.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> +1 Four weeks extra would be ideal in this situation.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>>>>>>> <ru...@gmail.com>wrote:
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 30 May 2013, at 06:34, Chip Childers
>>>>>>>>>> <ch...@sungard.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>>>>>>>>> * *
>>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
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" <jb...@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.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" <jb...@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
> >>>>> <Ch...@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"
> >>>>>> <mi...@solidfire.com>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> +1 Four weeks extra would be ideal in this situation.
> >>>>>>>
> >>>>>>>
> >>>>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> >>>>>>> <ru...@gmail.com>wrote:
> >>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 30 May 2013, at 06:34, Chip Childers
> >>>>>>>> <ch...@sungard.com>
> >>>>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
> >>>>>>> * *
> >>
>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
On May 30, 2013, at 1:57 PM, "John Burwell" <jb...@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.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" <jb...@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
>>>>> <Ch...@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"
>>>>>> <mi...@solidfire.com>
>>>>>> wrote:
>>>>>>
>>>>>>> +1 Four weeks extra would be ideal in this situation.
>>>>>>>
>>>>>>>
>>>>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>>>>> <ru...@gmail.com>wrote:
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 30 May 2013, at 06:34, Chip Childers
>>>>>>>> <ch...@sungard.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>>>>>>> * *
>>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by John Burwell <jb...@basho.com>.
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" <jb...@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
> > >> <Ch...@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"
> > >>> <mi...@solidfire.com>
> > >>> wrote:
> > >>>
> > >>>> +1 Four weeks extra would be ideal in this situation.
> > >>>>
> > >>>>
> > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> > >>>> <ru...@gmail.com>wrote:
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> On 30 May 2013, at 06:34, Chip Childers
> > >>>>> <ch...@sungard.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
> > >>>> * *
> > >>>
> > >
>
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Sudha Ponnaganti <su...@citrix.com>.
+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" <jb...@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
> >> <Ch...@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"
> >>> <mi...@solidfire.com>
> >>> wrote:
> >>>
> >>>> +1 Four weeks extra would be ideal in this situation.
> >>>>
> >>>>
> >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> >>>> <ru...@gmail.com>wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 30 May 2013, at 06:34, Chip Childers
> >>>>> <ch...@sungard.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
> >>>> **
> >>>
> >
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
On Fri, May 31, 2013 at 11:13:53AM -0400, John Burwell wrote:
> Chip,
>
> As I understand the [VOTE] extension email, the code freeze is currently extended to Tuesday, 4 June 2012, regardless of the vote outcome. If my understanding is correct, then we have three more days to complete the review/feedback loop -- correct?
That was IMO, but I think it's only right... we were discussing this
and didn't come to a consensus. A couple of days doesn't hurt us in the
long run, in order to have time to come to a consensus.
Someone can yell violently at me if they strongly disagree... but I
thought it was the best course of action.
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by John Burwell <jb...@basho.com>.
Chip,
As I understand the [VOTE] extension email, the code freeze is currently extended to Tuesday, 4 June 2012, regardless of the vote outcome. If my understanding is correct, then we have three more days to complete the review/feedback loop -- correct?
Thanks,
-John
On May 31, 2013, at 11:10 AM, Chip Childers <ch...@sungard.com> wrote:
> On Thu, May 30, 2013 at 11:55:38PM +0000, Animesh Chaturvedi 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+documents for 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.
>
> It absolutely should. The only caveat I'd say, is that if it's a plugin
> ONLY there is limited risk to the rest of the software.
>
>>> If we move towards extending the freeze date by 4 weeks then obviously
>>> it is not an issue.
>
> VOTE started to extend, but we should be working with Mike either way
> here. If it's agreed on and merged into master before the cut, it's in
> 4.2. If we do it a day after, then it's 4.3. We are trying to be
> time-based so that features can merge in (especially isolated ones)
> anytime really (if quality is good and there's consensus on technical
> approach). It's just a question of what release branch it makes it
> into.
>
> -chip
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
On Thu, May 30, 2013 at 11:55:38PM +0000, Animesh Chaturvedi 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+documents for 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.
It absolutely should. The only caveat I'd say, is that if it's a plugin
ONLY there is limited risk to the rest of the software.
> > If we move towards extending the freeze date by 4 weeks then obviously
> > it is not an issue.
VOTE started to extend, but we should be working with Mike either way
here. If it's agreed on and merged into master before the cut, it's in
4.2. If we do it a day after, then it's 4.3. We are trying to be
time-based so that features can merge in (especially isolated ones)
anytime really (if quality is good and there's consensus on technical
approach). It's just a question of what release branch it makes it
into.
-chip
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
Mike please start your proposal in a separate email thread.
Thanks
Animesh
On May 30, 2013, at 6:26 PM, "Mike Tutkowski" <mi...@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.tutkowski@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.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" <jb...@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
>>>>>>>>>> <Ch...@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"
>>>>>>>>>>> <mi...@solidfire.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> +1 Four weeks extra would be ideal in this situation.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>>>>>>>>>> <ru...@gmail.com>wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 30 May 2013, at 06:34, Chip Childers
>>>>>>>>>>>>> <ch...@sungard.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> On May 29, 2013, at 7:59 PM, John Burwell
>>>>>>>>>>>>>> <jb...@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>
>> *™*
>>
>
>
>
> --
> *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>
> *™*
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Mike Tutkowski <mi...@solidfire.com>.
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.tutkowski@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.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" <jb...@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
>>> > > > > >> <Ch...@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"
>>> > > > > >>> <mi...@solidfire.com>
>>> > > > > >>> wrote:
>>> > > > > >>>
>>> > > > > >>>> +1 Four weeks extra would be ideal in this situation.
>>> > > > > >>>>
>>> > > > > >>>>
>>> > > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>> > > > > >>>> <ru...@gmail.com>wrote:
>>> > > > > >>>>
>>> > > > > >>>>>
>>> > > > > >>>>>
>>> > > > > >>>>> On 30 May 2013, at 06:34, Chip Childers
>>> > > > > >>>>> <ch...@sungard.com>
>>> > > > > >>>>> wrote:
>>> > > > > >>>>>
>>> > > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
>>> > > > > >>>>>> <jb...@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>
> *™*
>
--
*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>
*™*
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Mike Tutkowski <mi...@solidfire.com>.
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" <jb...@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
>> > > > > >> <Ch...@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"
>> > > > > >>> <mi...@solidfire.com>
>> > > > > >>> wrote:
>> > > > > >>>
>> > > > > >>>> +1 Four weeks extra would be ideal in this situation.
>> > > > > >>>>
>> > > > > >>>>
>> > > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>> > > > > >>>> <ru...@gmail.com>wrote:
>> > > > > >>>>
>> > > > > >>>>>
>> > > > > >>>>>
>> > > > > >>>>> On 30 May 2013, at 06:34, Chip Childers
>> > > > > >>>>> <ch...@sungard.com>
>> > > > > >>>>> wrote:
>> > > > > >>>>>
>> > > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
>> > > > > >>>>>> <jb...@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>
*™*
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Mike Tutkowski <mi...@solidfire.com>.
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" <jb...@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
> > > > > >> <Ch...@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"
> > > > > >>> <mi...@solidfire.com>
> > > > > >>> wrote:
> > > > > >>>
> > > > > >>>> +1 Four weeks extra would be ideal in this situation.
> > > > > >>>>
> > > > > >>>>
> > > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> > > > > >>>> <ru...@gmail.com>wrote:
> > > > > >>>>
> > > > > >>>>>
> > > > > >>>>>
> > > > > >>>>> On 30 May 2013, at 06:34, Chip Childers
> > > > > >>>>> <ch...@sungard.com>
> > > > > >>>>> wrote:
> > > > > >>>>>
> > > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
> > > > > >>>>>> <jb...@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>
*™*
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
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+documents for 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" <jb...@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
> > > > >> <Ch...@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"
> > > > >>> <mi...@solidfire.com>
> > > > >>> wrote:
> > > > >>>
> > > > >>>> +1 Four weeks extra would be ideal in this situation.
> > > > >>>>
> > > > >>>>
> > > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> > > > >>>> <ru...@gmail.com>wrote:
> > > > >>>>
> > > > >>>>>
> > > > >>>>>
> > > > >>>>> On 30 May 2013, at 06:34, Chip Childers
> > > > >>>>> <ch...@sungard.com>
> > > > >>>>> wrote:
> > > > >>>>>
> > > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
> > > > >>>>>> <jb...@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)*
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----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. Also I did not find a JIRA ticket.
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 .
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" <jb...@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
> > > >> <Ch...@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"
> > > >>> <mi...@solidfire.com>
> > > >>> wrote:
> > > >>>
> > > >>>> +1 Four weeks extra would be ideal in this situation.
> > > >>>>
> > > >>>>
> > > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> > > >>>> <ru...@gmail.com>wrote:
> > > >>>>
> > > >>>>>
> > > >>>>>
> > > >>>>> On 30 May 2013, at 06:34, Chip Childers
> > > >>>>> <ch...@sungard.com>
> > > >>>>> wrote:
> > > >>>>>
> > > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell
> > > >>>>>> <jb...@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)*
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Mike Tutkowski <mi...@solidfire.com>.
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!
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" <jb...@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
> > >> <Ch...@citrix.com> wrote:
> > >>
> > >>> This topic was already discussed here:
> > >>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
> > >>>
> > >>>
> > >>> 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" <mi...@solidfire.com>
> > >>> wrote:
> > >>>
> > >>>> +1 Four weeks extra would be ideal in this situation.
> > >>>>
> > >>>>
> > >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> > >>>> <ru...@gmail.com>wrote:
> > >>>>
> > >>>>>
> > >>>>>
> > >>>>> On 30 May 2013, at 06:34, Chip Childers
> > >>>>> <ch...@sungard.com>
> > >>>>> wrote:
> > >>>>>
> > >>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
*™*
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----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" <jb...@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
> >> <Ch...@citrix.com> wrote:
> >>
> >>> This topic was already discussed here:
> >>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
> >>>
> >>>
> >>> 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" <mi...@solidfire.com>
> >>> wrote:
> >>>
> >>>> +1 Four weeks extra would be ideal in this situation.
> >>>>
> >>>>
> >>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
> >>>> <ru...@gmail.com>wrote:
> >>>>
> >>>>>
> >>>>>
> >>>>> On 30 May 2013, at 06:34, Chip Childers
> >>>>> <ch...@sungard.com>
> >>>>> wrote:
> >>>>>
> >>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
> >>>> **
> >>>
> >
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Wido den Hollander <wi...@widodh.nl>.
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
> On 5/30/13 3:49 AM, "John Burwell" <jb...@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
>> <Ch...@citrix.com> wrote:
>>
>>> This topic was already discussed here:
>>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
>>>
>>>
>>> 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" <mi...@solidfire.com>
>>> wrote:
>>>
>>>> +1 Four weeks extra would be ideal in this situation.
>>>>
>>>>
>>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>>> <ru...@gmail.com>wrote:
>>>>
>>>>>
>>>>>
>>>>> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com>
>>>>> wrote:
>>>>>
>>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>>>> **
>>>
>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chiradeep Vittal <Ch...@citrix.com>.
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.
On 5/30/13 3:49 AM, "John Burwell" <jb...@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
><Ch...@citrix.com> wrote:
>
>> This topic was already discussed here:
>> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
>>
>>
>> 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" <mi...@solidfire.com>
>>wrote:
>>
>>> +1 Four weeks extra would be ideal in this situation.
>>>
>>>
>>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>>> <ru...@gmail.com>wrote:
>>>
>>>>
>>>>
>>>> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com>
>>>> wrote:
>>>>
>>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>>> **
>>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by John Burwell <jb...@basho.com>.
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
<Ch...@citrix.com> wrote:
> This topic was already discussed here:
> http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
>
>
> 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" <mi...@solidfire.com> wrote:
>
>> +1 Four weeks extra would be ideal in this situation.
>>
>>
>> On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
>> <ru...@gmail.com>wrote:
>>
>>>
>>>
>>> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com>
>>> wrote:
>>>
>>>> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>> **
>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chiradeep Vittal <Ch...@citrix.com>.
This topic was already discussed here:
http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.html
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" <mi...@solidfire.com> wrote:
>+1 Four weeks extra would be ideal in this situation.
>
>
>On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
><ru...@gmail.com>wrote:
>
>>
>>
>> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com>
>>wrote:
>>
>> > On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
>**
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Mike Tutkowski <mi...@solidfire.com>.
+1 Four weeks extra would be ideal in this situation.
On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen <ru...@gmail.com>wrote:
>
>
> On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com> wrote:
>
> > On May 29, 2013, at 7:59 PM, John Burwell <jb...@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>
*™*
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Sebastien Goasguen <ru...@gmail.com>.
On 30 May 2013, at 06:34, Chip Childers <ch...@sungard.com> wrote:
> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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 ?
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Murali Reddy <mu...@gmail.com>.
Yes. We agreed on time based release. I am failing to see what would extending freeze date will achieve.
On 30-May-2013, at 12:34 PM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 30, 2013 at 3:02 AM, murali reddy <mu...@gmail.com> wrote:
>> We should do a health-check of proposed features [1] which are at risk for
>> 4.2 feature freeze before deciding to re-evaluate timelines.
>
> We are supposedly doing time-based release, so we don't care about
> what features make it versus don't.
>
> --David
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Animesh Chaturvedi <an...@citrix.com>.
> -----Original Message-----
> From: John Burwell [mailto:jburwell@basho.com]
> Sent: Thursday, May 30, 2013 6:51 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>
> David and Chip,
>
> To be clear about my proposal, I did not intend to propose that we push
> back the feature freeze by x days of time and subtract x days from
> testing. My intention is to add those days into the cycle without
> reducing the test window -- pushing the release date out x days.
>
> Another perspective is that we are acknowledging the likelihood that
> 4.1.0 delay will cascade into the 4.2.0 cycle. Rather than hoping we
> can absorb the impact, we embrace it early to reduce the time pressure
> on the community, reset expectations with our users, and increase the
> probability of high quality release.
>
> Thanks,
> -John
>
[Animesh>] Yes if we push out the freeze then the release date also gets pushed out by the same timeframe
> On May 30, 2013, at 9:39 AM, David Nalley <da...@gnsa.us> wrote:
>
> > On Thu, May 30, 2013 at 9:13 AM, Chip Childers
> > <ch...@sungard.com> wrote:
> >> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
> >>>
> >>>
> >>>> -----Original Message-----
> >>>> From: David Nalley [mailto:david@gnsa.us]
> >>>> Sent: Thursday, May 30, 2013 12:36 PM
> >>>> To: dev@cloudstack.apache.org
> >>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
> >>>>
> >>>> On Thu, May 30, 2013 at 3:02 AM, murali reddy
> >>>> <mu...@gmail.com> wrote:
> >>>>> We should do a health-check of proposed features [1] which are at
> >>>>> risk for
> >>>>> 4.2 feature freeze before deciding to re-evaluate timelines.
> >>>>>
> >>>>
> >>>> We are supposedly doing time-based release, so we don't care about
> >>>> what features make it versus don't.
> >>>
> >>> 4.1 was also supposed to be a time based one but got delayed due to
> various issues. So not sure what would be the right approach here. I
> think it makes sense to look at the feature list to see if some of them
> (individual features can be voted upon) can be accommodated in 4.2. If
> there are no such features then there is no need for extending the
> cutoff date.
> >>>
> >>
> >> 4.1's *feature freeze* was not extended (with the exception of
> >> Javelin merging in at the very end). What delayed us were quality
> issues...
> >> and frankly the "stabilization" period isn't something that I
> >> personally consider to be the critical date to hit. It's going to
> >> vary, based on what we find during testing. To me, the time-based
> >> approach is focused on the feature merge window primarily, and (over
> >> time) getting some consistency in our actual release dates. I think
> >> we are still learning to work with a feature freeze... we can get
> >> better at the tail end after we get better at bringing in only *known
> >> good* features into master.
> >
> > Indeed.
> > Extending the feature freeze window only - means shortening the QA
> > window - which in practice either won't work, or denies reality. As we
> > get more robust automated QA we should be able to move the freeze date
> > later, and merge with greater confidence, but I don't see it at this
> > point.
> >
> > --David
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by John Burwell <jb...@basho.com>.
David and Chip,
To be clear about my proposal, I did not intend to propose that we push back the feature freeze by x days of time and subtract x days from testing. My intention is to add those days into the cycle without reducing the test window -- pushing the release date out x days.
Another perspective is that we are acknowledging the likelihood that 4.1.0 delay will cascade into the 4.2.0 cycle. Rather than hoping we can absorb the impact, we embrace it early to reduce the time pressure on the community, reset expectations with our users, and increase the probability of high quality release.
Thanks,
-John
On May 30, 2013, at 9:39 AM, David Nalley <da...@gnsa.us> wrote:
> On Thu, May 30, 2013 at 9:13 AM, Chip Childers
> <ch...@sungard.com> wrote:
>> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: David Nalley [mailto:david@gnsa.us]
>>>> Sent: Thursday, May 30, 2013 12:36 PM
>>>> To: dev@cloudstack.apache.org
>>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>>>
>>>> On Thu, May 30, 2013 at 3:02 AM, murali reddy
>>>> <mu...@gmail.com> wrote:
>>>>> We should do a health-check of proposed features [1] which are at risk
>>>>> for
>>>>> 4.2 feature freeze before deciding to re-evaluate timelines.
>>>>>
>>>>
>>>> We are supposedly doing time-based release, so we don't care about what
>>>> features make it versus don't.
>>>
>>> 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>>>
>>
>> 4.1's *feature freeze* was not extended (with the exception of Javelin
>> merging in at the very end). What delayed us were quality issues...
>> and frankly the "stabilization" period isn't something that I personally
>> consider to be the critical date to hit. It's going to vary, based on
>> what we find during testing. To me, the time-based approach is focused
>> on the feature merge window primarily, and (over time) getting some
>> consistency in our actual release dates. I think we are still learning
>> to work with a feature freeze... we can get better at the tail end
>> after we get better at bringing in only *known good* features into
>> master.
>
> Indeed.
> Extending the feature freeze window only - means shortening the QA
> window - which in practice either won't work, or denies reality. As we
> get more robust automated QA we should be able to move the freeze date
> later, and merge with greater confidence, but I don't see it at this
> point.
>
> --David
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 30, 2013 at 9:13 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>>
>>
>> > -----Original Message-----
>> > From: David Nalley [mailto:david@gnsa.us]
>> > Sent: Thursday, May 30, 2013 12:36 PM
>> > To: dev@cloudstack.apache.org
>> > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>> >
>> > On Thu, May 30, 2013 at 3:02 AM, murali reddy
>> > <mu...@gmail.com> wrote:
>> > > We should do a health-check of proposed features [1] which are at risk
>> > > for
>> > > 4.2 feature freeze before deciding to re-evaluate timelines.
>> > >
>> >
>> > We are supposedly doing time-based release, so we don't care about what
>> > features make it versus don't.
>>
>> 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>>
>
> 4.1's *feature freeze* was not extended (with the exception of Javelin
> merging in at the very end). What delayed us were quality issues...
> and frankly the "stabilization" period isn't something that I personally
> consider to be the critical date to hit. It's going to vary, based on
> what we find during testing. To me, the time-based approach is focused
> on the feature merge window primarily, and (over time) getting some
> consistency in our actual release dates. I think we are still learning
> to work with a feature freeze... we can get better at the tail end
> after we get better at bringing in only *known good* features into
> master.
Indeed.
Extending the feature freeze window only - means shortening the QA
window - which in practice either won't work, or denies reality. As we
get more robust automated QA we should be able to move the freeze date
later, and merge with greater confidence, but I don't see it at this
point.
--David
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by John Burwell <jb...@basho.com>.
Marcus,
I think it best to defer the larger release cycle length question to another time and place. As Chip stated earlier, the consensus is to maintain the current freeze date. Given the time sensitivity, my proposal can be considered resolved.
Thanks,
-John
On May 30, 2013, at 11:34 AM, Marcus Sorensen <sh...@gmail.com> wrote:
> I think there does need to be some course correction, but perhaps we
> should look at the development cycle overall and the lessons learned
> from 4.1. Did we not allocate enough time for bugfixing? Did we allow
> too many low-quality merges for the time allotted? Did we have issues
> with the overlap (allowing new features into master while bugfixing/QA
> needed to be focused on)? Or something else? Or maybe all of it?
>
> One thing that may help is to have some sort of feature review during
> the development cycle. Maybe at the halfway point we make a list if
> what will be in this release, with the intent of weeding out last
> minute bombs being dropped just before feature freeze. If a relatively
> large change isn't feature complete and its devs don't have it testing
> 3-4 weeks before feature freeze, then it gets moved to the next
> release. Sort of a sliding window for feature freeze, based on
> complexity. I know we've sort of said 'big changes can only land at
> the beginning of a cycle' once or twice, but I think making it
> official via some sort of review that pins features into releases
> would be helpful in solidifying that (as well as developer
> expectations).
>
> Or maybe we extend the time between feature freeze and code freeze,
> knowing that features are inevitably going to be rushed in at the last
> minute.
>
> I'm not sure what the correct answer is, but if we're going to talk
> about adjusting the 4.2 release, I thought it might be wise to
> consider fine-tuning the development cycle in general.
>
> On Thu, May 30, 2013 at 8:56 AM, Chip Childers
> <ch...@sungard.com> wrote:
>> On Thu, May 30, 2013 at 01:52:28PM +0000, Sudha Ponnaganti wrote:
>>> 4.2 already has lot of features ( Around 70+ features ) added and require hardening once feature freeze happens. This release is bigger than any other release. Even though 1 round of testing is being done for majority of the features, there are quite a few that require community help to build quality. By adding more features, it would be that much difficult to harden the release.
>>>
>>> -----Original Message-----
>>> From: Chip Childers [mailto:chip.childers@sungard.com]
>>> Sent: Thursday, May 30, 2013 6:13 AM
>>> To: dev@cloudstack.apache.org
>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>>
>>> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>>>>
>>>>
>>>>> -----Original Message-----
>>>>> From: David Nalley [mailto:david@gnsa.us]
>>>>> Sent: Thursday, May 30, 2013 12:36 PM
>>>>> To: dev@cloudstack.apache.org
>>>>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>>>>
>>>>> On Thu, May 30, 2013 at 3:02 AM, murali reddy
>>>>> <mu...@gmail.com> wrote:
>>>>>> We should do a health-check of proposed features [1] which are at
>>>>>> risk for
>>>>>> 4.2 feature freeze before deciding to re-evaluate timelines.
>>>>>>
>>>>>
>>>>> We are supposedly doing time-based release, so we don't care about
>>>>> what features make it versus don't.
>>>>
>>>> 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>>>>
>>>
>>> 4.1's *feature freeze* was not extended (with the exception of Javelin merging in at the very end). What delayed us were quality issues...
>>> and frankly the "stabilization" period isn't something that I personally consider to be the critical date to hit. It's going to vary, based on what we find during testing. To me, the time-based approach is focused on the feature merge window primarily, and (over time) getting some consistency in our actual release dates. I think we are still learning to work with a feature freeze... we can get better at the tail end after we get better at bringing in only *known good* features into master.
>>>
>>
>> I have to say that I'm actually surprised at the number of developers
>> that want to hold to the schedule... and I'm happy if we stick to our
>> guns. I'm also OK with extending a bit (if that had been the
>> consensus).
>>
>> Sounds like we are mostly agreeing that we should stick to the existing
>> schedule for feature freeze?
>>
>> -chip
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Marcus Sorensen <sh...@gmail.com>.
I think there does need to be some course correction, but perhaps we
should look at the development cycle overall and the lessons learned
from 4.1. Did we not allocate enough time for bugfixing? Did we allow
too many low-quality merges for the time allotted? Did we have issues
with the overlap (allowing new features into master while bugfixing/QA
needed to be focused on)? Or something else? Or maybe all of it?
One thing that may help is to have some sort of feature review during
the development cycle. Maybe at the halfway point we make a list if
what will be in this release, with the intent of weeding out last
minute bombs being dropped just before feature freeze. If a relatively
large change isn't feature complete and its devs don't have it testing
3-4 weeks before feature freeze, then it gets moved to the next
release. Sort of a sliding window for feature freeze, based on
complexity. I know we've sort of said 'big changes can only land at
the beginning of a cycle' once or twice, but I think making it
official via some sort of review that pins features into releases
would be helpful in solidifying that (as well as developer
expectations).
Or maybe we extend the time between feature freeze and code freeze,
knowing that features are inevitably going to be rushed in at the last
minute.
I'm not sure what the correct answer is, but if we're going to talk
about adjusting the 4.2 release, I thought it might be wise to
consider fine-tuning the development cycle in general.
On Thu, May 30, 2013 at 8:56 AM, Chip Childers
<ch...@sungard.com> wrote:
> On Thu, May 30, 2013 at 01:52:28PM +0000, Sudha Ponnaganti wrote:
>> 4.2 already has lot of features ( Around 70+ features ) added and require hardening once feature freeze happens. This release is bigger than any other release. Even though 1 round of testing is being done for majority of the features, there are quite a few that require community help to build quality. By adding more features, it would be that much difficult to harden the release.
>>
>> -----Original Message-----
>> From: Chip Childers [mailto:chip.childers@sungard.com]
>> Sent: Thursday, May 30, 2013 6:13 AM
>> To: dev@cloudstack.apache.org
>> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>>
>> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>> >
>> >
>> > > -----Original Message-----
>> > > From: David Nalley [mailto:david@gnsa.us]
>> > > Sent: Thursday, May 30, 2013 12:36 PM
>> > > To: dev@cloudstack.apache.org
>> > > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>> > >
>> > > On Thu, May 30, 2013 at 3:02 AM, murali reddy
>> > > <mu...@gmail.com> wrote:
>> > > > We should do a health-check of proposed features [1] which are at
>> > > > risk for
>> > > > 4.2 feature freeze before deciding to re-evaluate timelines.
>> > > >
>> > >
>> > > We are supposedly doing time-based release, so we don't care about
>> > > what features make it versus don't.
>> >
>> > 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>> >
>>
>> 4.1's *feature freeze* was not extended (with the exception of Javelin merging in at the very end). What delayed us were quality issues...
>> and frankly the "stabilization" period isn't something that I personally consider to be the critical date to hit. It's going to vary, based on what we find during testing. To me, the time-based approach is focused on the feature merge window primarily, and (over time) getting some consistency in our actual release dates. I think we are still learning to work with a feature freeze... we can get better at the tail end after we get better at bringing in only *known good* features into master.
>>
>
> I have to say that I'm actually surprised at the number of developers
> that want to hold to the schedule... and I'm happy if we stick to our
> guns. I'm also OK with extending a bit (if that had been the
> consensus).
>
> Sounds like we are mostly agreeing that we should stick to the existing
> schedule for feature freeze?
>
> -chip
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
On Thu, May 30, 2013 at 01:52:28PM +0000, Sudha Ponnaganti wrote:
> 4.2 already has lot of features ( Around 70+ features ) added and require hardening once feature freeze happens. This release is bigger than any other release. Even though 1 round of testing is being done for majority of the features, there are quite a few that require community help to build quality. By adding more features, it would be that much difficult to harden the release.
>
> -----Original Message-----
> From: Chip Childers [mailto:chip.childers@sungard.com]
> Sent: Thursday, May 30, 2013 6:13 AM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>
> On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
> >
> >
> > > -----Original Message-----
> > > From: David Nalley [mailto:david@gnsa.us]
> > > Sent: Thursday, May 30, 2013 12:36 PM
> > > To: dev@cloudstack.apache.org
> > > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
> > >
> > > On Thu, May 30, 2013 at 3:02 AM, murali reddy
> > > <mu...@gmail.com> wrote:
> > > > We should do a health-check of proposed features [1] which are at
> > > > risk for
> > > > 4.2 feature freeze before deciding to re-evaluate timelines.
> > > >
> > >
> > > We are supposedly doing time-based release, so we don't care about
> > > what features make it versus don't.
> >
> > 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
> >
>
> 4.1's *feature freeze* was not extended (with the exception of Javelin merging in at the very end). What delayed us were quality issues...
> and frankly the "stabilization" period isn't something that I personally consider to be the critical date to hit. It's going to vary, based on what we find during testing. To me, the time-based approach is focused on the feature merge window primarily, and (over time) getting some consistency in our actual release dates. I think we are still learning to work with a feature freeze... we can get better at the tail end after we get better at bringing in only *known good* features into master.
>
I have to say that I'm actually surprised at the number of developers
that want to hold to the schedule... and I'm happy if we stick to our
guns. I'm also OK with extending a bit (if that had been the
consensus).
Sounds like we are mostly agreeing that we should stick to the existing
schedule for feature freeze?
-chip
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Sudha Ponnaganti <su...@citrix.com>.
4.2 already has lot of features ( Around 70+ features ) added and require hardening once feature freeze happens. This release is bigger than any other release. Even though 1 round of testing is being done for majority of the features, there are quite a few that require community help to build quality. By adding more features, it would be that much difficult to harden the release.
-----Original Message-----
From: Chip Childers [mailto:chip.childers@sungard.com]
Sent: Thursday, May 30, 2013 6:13 AM
To: dev@cloudstack.apache.org
Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Thursday, May 30, 2013 12:36 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
> >
> > On Thu, May 30, 2013 at 3:02 AM, murali reddy
> > <mu...@gmail.com> wrote:
> > > We should do a health-check of proposed features [1] which are at
> > > risk for
> > > 4.2 feature freeze before deciding to re-evaluate timelines.
> > >
> >
> > We are supposedly doing time-based release, so we don't care about
> > what features make it versus don't.
>
> 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>
4.1's *feature freeze* was not extended (with the exception of Javelin merging in at the very end). What delayed us were quality issues...
and frankly the "stabilization" period isn't something that I personally consider to be the critical date to hit. It's going to vary, based on what we find during testing. To me, the time-based approach is focused on the feature merge window primarily, and (over time) getting some consistency in our actual release dates. I think we are still learning to work with a feature freeze... we can get better at the tail end after we get better at bringing in only *known good* features into master.
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
On Thu, May 30, 2013 at 11:02:32AM +0000, Koushik Das wrote:
>
>
> > -----Original Message-----
> > From: David Nalley [mailto:david@gnsa.us]
> > Sent: Thursday, May 30, 2013 12:36 PM
> > To: dev@cloudstack.apache.org
> > Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
> >
> > On Thu, May 30, 2013 at 3:02 AM, murali reddy
> > <mu...@gmail.com> wrote:
> > > We should do a health-check of proposed features [1] which are at risk
> > > for
> > > 4.2 feature freeze before deciding to re-evaluate timelines.
> > >
> >
> > We are supposedly doing time-based release, so we don't care about what
> > features make it versus don't.
>
> 4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>
4.1's *feature freeze* was not extended (with the exception of Javelin
merging in at the very end). What delayed us were quality issues...
and frankly the "stabilization" period isn't something that I personally
consider to be the critical date to hit. It's going to vary, based on
what we find during testing. To me, the time-based approach is focused
on the feature merge window primarily, and (over time) getting some
consistency in our actual release dates. I think we are still learning
to work with a feature freeze... we can get better at the tail end
after we get better at bringing in only *known good* features into
master.
RE: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Koushik Das <ko...@citrix.com>.
> -----Original Message-----
> From: David Nalley [mailto:david@gnsa.us]
> Sent: Thursday, May 30, 2013 12:36 PM
> To: dev@cloudstack.apache.org
> Subject: Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
>
> On Thu, May 30, 2013 at 3:02 AM, murali reddy
> <mu...@gmail.com> wrote:
> > We should do a health-check of proposed features [1] which are at risk
> > for
> > 4.2 feature freeze before deciding to re-evaluate timelines.
> >
>
> We are supposedly doing time-based release, so we don't care about what
> features make it versus don't.
4.1 was also supposed to be a time based one but got delayed due to various issues. So not sure what would be the right approach here. I think it makes sense to look at the feature list to see if some of them (individual features can be voted upon) can be accommodated in 4.2. If there are no such features then there is no need for extending the cutoff date.
>
> --David
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by David Nalley <da...@gnsa.us>.
On Thu, May 30, 2013 at 3:02 AM, murali reddy <mu...@gmail.com> wrote:
> We should do a health-check of proposed features [1] which are at risk for
> 4.2 feature freeze before deciding to re-evaluate timelines.
>
We are supposedly doing time-based release, so we don't care about
what features make it versus don't.
--David
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by murali reddy <mu...@gmail.com>.
We should do a health-check of proposed features [1] which are at risk for
4.2 feature freeze before deciding to re-evaluate timelines.
[1]
https://cwiki.apache.org/confluence/display/CLOUDSTACK/4.2+Design+Documents
On Thu, May 30, 2013 at 10:04 AM, Chip Childers
<ch...@sungard.com>wrote:
> On May 29, 2013, at 7:59 PM, John Burwell <jb...@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?
>
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by Chip Childers <ch...@sungard.com>.
On May 29, 2013, at 7:59 PM, John Burwell <jb...@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?
Re: [PROPOSAL] Pushback 4.2.0 Feature Freeze
Posted by David Nalley <da...@gnsa.us>.
On Wed, May 29, 2013 at 7:59 PM, John Burwell <jb...@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
Perhaps it's implied, but this really means pushing the entire
schedule 8 weeks, not just feature freeze?
I hope that it doesn't turn into a race to add yet more features that
were being planned for injection into 4.3
--David