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:09 GMT
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