On Tue, Jun 17, 2014 at 4:34 PM, Sean Busbey <[email protected]> wrote:
> On Tue, Jun 17, 2014 at 4:19 PM, Billie Rinaldi <[email protected]> > wrote: > > > On Tue, Jun 17, 2014 at 12:19 PM, Sean Busbey <[email protected]> > 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. > Having jenkins alert on rat failure seems like a good way to go. As long as jenkins is not constantly crying wolf when there is not a problem, so that people ignore it. > > > -- > Sean >
