Return-Path: X-Original-To: apmail-incubator-general-archive@www.apache.org Delivered-To: apmail-incubator-general-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 62EE310B88 for ; Tue, 25 Mar 2014 23:49:12 +0000 (UTC) Received: (qmail 1636 invoked by uid 500); 25 Mar 2014 23:48:54 -0000 Delivered-To: apmail-incubator-general-archive@incubator.apache.org Received: (qmail 1461 invoked by uid 500); 25 Mar 2014 23:48:52 -0000 Mailing-List: contact general-help@incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: general@incubator.apache.org Delivered-To: mailing list general@incubator.apache.org Received: (qmail 1450 invoked by uid 99); 25 Mar 2014 23:48:51 -0000 Received: from minotaur.apache.org (HELO minotaur.apache.org) (140.211.11.9) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2014 23:48:51 +0000 Received: from localhost (HELO mail-yh0-f42.google.com) (127.0.0.1) (smtp-auth username jamestaylor, mechanism plain) by minotaur.apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Mar 2014 23:48:51 +0000 Received: by mail-yh0-f42.google.com with SMTP id t59so1353082yho.15 for ; Tue, 25 Mar 2014 16:48:50 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=qBCyaEExVtliNlke9MocHpCYC12+YlSyIw8muU78v14=; b=kLCLTj4cTBdsAaHSry1bwssndiVm3qI3ZAKqdCJ2M79j3B8iEkwL/H/4qOvCyqiMLQ jOropq5cwui6yXj4SdjZ/aSnmOHYPejFvGD+LYNbOIqXoM7PKK0NgHvKT93R7Ndw6Hpy i2lvfQZyCyHhOv7454rL0GU+DUQi/BidbwAiKFyJJ5tWyFlwKwjuCMLd1QrAD0c64waQ P4DGzeUVXO/YLOym8dzM9A3jGsnNAwj3Zws8pGTfxGu/ioQiV19+272C2GIwL5w0nHbu YkC7OG/oTw/ENcPthHMkXnFGSfP01Kfw2FWFIyfpS9HFhx2Ed7hZ2MVxGv0BuaHOlsGE e6fw== MIME-Version: 1.0 X-Received: by 10.236.30.230 with SMTP id k66mr78082615yha.57.1395791330524; Tue, 25 Mar 2014 16:48:50 -0700 (PDT) Received: by 10.170.195.68 with HTTP; Tue, 25 Mar 2014 16:48:50 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Mar 2014 16:48:50 -0700 Message-ID: Subject: Re: [VOTE] Release of Apache Phoenix 3.0.0 incubating RC1 From: James Taylor To: James Taylor Cc: general@incubator.apache.org Content-Type: multipart/alternative; boundary=089e016340746fc4da04f576fe82 --089e016340746fc4da04f576fe82 Content-Type: text/plain; charset=ISO-8859-1 (sorry, meant instead of listing these in our NOTICE file) On Tue, Mar 25, 2014 at 4:48 PM, James Taylor 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 wrote: > >> On 25 March 2014 23:06, James Taylor 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 wrote: >> > >> >> On 25 March 2014 22:27, James Taylor 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 > > >> >> 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 wrote: >> >> >> >> >> >> > On 25 March 2014 22:01, Andrew Purtell >> 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 wrote: >> >> >> > > >> >> >> > >> On 25 March 2014 21:56, Andrew Purtell >> >> wrote: >> >> >> > >> > On Tue, Mar 25, 2014 at 11:54 AM, sebb >> 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 >> >> > --089e016340746fc4da04f576fe82--