lucene-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: [VOTE] Release Apache Nutch 1.0
Date Fri, 20 Mar 2009 06:25:59 GMT

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


Mime
View raw message