hear hear, but this can not be managed if not automated. not in 4 months or, with a product like ACS not on a halve year basis. Weren't you advocating a release dedicated to automated testing in another thread, Marcus?
Daan On Mon, Sep 9, 2013 at 8:10 PM, Marcus Sorensen <shadow...@gmail.com> wrote: > 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. > 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. >> > >> >>
