cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <>
Subject Re: Findbugs report on 4.3-forward
Date Wed, 29 Jan 2014 20:08:09 GMT
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
<> 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 <>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:
> o: 303.746.7302
> Advancing the way the world uses the
> cloud<>
> *(tm)*

View raw message