> -----Original Message----- > From: Daan Hoogland [mailto:daan.hoogl...@gmail.com] > Sent: Monday, September 09, 2013 11:50 AM > To: dev > Subject: Re: [VOTE] Apache CloudStack 4.2.0 (fourth round) > > Animesh, > > Without wanting to pass judgement on the quality of those tests or the > accuracy with which they were performed, there is now a mismatch between > what passed those tests and what people expect to work in the current > release. I assume that the tests where performed at an acceptable level > of expertise and I expect they were programmed at such a level. This > would leave only the coverage as a cause of our present problem. > > To get back to the subject of the thread; If the bugs are in new > features that is completely acceptable to me. If the bug are newly > discovered in old features as well. If however new bugs are introduced > to old features that people are using anywhere, this cuts them of from > upgrading with the rest of us. I would say no men gets left behind. If > need be new features need to be cut out but better is fix everything > that is introduced in this release. > > €0,02 > Daan [Animesh>]Daan I would also prefer to fix as many issues as possible but suggesting a pragmatic approach where we also consider maintenance release. I have no problem cutting another RC, but the feedback is slowly trickling in. The issues in discussion also appeared in 4th VOTE not during the prior VOTEs.
> > On Mon, Sep 9, 2013 at 8: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. > >> > > > >> > > >> >
