On Mon, Oct 19, 2015 at 11:24 AM, Allen Wittenauer <a...@altiscale.com> wrote:
> > On Oct 19, 2015, at 11:09 AM, Andrew Wang <andrew.w...@cloudera.com> > wrote: > > > Could we make it so we run RAT after building docs but before running > > tests? I think that's what's causing these issues, it looks like temp > > output from running tests. This would be a nice intermediate step toward > > that plug-in you mentioned, since test output is certainly not part of > the > > release tarball. > > There’s no real guarantee of the order a dev or worse the RE might > run the build in, however. The current order tests the worst possible > case, and as a result discovered these bugs in the build that have been > there for a very long time. So moving the test to hide bad results sound > counterproductive to me. (It also might point to potential issues with > parallel tests, but that’s very case-by-case dependent of course.) > > Besides, with JDK8 now being tested against, these are likely the > easier problems to fix given how broken javadoc is… ;) > > I do agree we should fix these usages of build/test/data, but I don't follow the logic regarding running RAT after tests. The point of the precommit RAT check is to avoid introducing things to the source tarball that fail RAT, and test output is not part of the source tarball. It's not intended to detect issues if an RM incorrectly builds a release, the RM and PMC always need to run RAT again when voting on a release. We don't run precommit on releases, so this "RAT after tests" check wouldn't help detect bad release tarballs. Point being, RAT is not supposed to be used to catch naughty tests that operate outside target/, so let's not use it as such. These RAT errors, although they helped us find some test issues, are unrelated to the release process and thus spurious.
