On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <[EMAIL PROTECTED]> wrote:

My understanding from that prior conversation is that, with the way we
use JIRA to mark things as fixed in the latest major release and
enumerating the fix versions to denote all the bugfix releases in
which it was fixed, meant that we can cover the entire CHANGE history
(after a certain point) by including only the major releases, and the
bugfixes since the last major one. Therefore, since this is a major
release, I included the 1.4.0 and 1.5.0 changes also. Anything fixed
in 1.5.1 would also be marked as fixed for 1.6.0 (if it still
applied), so the 1.6.0 changes include those and 1.5.1 is not needed
to list separately. This was not done for 1.5.0, because we hadn't
discussed it then.

It seems you came to a different understanding from that conversation.
If I understand you correctly, it would mean we should only include
1.6.0 changes? If that's the case, do you think a -1 is warranted for
including more than necessary (1.4.0 and 1.5.0)?
The rat check plugin typically ignores README/NOTICE/LICENSE files as
category "N" (for Notices). That's why it ignored the
japi-compliance/README and conf/examples/crypto/readme.txt. I think
it's expected that the LICENSE file covers them. At the very least, I
don't think they contain anything copyrightable that would necessitate
a license. But, for consistency, maybe we should add it anyway? I'm
not sure that consistency argument warrants blockage (for me), though.

The rest were ignored because the rat check does not check binary
files. These files should be covered by the LICENSE/NOTICE files.
Binary document files may or may not be capable of supporting license
metadata, in general, but I think the coverage by the LICENSE/NOTICE
files is sufficient. However, we can do additional things with these
files. The ScaleTest.odp could probably be converted to markdown, with
a license header. The state_diagrams are not used anywhere in the
LaTeX generation (leftover from old developer manual?), and could
probably be deleted or moved to the website or wiki, if they are
needed at all. I'm not sure which option is best. However, again, I'd
consider the LICENSE/NOTICE files sufficient, so as not to block,
especially since they didn't block any previous release (presumably
because LICENSE/NOTICE covered them), and they've been around awhile.

NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB