incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From James Taylor <jamestay...@apache.org>
Subject Re: [VOTE] Release of Apache Phoenix 3.0.0 incubating RC1
Date Tue, 25 Mar 2014 23:48:50 GMT
(sorry, meant instead of listing these in our NOTICE file)


On Tue, Mar 25, 2014 at 4:48 PM, James Taylor <jamestaylor@apache.org>wrote:

> Ah, I see. Thanks, Sebb. So we should modify our LICENSE file as indicated
> in http://www.apache.org/dev/licensing-howto.html#permissive-deps instead
> of listing these in our LICENSE file. Since all licenses are either Apache
> or BSD, this should be fine.
>
> I'm still a bit confused about one thing, though. The above link says "add
> a pointer to the dependency's location within the source tree". For
> sqlline, we bundle it, but have no source dependencies on it. It's used as
> a command line terminal interface. Is this pointer optional then? We could
> point to the python script that invokes it - would that be correct?
>
> For our HBase dependencies, we have many places in the source that call
> HBase APIs. Do we just list one of them?
>
>
> On Tue, Mar 25, 2014 at 4:25 PM, sebb <sebbaz@gmail.com> wrote:
>
>> On 25 March 2014 23:06, James Taylor <jamestaylor@apache.org> wrote:
>> > Our binary distribution bundles sqlline which has a BSD Clause 3
>> license.
>> > We've included this license with the Apache 2 license in our LICENSE
>> file.
>> > Do we need to include sqlline in the NOTICE file?
>>
>> Depends on its license.
>>
>> > Yes, we bundle ANTLR in our binary distribution. Most of the other items
>> > are pulled in based on the transitive dependencies of other jars we've
>> > bundled in our binary distribution.
>>
>> I see now why I did not notice the 3rd party binaries.
>> They seem to have been merged into jars which look like phoenix code -
>> and indeed also contain phoenix code.
>>
>> That is a very non-standard way to do things, and I think could
>> mislead end-users as to the provenance of the code.
>>
>> It's OK to bundle separate jars in a binary release (assuming
>> licensing etc is OK), but I don't think it's OK to merge 3rd party
>> code with ASF code in a single jar.
>> Apart from anything, that will play havoc with Maven and possibly
>> other dependency management systems.
>>
>> > That's why we included them in the NOTICE file. Is this correct?
>>
>> As I already wrote, not necessarily.
>> You can only include certain license types; in all cases the licenses
>> must be included in the bundle - either actually included in the
>> LICENSE file or locally linked from it.
>> Some licenses may require attribution in the NOTICE file.
>>
>> See for example
>>
>> http://www.apache.org/dev/licensing-howto.html#permissive-deps
>>
>> > Our LICENSE file includes the licenses of all bundled software - either
>> > Apache 2 or BSD Clause 3.
>>
>> But there is no indication as to which 3rd party software uses what
>> license.
>>
>> again, see
>>
>> http://www.apache.org/dev/licensing-howto.html#permissive-deps
>>
>> > Please advise, as we're trying to follow the guidelines listed here[1].
>>
>> As am I ...
>>
>> > Thanks,
>> > James
>> >
>> > [1] http://www.apache.org/dev/licensing-howto.html
>> >
>> >
>> >
>> > On Tue, Mar 25, 2014 at 3:48 PM, sebb <sebbaz@gmail.com> wrote:
>> >
>> >> On 25 March 2014 22:27, James Taylor <jamestaylor@apache.org> wrote:
>> >> > Thanks for the detailed review, Sebb. We really appreciate you
>> spending
>> >> > your time going through this. Here's the list of TODOs for us:
>> >> > 1) In the binary bundle:
>> >> >     a) Fix the copy/paste error for the URL to SQLLine in the NOTICE
>> file
>> >> > in the binary bundle as noted by Gabriel here[1].
>> >>
>> >> It's not clear to me that the SQLLine attribution should even be in
>> >> the NOTICE file.
>> >> Though of course if it must be included, the URL should be correct.
>> >>
>> >> >    b) Change "developed by" to "developed at" in the NOTICE file
>> >> >    c) In answer to your question, yes all those projects listed are
>> >> bundled
>> >> > with our binary distribution.
>> >>
>> >> Are you sure?
>> >> Even JUnit and ANTLR?
>> >>
>> >> Even if they are included, that only means that a LICENSE file entry
>> >> is needed, not necessarily a NOTICE entry.
>> >>
>> >> > 2) In the source bundle:
>> >> >     a) The target dir and rat.txt files should be removed from the
>> src
>> >> > bundle
>> >>
>> >> Yes.
>> >>
>> >> >     b) There were the following changes made to the src bundle not
>> >> > reflected in git:
>> >> >       - the docs/phoenix.csv file was removed (it's part of our
>> website
>> >> so
>> >> > should not be included in our git repo)
>> >>
>> >> OK
>> >>
>> >> >       - the build.txt file was modified slightly in the src bundle.
>> >>
>> >> Not OK.
>> >>
>> >> >       - the CHANGES file is bundled with the src bundle, but not
>> checked
>> >> > into git.
>> >>
>> >> The source bundle must only contain files contained in the Git tag.
>> >>
>> >> The point is that the only practical way to ensure that the source
>> >> bundle contains only files that have the appropriate license and are
>> >> allowed to be included in a release is to compare the files with Git
>> >> (or SVN). Otherwise it's impossible to establish provenance and
>> >> difficult to determine if the file has a suitable license.
>> >>
>> >> >      - the README.md file is not included in the src bundle, but
>> instead
>> >> a
>> >> > README file is included instead.
>> >>
>> >> The ASF releases source, so source files to create documentation
>> >> should be included.
>> >>
>> >> > For the source binary changes, we could commit and push those
>> changes to
>> >> > git and update our 3.0.0 tag. Would that be an acceptable solution?
>> >>
>> >> Not sure what you are proposing.
>> >>
>> >> The RC reviewers need to be able to check that the source bundle
>> >> agrees with the tag.
>> >> Also that the NOTICE and LICENSE files in the bundles agree with the
>> >> contents of those bundles and that any bundled code can be released
>> >> under the Apache License.
>> >>
>> >> > Are there more changes necessary to the NOTICE file in the binary
>> bundle?
>> >> > Would it be acceptable to fix the URL in the next release? If not,
>> would
>> >> we
>> >> > need to go through a dev vote again for the NOTICE file change?
>> >>
>> >> See above.
>> >>
>> >> > FWIW, we'll automate the generation of our release bundles for our
>> next
>> >> > release (and make sure the source matches exactly as well).
>> >>
>> >> > Thanks,
>> >> > James
>> >> >
>> >> > [1]
>> >> >
>> >>
>> http://mail-archives.apache.org/mod_mbox/incubator-phoenix-dev/201403.mbox/%3CCAA5C_puNoy74jniWMTbx%3DZFyc1itf0w6E4kCHvCOTK_OTfBgmg%40mail.gmail.com%3E
>> >> >
>> >> >
>> >> > On Tue, Mar 25, 2014 at 3:16 PM, Andrew Purtell <apurtell@apache.org
>> >
>> >> wrote:
>> >> >
>> >> >> James, Mujtaba, et. al.,
>> >> >>
>> >> >> Can we add a "Releasing" page to
>> http://phoenix.incubator.apache.org/that
>> >> >> includes step by step instructions for packaging a Phoenix release.
>> We
>> >> can
>> >> >> fine tune this process according to feedback received during RCs.
>> This
>> >> >> could/should include shell commands captured one time through your
>> >> process
>> >> >> for generating a source tarball from a Git checkout at an exact
SHA,
>> >> saving
>> >> >> off a clean source tarball before running release checks, generating
>> >> binary
>> >> >> release tarballs, calculating checksums over the tarballs, signing
>> the
>> >> >> tarballs, etc.
>> >> >>
>> >> >>
>> >> >> On Tue, Mar 25, 2014 at 3:09 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >>
>> >> >> > On 25 March 2014 22:01, Andrew Purtell <apurtell@apache.org>
>> wrote:
>> >> >> > > Pardon, got -bin and -src crossed mentally, indeed they
are
>> there.
>> >> >> > >
>> >> >> > > Looks like src was packaged after running the RAT check.
 Does
