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" <jburw...@basho.com> wrote:
Chiradeep,
As I understood that conversation, it was about permanently changing
the length of release cycles. I am proposing that we acknowledge the
impact of the longer than anticipated 4.1.0 release, and push out
4.2.0. 4.3.0 would still be a four month release cycle, it would just
start X weeks later.
I like Chip's compromise of 4 weeks. I think it would be a great
benefit to the 4.2.0 release if the community had the opportunity to
completely focus on its development for some period of time.
Finally, to David's concern that other features might be added during
such an extension. I think that would be acceptable provided they
pass review. The goal of my proposal is not permit more features but
to give the community time to review and collaborate on changes coming
into the release. If additional high quality feature implementations
happen to get merged in during that period then I consider that a
happy side effect.
Thanks,
-John
On May 30, 2013, at 1:51 AM, Chiradeep Vittal
<chiradeep.vit...@citrix.com> wrote:
This topic was already discussed here:
http://www.mail-archive.com/dev@cloudstack.apache.org/msg03235.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" <mike.tutkow...@solidfire.com>
wrote:
+1 Four weeks extra would be ideal in this situation.
On Wed, May 29, 2013 at 10:48 PM, Sebastien Goasguen
<run...@gmail.com>wrote:
On 30 May 2013, at 06:34, Chip Childers <chip.child...@sungard.com>
wrote:
On May 29, 2013, at 7:59 PM, John Burwell <jburw...@basho.com> wrote:
All,
Since we have taken an eight (8) week delay completing the 4.1.0
release, I would like propose that we re-evaluate the timelines for
the
4.2.0 release. When the schedule was originally conceived, it was
intended
that the project would have eight (8) weeks to focus exclusively on
4.2.0
development. Unfortunately, this delay has created an unfortunate
conflict
between squashing 4.1.0 bugs and completing 4.2.0 features. I propose
that
we acknowledge this schedule impact, and push back the 4.2.0 feature
freeze
date by eight (8) weeks to 2 August 2013. This delay will give the
project
time to properly review merges and address issues holistically, and,
hopefully, relieve a good bit of the stress incurred by the
simultaneous
4.1.0 and 4.2.0 activities.
Thanks,
-John
This is a reasonable idea IMO. I'd probably only extend by a month
personally, but your logic is sound. I'd much rather have reasoned
discussions about code than argue procedural issues about timing any
day. This might help facilitate that on some of the features folks
are
scrambling to complete.
Others?
I am +1 on this, 4 weeks maybe ?
--
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkow...@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
**
