I would agree, being someone who is interested in deploying CloudStack and has been following the dev list for a while now to see what the status is, I wouldn't touch this release with a 10 foot pole. Especially after the last few build failures I've had. I understand the need to draw the line but whats the point of a release thats riddled with fun landmines for the user to step on?
On Mon, Sep 9, 2013 at 2:02 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > Its the consequence of our anemic testing capability compared to the > feature set. I don't think we can accept regressions in general at all for > storage types, hypervisor types, network, etc unless it is due to an > abandoned feature, otherwise it will be impossible for people to navigate a > swiss cheese feature set. We will need a matrix showing each release and > what's broken/working, maybe a helper app that will tell people which > versions are safe. > On Sep 9, 2013 11:52 AM, "Animesh Chaturvedi" < > animesh.chaturv...@citrix.com> > wrote: > > > > > > > > -----Original Message----- > > > From: Chip Childers [mailto:chip.child...@sungard.com] > > > Sent: Monday, September 09, 2013 8:25 AM > > > To: dev@cloudstack.apache.org > > > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round) > > > > > > On Mon, Sep 09, 2013 at 10:42:48AM -0400, Simon Weller wrote: > > > > -1 from me as well. > > > > > > > > > > > > I know we're trying to hit timed releases, but I think it's very > > > important to preserve key underlying functionality across releases. If > a > > > supported and documented feature is known to be broken, we need to > > > address it...if we don't, it's going to cause lots of pain, and reflect > > > badly on ACS as a project. > > > > > > > > > > Agreed. The idea of "time-based" is all about feature development. > > > Quality shouldn't be sacrificed. > > > > [Animesh>] But we have to draw the line at some point otherwise we cannot > > maintain a 4 month cadence. 4.3 code freeze is in just 6-7 weeks and this > > is our 4th VOTE round for 4.2. IMHO if something is in core orchestration > > layer, failed upgrade, cannot install and the likes and affects most > users > > it should block a release. Other remaining issues should be picked up for > > subsequent maintenance release. May be we should discuss when should be > the > > next maintenance release on 4.2, 4 weeks or 6 weeks rather than delaying > > 4.2. > > > > > -- Thank you, Matthew Fusaro Zentific LLC Developer & Network Engineer
