I did see those tests, but they were this round, and they don't cover any of the things I mentioned. On Sep 9, 2013 12:31 PM, "Animesh Chaturvedi" <animesh.chaturv...@citrix.com> wrote:
> > > > -----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. > > > > > > > > > > >
