> -----Original Message----- > From: Marcus Sorensen [mailto:shadow...@gmail.com] > Sent: Monday, September 09, 2013 11:10 AM > To: dev@cloudstack.apache.org > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round) > > We just need to have basic automated testing of every core supported > platform. With 4.1 we released a product that didn't even work on > Ubuntu KVM, nobody tested it. As long as we rely on devs to > individually test things at their leisure, we will always end up with 3- > 4 round release votes. An RC should pass a test suite first, and that > test suite should do a basic test for every item we claim support for, > BEFORE it goes up for a vote. [Animesh>] It did may be you missed the test results from Prasanna for this VOTE.
> On Sep 9, 2013 12:02 PM, "Chiradeep Vittal" > <chiradeep.vit...@citrix.com> > wrote: > > > Agree with Animesh. > > From a somewhat selfish perspective, I've gone through 2 rounds of > > testing, not relishing the 3rd round. > > There are literally hundreds of features in CloudStack. Another delay > > could bring one more bug (existing perhaps, or newly introduced). > > And another round of testing. > > > > Draw the line somewhere. > > -- > > Chiradeep > > > > > > On 9/9/13 10:51 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. > > > > > > >
