On Tue, Dec 07, 2010 at 08:41:10PM -0600, Peter Karman wrote: > Chris Hostetter wrote on 12/7/10 8:29 PM: > > > 1) Although the lucene release haven't really set a good example of this, > > the mantra Juka has always evangalized that i've come to appreciate is > > that the "source" release should essentially be "svn export | tar | gzip" > > > > +1
OK, great! The path forward starts to look clear. First, I'll close <https://issues.apache.org/jira/browse/LUCY-130> as a wontfix. We'll keep the basic layout we have now, and you'll still need to cd into a host language dir to build for a given target. Next, we have to rearrange the sources a bit. Changes and README should move up one level, out of trunk/perl/ into trunk/, where they will become shared. README's content will have to be generalized. We probably want to move the sample US Constitution corpus, too, up out of trunk/perl/sample/us_constitution/ -- but that's a little tricky, because trunk/perl/sample/ also contains a bunch of Perl apps. My first take is that each host language subdirectory should have its own sample directory, i.e. this... trunk/corpora/us_constitution/ trunk/perl/sample/ trunk/python/sample/ trunk/ruby/sample/ ... and not this: trunk/sample/us_constitution/ trunk/sample/perl/ trunk/sample/python/ trunk/sample/ruby/ Since IMO it would be confusing to have "sample" directories both at the top level and within host language dirs, I think the new destination for the corpus should be $dist_root/corpora/us_constitution/ -- which would be found at the top level of both the ASF release and the downstream packages. The word "corpora" is kind of esoteric, but oh well. MANIFEST is a little more annoying. I got tired of forgetting to update MANIFEST and started autogenerating it at dist build time, living with warnings when building from SVN checkout. However, if the ASF release is just a snapshot of the repository, we'd also get those warnings when building from the official tarball, which is less cool. And Build.PL needs MANIFEST immediately nearby -- i.e. at trunk/perl/MANIFEST, so trunk/MANIFEST won't do. Do we really have to start maintaining trunk/perl/MANIFEST, and do we need another one at the top level? Maybe we need a "prepare_commit" build target which verifies that various MANIFEST files are up-to-date, or something. I guess until there's a plan, I'll put this one off... After that, we have to fix the Perl "dist" build target. Right now it will snag the core/, charmonizer/, clownfish/ and devel/ directories, but it also needs to grab all the stuff that has moved around. The names for the downstream builds will all be customized according to what's best for the dist channel, and won't follow the conventions of either the Incubator or the Qpid example... ASF release: lucy-0.1.0-incubating.tar.gz CPAN release: Lucy-0.1.0.tar.gz ... but we'll have to add a note somewhere to indicate that the CPAN release is not an official ASF package: http://incubator.apache.org/guides/releasemanagement.html#best-practice-downstream Need to add notes that these are not official releases. Lastly, thinking about non-Perl downstream distros like PyPI, PEAR, etc... we'll autogenerate all files which depend on Clownfish (and therefore Perl) at *dist* build time. Thus, you'll still need Perl to build Lucy from the official Apache source release, but if you obtain Lucy from a dist channel like PyPI, you won't. Marvin Humphrey
