Mailing-List: contact general-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Date: Thu, 19 Mar 2009 23:25:59 -0700 (PDT)
From: Chris Hostetter <hossman_lucene@fucit.org>
To: general@lucene.apache.org
cc: nutch-dev@lucene.apache.org
Subject: Re: [VOTE] Release Apache Nutch 1.0
In-Reply-To: <510143ac0903190659u2884710jb502e430abcf7587@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.0903192304380.30953@radix.cryptio.net>
References: <49B6181B.1050802@gmail.com> <49BB6322.307@gmail.com>
 <49C21123.4060809@gmail.com>
  <510143ac0903190523w76e541a6s214f7b5f183482ad@mail.gmail.com>
  <49C24565.3020904@gmail.com>
 <510143ac0903190659u2884710jb502e430abcf7587@mail.gmail.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII


For the record: i have not had any time to review hte release candidate, 
my comments below are only based on this thread...

: > 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.
: 
: Most end users are happy with just the binaries. But pure source
: releases are really useful for example for people that maintain custom
: modifications as patches against the official source releases (think
: of Linux distributions with system-specific changes, companies with
: proprietary extensions, etc.). I'm not sure if Nutch yet has such
: users.

in terms of release type (source vs binary vs combined) it's important to 
keep the audience in mind ... a pure source release probably isn't 
suitable for the nutch user base, since it's primary purpose is to be a 
standalone application people can run without any knowledge of java. (Solr 
is in a similar boat).  A pure binary release (AFAIK) isn't permitted in 
the ASF.  A combined release tends to satisfy everyone.

it may result in a download that seems bloated, but anecdotaly people 
seem to be more bothered by a download that's lacking something they think 
it should have then by a release that contains more then they think it 
should have.  

A "full" release packge with combined source and binaries (and docs) also 
makes it easier for people to "try out" software easily, and puruse the 
docs, and puruse the source code, etc...

I suspect most people maintaining packages of official releases aren't 
particularly bothered by releases that are combined -- they can always 
ignore the compiled code and only deal with the source, in many cases it's 
as simple as adding "ant clean" to the first line of their patch-and-build 
script.  (but i'm certianly not an expert on how package managers think)

: That would be nice. Note that even the users who just want the
: binaries benefit from such a division as also their downloads will be
: faster.

Ehhh ... i'm not sure that angle (src making banary releases larger) is 
ever really an issue ... if i remember right i think the size of 
the compressed source code for solr was only about 10% of the final size 
of the last full release.

: PS. I know there's a long tradition of doing releases the way you
: prepared Nutch 1.0, and I'm not claiming that it's necessarily the
: wrong way of doing things. My -1 was due to the JAI libraries, not due
: to the structure of the release. However, as described above, I
: personally much prefer the clear distinction between source releases
: and binaries.

While the JAI and LICENSE.txt issues definitely seem like they need worked 
out before i release, i wouldn't suggest radically revamping the packaging 
strategy just prior to a release ... even if the concensus is that 
changing the release structure/size is a good ide in the long run.  
probably better to do it just after the release, so there is a long period 
of developer builds to work out any glitches.


-Hoss