I agree that quality should be our primary focus. My one point of caution here would be, "How risky are these fixes?"
Just because we believe we have fixes for issues does not necessarily mean they should be put in a release late in the game. We have to weigh the benefits of having the fixes versus the risks of introducing them so late in the game. Now, I don't know what fixes we're referring to here (I haven't read through this entire e-mail chain), but I just wanted to throw that out there. Thanks! On Wed, Jan 29, 2014 at 12:04 PM, Chip Childers <chipchild...@apache.org>wrote: > On Tue, Jan 28, 2014 at 11:36:52PM +0100, Hugo Trippaers wrote: > > Hey Animesh, > > > > Not in agreement here. These are squashed bugs and we want as less bugs > in the release as possible. > > > > This is why we test any RC before we release it. I say include all the > big fixes we have in the release. If that means more testing before we cut > the RC then that is what it is. I can't rightfully vote for a release with > known issues with existing fixes. Quality over release schedule would be my > vote then. > > > > Cheers, > > Hugo > > +1 - to me, the schedule is really about constraining scope. Quality > should be primary. > -- *Mike Tutkowski* *Senior CloudStack Developer, SolidFire Inc.* e: mike.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *(tm)*
