+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> *™*