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
