ok i think this is now case closed. Actions taken 1) Pushed all module specific RAT exclusions down to the specific relevant modules 2) Removed the broad RAT exclusion for test resources 3) Added specific RAT exclusions per test file for which it was appropriate based on the test resource in question. 4) Validated full clean build is good to go and that the full RAT verification works 5) Fixed 3 module directory names which did not match their artifact names (nifi-cluster --> nifi-framework-cluster...)
We should now be taking full advantage of RAT and only excluding specifically approved items. Ryan: Thanks for being persistent. You were right. Thanks Joe On Mon, Mar 16, 2015 at 5:03 PM, Joe Witt <[email protected]> wrote: > Ryan, > > To be honest I think you're probably right. I was being lazy. But in > reality my laziness would cause an addition step in an already many > step release process. So that isn't cool. And further my lazy > approach could cause us to miss something. Your approach requires > more up front cost in the cases where test data does need to bypass > the header but then we're done. So, in short, i think you're right. > > Unless there is any objection i'll go through the current exclusions > and give this a shot. > > Thanks > Joe > > On Mon, Mar 16, 2015 at 4:57 PM, Ryan Blue <[email protected]> wrote: >> On 03/16/2015 08:13 AM, Joe Witt wrote: >>> >>> Billie, >>> >>> Ok understood. I'll update the release guide to indicate this guidance. >>> >>> Thanks! >>> Joe >>> >>> On Mon, Mar 16, 2015 at 11:10 AM, Billie Rinaldi <[email protected]> >>> wrote: >>>> >>>> I think it is okay to leave the rat exclusion as is. However, it is >>>> important that you verify what has been committed as test resources, >>>> along >>>> with anything else excluded from the rat check, before release. I'm sure >>>> that no one will deliberately check in something they know shouldn't be >>>> there, but people have a tendency to commit things to work around >>>> policies >>>> they don't fully understand -- and understanding ASF policies is not a >>>> trivial undertaking. This has happened on every project I've worked on. >> >> >> I think it would be easier to maintain by adding the individual exclusions. >> I don't see a big drawback to having a big longer RAT configuration, and I'd >> prefer that to a release task that says to check all of the >> src/test/resources files added to do the license check by hand. A commit >> with an addition to the RAT rules only needs to be added once, and a RAT >> check for other files ensures the source tree is always up to date. >> >> It's up to you guys in the end, but I don't understand how the general >> exclusion makes things easier. >> >> rb >> >> >> -- >> Ryan Blue >> Software Engineer >> Cloudera, Inc.
