You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Mike Drob <ma...@cloudera.com> on 2014/04/28 21:24:23 UTC
Re: [DISCUSS] Accumulo 1.6.0-RC4
Forking thread for discussion.
On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <ma...@cloudera.com> wrote:
> > -1
> >
> > The good:
> >
> > * Verified all signatures and checksums.
> > * Ran continuous ingest with binary artifact + custom built native maps.
> >
> >
> > The issues, but not enough to vote against:
> >
> > * Encountered ACCUMULO-2741.
> > * Encountered ACCUMULO-2742.
> > * Source artifact missing .gitignore
> > ** This has been discussed, and I'm voting for precedent here. We can
> agree
> > to disagree, and if this vote passes then a new precedent will have been
> > set.
> >
> >
> > The bad:
> >
> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
> > ** It seems like we agreed to only include changes from the current major
> > release line, but that is not 100% clear.
>
> 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)?
>
> Yes, my understanding was that only 1.6.0 changes would be present. Yes, I
believe that this warrants a -1.
> >
> > * Missing licence headers:
> > ** README
> > ** conf/examples/crypto/readme.txt
> > ** test/compat/japi-compliance/README
> > ** test/system/continuous/ScaleTest.odp
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >
> > **
> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >
> > **
> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >
> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>
> 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.
>
> http://www.apache.org/legal/src-headers.html#faq-exceptions
The README has plenty of intellectual creativity in its content, and is
therefore subject to copyright claims. It could be argued that the other
two README files are short enough to not have copyright-able content, but
it doesn't sound like that's the case you want to make.
There is also lengthy discussion on
https://issues.apache.org/jira/browse/LEGAL-114 but again, that is focused
on small, non-creative files. Our README does not fall into that category.
> 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.
>
I do not agree that "in general, coverage by LICENSE files is sufficient.
If that were the case, then we would not need to put headers on our source
files, on our markdown files, on our example configuration files, etc...
I also do not accept "they've been around for a while and nobody noticed
it" as a reason to continue to ignore them. Either they are a violation, or
they are not. This is not to say that we have been perfect in the past, but
instead we correct mistakes when they are brought to attention.
Re: [DISCUSS] Accumulo 1.6.0-RC4
Posted by Billie Rinaldi <bi...@gmail.com>.
On Mon, Apr 28, 2014 at 2:23 PM, Mike Drob <ma...@cloudera.com> wrote:
> On Mon, Apr 28, 2014 at 5:12 PM, Christopher <ct...@apache.org> wrote:
>
> > On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob <ma...@cloudera.com> wrote:
> > > Forking thread for discussion.
> > >
> > > On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ct...@apache.org>
> > wrote:
> > >
> > >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <ma...@cloudera.com>
> > wrote:
> > >> > -1
> > >> >
> > >> >
> > >> > * Missing licence headers:
> > >> > ** README
> > >> > ** conf/examples/crypto/readme.txt
> > >> > ** test/compat/japi-compliance/README
> > >> > ** test/system/continuous/ScaleTest.odp
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> > >> >
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> > >> >
> > >> > **
> > >> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> > >> >
> > >> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> > >>
> > >> 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.
> > >>
> > >> http://www.apache.org/legal/src-headers.html#faq-exceptions
> > >
> > > The README has plenty of intellectual creativity in its content, and is
> > > therefore subject to copyright claims. It could be argued that the
> other
> > > two README files are short enough to not have copyright-able content,
> but
> > > it doesn't sound like that's the case you want to make.
> > >
> > > There is also lengthy discussion on
> > > https://issues.apache.org/jira/browse/LEGAL-114 but again, that is
> > focused
> > > on small, non-creative files. Our README does not fall into that
> > category.
> > >
> >
> > Agreed. Sorry, I meant the two smaller files didn't have enough. I had
> > combined two paragraphs for succinctness and this distinction got
> > lost.
> >
> > We had previously ignored other README files, but then added licences to
> them in ACCUMULO-2534 when rat-plugin complained. I believe the assumption
> is that README files are generally minimal, but I do not want to speak for
> the developers in this case.
>
> I strongly believe that our README needs a licence header. I am under the
> impression that it never had one.
>
>
> > >
> > >> 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.
> > >>
> > >
> > > I do not agree that "in general, coverage by LICENSE files is
> sufficient.
> > > If that were the case, then we would not need to put headers on our
> > source
> > > files, on our markdown files, on our example configuration files,
> etc...
> > >
> > > I also do not accept "they've been around for a while and nobody
> noticed
> > > it" as a reason to continue to ignore them. Either they are a
> violation,
> > or
> > > they are not. This is not to say that we have been perfect in the past,
> > but
> > > instead we correct mistakes when they are brought to attention.
> >
> > No, the "in general" part I was referring to only was for binary
> > files, which cannot be labeled without altering the contents. That is
> > not the case here (if the document formats allow metadata), but a
> > general explanation of the assumptions that the RAT check makes. I
> > also agree precedent should not determine the correct course of
> > action. The comment about precedent was specifically made in the
> > context of the parenthetical presumption... if that presumption does
> > not hold, and they did not block for some other reason (oversight, for
> > example), that is a different statement entirely.
> >
>
> It makes sense for rat-plugin to ignore binary files because they could be
> encrypted or compressed or something else, and already have a license
> header (false positives) or are simply impossible to add a header to
> because they are machine generated.
>
> If these files have licence headers somewhere in them, then I will withdraw
> my concern over them. I felt that I performed due diligence by visually
> inspecting them, running them through "strings" program, and attempting to
> check for file metadata. I support removing them and somehow moving the
> contents to our website.
>
I think Mike's assessment that we should add license headers to our README
files is correct, even though these files are ignored by rat. I'd be in
favor of moving the odg/odp and corresponding pdf files to the web site,
where they can sit until we figure out how we'd like to incorporate their
information into our documentation. (Note that the policy at
https://www.apache.org/legal/src-headers.html states that it does not apply
to web site content.) Or we could just attach those files to a ticket
whose purpose is to find a home for the information.
Re: [DISCUSS] Accumulo 1.6.0-RC4
Posted by Mike Drob <ma...@cloudera.com>.
On Mon, Apr 28, 2014 at 5:12 PM, Christopher <ct...@apache.org> wrote:
> On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob <ma...@cloudera.com> wrote:
> > Forking thread for discussion.
> >
> > On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ct...@apache.org>
> wrote:
> >
> >> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <ma...@cloudera.com>
> wrote:
> >> > -1
> >> >
> >> >
> >> > * Missing licence headers:
> >> > ** README
> >> > ** conf/examples/crypto/readme.txt
> >> > ** test/compat/japi-compliance/README
> >> > ** test/system/continuous/ScaleTest.odp
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
> >> >
> >> > **
> >> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
> >> >
> >> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
> >>
> >> 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.
> >>
> >> http://www.apache.org/legal/src-headers.html#faq-exceptions
> >
> > The README has plenty of intellectual creativity in its content, and is
> > therefore subject to copyright claims. It could be argued that the other
> > two README files are short enough to not have copyright-able content, but
> > it doesn't sound like that's the case you want to make.
> >
> > There is also lengthy discussion on
> > https://issues.apache.org/jira/browse/LEGAL-114 but again, that is
> focused
> > on small, non-creative files. Our README does not fall into that
> category.
> >
>
> Agreed. Sorry, I meant the two smaller files didn't have enough. I had
> combined two paragraphs for succinctness and this distinction got
> lost.
>
> We had previously ignored other README files, but then added licences to
them in ACCUMULO-2534 when rat-plugin complained. I believe the assumption
is that README files are generally minimal, but I do not want to speak for
the developers in this case.
I strongly believe that our README needs a licence header. I am under the
impression that it never had one.
> >
> >> 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.
> >>
> >
> > I do not agree that "in general, coverage by LICENSE files is sufficient.
> > If that were the case, then we would not need to put headers on our
> source
> > files, on our markdown files, on our example configuration files, etc...
> >
> > I also do not accept "they've been around for a while and nobody noticed
> > it" as a reason to continue to ignore them. Either they are a violation,
> or
> > they are not. This is not to say that we have been perfect in the past,
> but
> > instead we correct mistakes when they are brought to attention.
>
> No, the "in general" part I was referring to only was for binary
> files, which cannot be labeled without altering the contents. That is
> not the case here (if the document formats allow metadata), but a
> general explanation of the assumptions that the RAT check makes. I
> also agree precedent should not determine the correct course of
> action. The comment about precedent was specifically made in the
> context of the parenthetical presumption... if that presumption does
> not hold, and they did not block for some other reason (oversight, for
> example), that is a different statement entirely.
>
It makes sense for rat-plugin to ignore binary files because they could be
encrypted or compressed or something else, and already have a license
header (false positives) or are simply impossible to add a header to
because they are machine generated.
If these files have licence headers somewhere in them, then I will withdraw
my concern over them. I felt that I performed due diligence by visually
inspecting them, running them through "strings" program, and attempting to
check for file metadata. I support removing them and somehow moving the
contents to our website.
Re: [DISCUSS] Accumulo 1.6.0-RC4
Posted by Christopher <ct...@apache.org>.
On Mon, Apr 28, 2014 at 3:24 PM, Mike Drob <ma...@cloudera.com> wrote:
> Forking thread for discussion.
>
> On Mon, Apr 28, 2014 at 2:51 PM, Christopher <ct...@apache.org> wrote:
>
>> On Mon, Apr 28, 2014 at 12:20 PM, Mike Drob <ma...@cloudera.com> wrote:
>> > -1
>> >
>> > The good:
>> >
>> > * Verified all signatures and checksums.
>> > * Ran continuous ingest with binary artifact + custom built native maps.
>> >
>> >
>> > The issues, but not enough to vote against:
>> >
>> > * Encountered ACCUMULO-2741.
>> > * Encountered ACCUMULO-2742.
>> > * Source artifact missing .gitignore
>> > ** This has been discussed, and I'm voting for precedent here. We can
>> agree
>> > to disagree, and if this vote passes then a new precedent will have been
>> > set.
>> >
>> >
>> > The bad:
>> >
>> > * CHANGES file contains changes for 1.5.0 and 1.4.0 (BAD)
>> > ** Past discussion here: http://markmail.org/message/ulvovup36uaa2cav
>> > ** It seems like we agreed to only include changes from the current major
>> > release line, but that is not 100% clear.
>>
>> 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)?
>>
>> Yes, my understanding was that only 1.6.0 changes would be present. Yes, I
> believe that this warrants a -1.
>
>
>> >
>> > * Missing licence headers:
>> > ** README
>> > ** conf/examples/crypto/readme.txt
>> > ** test/compat/japi-compliance/README
>> > ** test/system/continuous/ScaleTest.odp
>> > **
>> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.odg
>> >
>> > **
>> > docs/src/main/latex/common/state_diagrams/HDFS_WAL_states.pdf
>> >
>> > **
>> > docs/src/main/latex/common/state_diagrams/tablet_states.odg
>> >
>> > ** docs/src/main/latex/common/state_diagrams/tablet_states.pdf
>>
>> 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.
>>
>> http://www.apache.org/legal/src-headers.html#faq-exceptions
>
> The README has plenty of intellectual creativity in its content, and is
> therefore subject to copyright claims. It could be argued that the other
> two README files are short enough to not have copyright-able content, but
> it doesn't sound like that's the case you want to make.
>
> There is also lengthy discussion on
> https://issues.apache.org/jira/browse/LEGAL-114 but again, that is focused
> on small, non-creative files. Our README does not fall into that category.
>
Agreed. Sorry, I meant the two smaller files didn't have enough. I had
combined two paragraphs for succinctness and this distinction got
lost.
>
>> 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.
>>
>
> I do not agree that "in general, coverage by LICENSE files is sufficient.
> If that were the case, then we would not need to put headers on our source
> files, on our markdown files, on our example configuration files, etc...
>
> I also do not accept "they've been around for a while and nobody noticed
> it" as a reason to continue to ignore them. Either they are a violation, or
> they are not. This is not to say that we have been perfect in the past, but
> instead we correct mistakes when they are brought to attention.
No, the "in general" part I was referring to only was for binary
files, which cannot be labeled without altering the contents. That is
not the case here (if the document formats allow metadata), but a
general explanation of the assumptions that the RAT check makes. I
also agree precedent should not determine the correct course of
action. The comment about precedent was specifically made in the
context of the parenthetical presumption... if that presumption does
not hold, and they did not block for some other reason (oversight, for
example), that is a different statement entirely.