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. > >
