lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sami Siren <ssi...@gmail.com>
Subject Re: [VOTE] Release Apache Nutch 1.0
Date Thu, 19 Mar 2009 13:15:17 GMT
thanks Jukka,

Jukka Zitting wrote:
> Hi,
> 
> On Thu, Mar 19, 2009 at 10:32 AM, Sami Siren <ssiren@gmail.com> wrote:
>> We (as a Nutch community) would really appreciate if somebody from the PMC
>> had the time to check it out.
> 
> -1 The release contains the Java Advanced Imaging libraries
> (jai_core.jar and jai_codec.jar) which are licensed under Sun's Binary
> Code License. We can't redistribute those libraries.

ok, we need to address that somehow.

> Other comments based on a quick look:
> 
> * The LICENSE.txt file should have at least references to the licenses
> of the bundled libraries.
> 
> * The NOTICE.txt file should start with the the following lines:
> 
>           Apache Nutch
>           Copyright 2009 The Apache Software Foundation
> 
> * The NOTICE.txt file should contain the required copyright notices
> from all bundled libraries.
> 
> * The README.txt should start with "Apache Nutch" instead of "Nutch"
> 
> * Why does the release package contain pre-built documentation and
> binaries? Downloading the 90MB package takes much longer than checking
> out and building the 40MB tag from svn.
> IMHO it would be a service to users to make the release contain just the svn export with
instruction
> on how to build the rest. 

I see your point about the fat artifact but I am not totally convinced 
that users (as in end users) would prefer the idea of fetching the 
development tools and compiling the software before they use it, at 
least I am not doing that with the software I use.

I will discuss this with rest of the devs and see what we can do here. 
One solution could be to split the release in two parts binary only and 
source (they would both be about the same size since out build process 
currently copies jars around I think that's mostly the reason for the 
gigantic size) as you propose below.

> We can also still provide pre-built binaries
> as separate downloads. 
> More notably: how am I to verify that the
> release came from the sources in our svn when it contains stuff that
> doesn't exist in the svn?

May be that I don't understand what you're trying to say here but isn't 
that always the case with binary releases (the difficulty to verify that 
the binary is build from certain tag from svn)?

--
  Sami Siren

Mime
View raw message