good point Mike, I would like to add that in our case 'quality' means 'usability'. We are not writing military or madical grade code. However I don't want to tell a big far eastern telco that their it is out because i left an == in the code that was meant to be an equals() call, or a leak because a set of lists of storage pools is removed from a list of longs, resulting in no action and their ids therefor stay in the list of poolsToAvoid.
Note that other types of examples exist. In short if we don't like the risk we do need to consider those fixes one by one. And even then we are closing our eyes for what we now know because of findbugs. I only resolved the scariest and only in the server package (and Ian did one in ldap) anyways, I am testing and have found other issues. I am not ready to say -1 yet but who knows. life is a mystery On Wed, Jan 29, 2014 at 8:14 PM, Mike Tutkowski <mike.tutkow...@solidfire.com> wrote: > 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)*
