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.

Reply via email to