The jenkins pull request job currently only builds the code (AFAIK) Can we also add enablefindbugs profile to it and see how quickly it analyses?
~Rajani On Fri, Jun 5, 2015 at 12:42 PM, Daan Hoogland <daan.hoogl...@gmail.com> wrote: > On Fri, Jun 5, 2015 at 8:42 AM, Rajani Karuturi <raj...@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.hoogl...@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 >