>> this
>> >> >> > require
>> >> >> > > a new RC?
>> >> >> >
>> >> >> > If I were the RM I would respin the RC for this sort of packaging
>> >> error.
>> >> >> >
>> >> >> > But in this case there are other more serious errors, the
binary
>> >> NOTICE
>> >> >> > file.
>> >> >> >
>> >> >> > And most important, please establish why the Git tag does
not
>> agree
>> >> >> > with the source archive, otherwise the new RC may also be
faulty
>> in
>> >> >> > that regard.
>> >> >> >
>> >> >> > It's vital that all files in the source bundle can be traced
back
>> to
>> >> >> > the source code control system.
>> >> >> >
>> >> >> > > On Tue, Mar 25, 2014 at 2:59 PM, sebb <sebbaz@gmail.com>
wrote:
>> >> >> > >
>> >> >> > >> On 25 March 2014 21:56, Andrew Purtell <apurtell@apache.org>
>> >> wrote:
>> >> >> > >> > On Tue, Mar 25, 2014 at 11:54 AM, sebb <sebbaz@gmail.com>
>> wrote:
>> >> >> > >> >
>> >> >> > >> >> On 25 March 2014 16:39, James Taylor <
>> jamestaylor@apache.org>
>> >> >> wrote:
>> >> >> > >> >> [...]
>> >> >> > >> >>
>> >> >> > >> >> > The source tarball, including signatures,
digests, etc
>> can be
>> >> >> found
>> >> >> > >> at:
>> >> >> > >> >> >
>> >> >> > >> >>
>> >> >> > >>
>> >> >> >
>> >> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/incubator/phoenix/phoenix-3.0.0-incubating-rc1/src/
>> >> >> > >> >>
>> >> >> > >> >> The source bundle includes directories and
files not in Git.
>> >> >> > >> >>
>> >> >> > >> >> There should be no "target" directories
in the source
>> bundle,
>> >> and
>> >> >> no
>> >> >> > >> >> Rat.txt files.
>> >> >> > >> >
>> >> >> > >> >
>> >> >> > >> > Where are those?
>> >> >> > >>
>> >> >> > >> In the source bundle.
>> >> >> > >>
>> >> >> > >> > $ wget
>> >> >> > >> >
>> >> >> > >>
>> >> >> >
>> >> >>
>> >>
>> https://dist.apache.org/repos/dist/dev/incubator/phoenix/phoenix-3.0.0-incubating-rc1/bin/phoenix-3.0.0-incubating.tar.gz
>> >> >> > >>
>> >> >> > >> That's the binary bundle.
>> >> >> >
>> >> >>
>> >> >> --
>> >> >> Best regards,
>> >> >>
>> >> >>    - Andy
>> >> >>
>> >> >> Problems worthy of attack prove their worth by hitting back. -
Piet
>> Hein
>> >> >> (via Tom White)
>> >> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: general-help@incubator.apache.org
>> >>
>> >>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: general-help@incubator.apache.org
>>
>>
>

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