cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: [DISCUSS] new findbugs bug findings
Date Fri, 05 Jun 2015 07:12:40 GMT
On Fri, Jun 5, 2015 at 8:42 AM, Rajani Karuturi <rajani@apache.org> wrote:
> Hi Daan,
> of the 51 issues, I dont think all of them are new. I checked a few and
> they are very old.

Some how we never get to a point where we keep up with findbugs this
way. The result is we don't use it (enough).

>
> I think it will be useful to run findbugs analysis on every pull request
> and inform any findings in the new code. Its within the contest and easy to
> get fixed than looking at them at a later point of time.

I agree but is this easy to implement? I am looking for the next step
in our reach not for an end goal. How can we get to a continuous
custom of checking these litle items and weeding out the old ones
along the way?

> On Thu, Jun 4, 2015 at 5:24 PM, Daan Hoogland <daan.hoogland@gmail.com>
> wrote:
>
>> LS,
>>
>> We have been improving a lot in terms checking submissions and having
>> better (as in less) overall mastaer breakage lately. We are not there
>> yet.
>>
>> At the moment findbugs has 51 new findings and fails the slowbuild for
>> that reason. I think a lot of those can be prevented. For the rest we
>> can attribute them to people/commits. Call it blaming but I know I am
>> guilty at times and some far better developers then me, as well.
>>
>> We are not running the slow build on every commit (it is called slow
>> for a reason) and a lot of people are ignoring the output from it
>> because it almost always fails. I fixed it in Austin and it now has 51
>> new findings (when I last looked).
>>
>> 1. One way to handle this is to publish the attribution on this list.
>> 2. Another way is to have a pull request builder do the slow build on
>> every commit
>> 3. The old proposal was to do the slow build at regular intervals and
>> revert everything in a failed build. I was one of the people rejecting
>> it but I put it here to be as complete as possible.
>>
>> 1 is very intensive work but very easily implemented
>> 2 is not much implementation work but requires even more discipline of
>> committers in their review work.
>>
>> I feel for both equally strong either way but I think we should make
>> the next step soon.
>>
>> thoughts?
>>
>> --
>> Daan
>>



-- 
Daan

Mime
View raw message