I agree with doing a source release now while gradually fixing a binary release.
On Monday, September 5, 2016, Suneel Marthi <smar...@apache.org> wrote: > Its easy to do what Andy is describing using maven's assembly plugin in the > maven world. I have no experience with sbt so can't speak to how it can be > done with Sbt and would defer that to the experts. > > We hit a similar issue with licenses in source and binary on the first Pirk > release last week. We finally decided to make a source-only first release > while we r now working on fixing the binary license packaging for the next > release. > > > > On Mon, Sep 5, 2016 at 2:05 PM, Andrew Purtell <andrew.purt...@gmail.com > <javascript:;>> > wrote: > > > It covers LICENSE and NOTICE file generation for both source and binary > > releases, and inclusion of the resulting files in source archives, binary > > jars, and binary archives through integration with the maven build and > > assembly targets. > > > > Including the complete text of any given license in LICENSE is important > > but only needs to be done once. You retain the copyright notice and > mention > > of the license type per dependency. We are just talking about > > deduplicating, eg 100 full texts of the ASLv2 into one. > > > > > On Sep 5, 2016, at 10:45 AM, Pat Ferrel <p...@occamsmachete.com > <javascript:;>> wrote: > > > > > > Thanks Andy. > > > > > > RE “Only need to include one entry with the complete text of a license, > > everything else can just name the license.” So the copyright notice in > the > > license is not important, only the license type? This is often the only > > important difference in the license from one dep to another. > > > > > > It sounds like your automation covered LICENSE.txt creation? or just > > inclusion in the binary? > > > > > > > > > On Sep 5, 2016, at 9:59 AM, Andrew Purtell <andrew.purt...@gmail.com > <javascript:;>> > > wrote: > > > > > > I won't weigh in on the question at hand but I'd like to make a couple > > of clarifications for what it is worth: > > > > > >> This yielded 166 deps, so this implies we need to include 166 licenses > > and copyright notices in LICENSE.txt. > > > > > > There are some available simplifications: > > > > > > - Only need to include one entry with the complete text of a license, > > everything else can just name the license. > > > > > > - Where there are multiple artifacts coming from a single project, like > > Hadoop, only one entry for the project is needed. > > > > > >> Donald is looking at automating this but I’m personally dubious > > > > > > As I think I've mentioned before here we have successfully automated > > this for HBase (based on automation done by yet other Apache projects) > so I > > hope you'll take my advice and evidence based assertion it can be done. > > Caveat: we use maven not SBT as build framework. > > > > > > > > >> > > >> On Sep 5, 2016, at 9:43 AM, Pat Ferrel <p...@actionml.com > <javascript:;>> wrote: > > >> > > >> This weekend I tracked down all out deps, which required a few scripts > > to process sbt output. This yielded 166 deps, so this implies we need to > > include 166 licenses and copyright notices in LICENSE.txt. As I read the > > Apache guidelines this should be the license that goes with the version > we > > include since the copyright owner of license may have changed in newer > > versions. > > >> > > >> This may be near impossible to maintain by hand if we have frequent > > dependency upgrades and frequent releases. Donald is looking at > automating > > this but I’m personally dubious about this because it require all 166 > deps > > have maintained their licenses in artifacts for all versions we might > use. > > >> > > >> A source release requires that *only* the source included be reflected > > in LICENSES.txt. This would be ~0, I think a couple things are included. > > >> > > >> Several things lead me to favor a source-only release: > > >> 1) 166 licenses needed for binary ~0 needed for source—I’d rather we > > spend time on things that add more value > > >> 2) I have never used the binary release. Any version of a source > > download and `./make-dirstribution` works universally. > > >> 3) our install.sh now installs source and builds it for the user. This > > is good because we can use the same script for unreleased -SNAPSHOT > > versions sitting in the `develop` branch. > > >> 4) outside of instructions for downloading and installing the binary > > that do not yet exist afaik, there would be no obvious way for the user > to > > get the binary. > > >> 5) indirectly any delay to release is getting to be a serious problem. > > We haven’t had a well supported release from the main project since close > > on a year ago and work on new features is being delayed. > > >> 6) we can do a source only release now and be clean of the license > > issue as far as the IPMC is concerned. We can add binary when we have a > > better answer to automation. In other words why hold the release for > binary? > > >> > > >> Since this decision will affect the project for as long as it is in > > incubation. I’d like to see what others think. I believe we can release > now > > if we do source-only. > > >> > > >> Source only, or source & binary? > > > > > >
