nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Billie Rinaldi <>
Subject Re: RAT exclusions for test resources
Date Mon, 16 Mar 2015 15:10:37 GMT
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.

On Sat, Mar 14, 2015 at 8:52 PM, Joe Witt <> wrote:

> Hello
> I've resolved all of the items raised in feedback for the 0.0.2
> release excluding one item which will be discussed in a moment.  All
> of the feedback and their disposition is captured in this JIRA
> The only outstanding item is this feedback:
> "One thing I'd fix for the next release is the exclusion of test
> resources from the RAT check. Wouldn't it be better to do that by file
> extension (e.g., */.json, */.avro) to avoid not checking files that
> could have license headers?"
> I would like to leave it as we have it now.  People should take care
> to apply the apache license header to everything including test data
> whenever possible.  But we must also be considerate of the fact that
> test data is just that - test data.  It is important that data under
> test mirrors exactly the data it is to be run against and certainly
> data we'd be processing in the wild will not often have license
> headers.  Given this I don't see how we can keep the RAT exclusion
> list from turning into a mess.  I prefer to trust that the developers
> are doing the right thing on test resources and keep the build simple.
> For non test resources though we retain a very specific and strict
> check.
> I'll close the ticket tracking the items raised for now but should
> folks have a strong view here then certainly we can address it.
> Thanks
> Joe

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