accumulo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sean Busbey <>
Subject Re: moving rat to a profile?
Date Tue, 17 Jun 2014 20:34:50 GMT
On Tue, Jun 17, 2014 at 4:19 PM, Billie Rinaldi <>

> On Tue, Jun 17, 2014 at 12:19 PM, Sean Busbey <> wrote:
> > My concern with a default-on profile is the same one I have with
> > Christopher's suggestion that we recommend -Drat.ignoreErrors=true.
> >
> > It's going to make the "easy" path one where things aren't checked.
> That's
> > going to necessitate we check things periodically and during release.
> >
> I don't understand how leaving the rat check on by default makes disabling
> it the easy path.  I think it makes the check happen more often than not.
> Even if we decide to suggest that new contributors just disable the check,
> we should still be educating potential committers (and existing committers,
> since this is a relatively new issue) about why the check sometimes fails
> when you switch branches and how to fix it.
Right now, there is a lot of noise coming from the rat plugin. In my
experience, developers tend to optimize their work path. Things that add to
build time tend to get de-prioritized, especially if they don't provide
feedback on something the developer currently cares about.

For example, when I am attempting to add a new IT or am attempting to fix
one that currently shows failure, I tend to disable unit tests and
findbugs. As far as I'm concerned this is normal and expected behavior.

However, it is not unreasonable to presume that people similarly downgrade
swaths of checks in their normal development. I doubt most of us run
"verify" and the accompanying ITs for our normal dev cycle. I try to use
-Psunny verify, but that easily increases build time several times over so
it doesn't happen as often as I'd like.

People are similarly going to change their normal build process to remove
the rat plugin (either by disabling the profile or by always telling it to
ignore errors), because it isn't what they're currently focused on. It's
"easy" because it is less likely to interrupt their workflow.

The people most likely to have that check run are those least capable of
correctly handling its output: people new to the codebase who don't yet
know the particulars of our build choices and how to tweak them.

We rely on jenkins to alert us when someone makes a change that blows out
an IT. What's the downside to doing the same for rat checks? The people who
aren't going to opt into turning on the profile by default are the same who
will manually turn it off for their local builds.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message