First, I want to say that I think being able to release more frequently is great. Thanks Mike for taking the initiative.
But we need to be able to fix packaging problems, and the only time we look at them is at release time. So I'm -1 to the idea of ignoring problems because we don't want to hold back releases. Re-spinning must remain a real option. Another random thought: we have had a tradition of spending time fixing docs prior to a release. I don't think this makes sense anymore: releasing should be as rote as possible. But I don't think our docs should suffer as a result of this shift. This implies that we should be looking harder at documentation when things get committed. (This is a good thing.) Lucene ------ Release blocking issues: 1. Snowball license: On 5/30/2011 at 8:22 AM, Doron Cohen wrote: > 3) Lucene src pack contains SNOWBALL-LICENSE.txt which is > not in either of the two binary packages, is this a problem? -1 to RC1 based on this. Unlike the other license files in the source distribution, which cover external .jar dependencies (in various lib/ directories in the source archive, but not in the release archives), the Snowball license covers content in the released Lucene binaries. 2. Source archive broken build: > 5) running 'ant clean' (or any target) from tarsrc/lucene-3.2.0 > fails due to dependency in ../common-build.xml. -1 to RC1 based on this. The source tarball needs to be usable. At present, nothing in the missing imported file is used in the Lucene build, so the <import> tag in lucene/common-build.xml could be removed. Alternatively, adding the attribute optional="true" to the <import> tag allows the build to function. 3. Contrib Javadocs include links to removed contribs ant, db, lucli, and swing. -1 to RC1 based on this. Non-blocking issues: 1. NOTICE.txt refers to .jar files and the corresponding LICENSE files in various lib/ directories, which are not included in the binary archives. Should we have a way to automatically strip these things from the source NOTICE.txt to form a release NOTICE.txt? 2. CHANGES.txt has no release date for 3.1.0 - although we've stopped putting dates on RCs' CHANGES.txt for the release-to-be, we should add dates to CHANGES.txt for past releases. Solr ---- Starting the example server and posting the example docs (following example/README.txt) works for me from the .tgz binary archive, as does building/running the tests from the source archive, though I had to switch to a 1.6 JVM to get the tests to complete - under Win7 with a 1.5 JVM, there were build failures related to file deletion problems. Release blocking issues: 1. Default to the new Tiered flush policy: On 5/29/2011 at 10:42 AM, Mark Miller wrote: > The only thing I am concerned about is that Solr does not use > VERSION_32 in the example and so does not use the new Tiered > flush policy. I do think that's worth a respin I agree. -1 to RC1 based on this. 2. All contrib/*/CHANGES.txt have "3.2-dev" as the release header. -1 to RC1 based on this. Steve > -----Original Message----- > From: Michael McCandless [mailto:[email protected]] > Sent: Friday, May 27, 2011 11:50 AM > To: [email protected] Dev > Subject: [VOTE] Release Lucene/Solr 3.2.0 > > Please vote to release the artifacts at: > > http://people.apache.org/~mikemccand/lucene_solr_320/rc1/ > > as Lucene 3.2.0 and Solr 3.2.0. > > Mike > > http://blog.mikemccandless.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected]
