: Please vote to release the artifacts at : http://people.apache.org/~yonik/staging_area/lucene-solr-3.1RC2
-0 I can't in good conscience vote for these artifacts. For the most part, there only only a few minor hicups -- but the big blocker (in my opinion) is that since RC1, dev-tools has been removed from the solr src packages and this causes the top level build.xml (and instructions for IDE users in the top level README.txt file) to be broken. My detailed notes below... ########################## ### apache-solr-3.1.0-src.tgz dev-tools isn't in here -- this totally boggles my mind, particularly since there was a deliberate and concious switch to make the source releases match what you get when doing an "svn export" because dev-tools is missing, 3 of the top level ant targets advertised using "ant -p" don't work; including 'ant idea' and 'ant eclipse' which are also explicitly mentioned in the top level README.txt as how people using those IDEs should get started developing the code. This seems like a major issue to me. we're setting ourselves up to make the release look completely broken right out of the gate for anyone using one of those IDEs. Ask about this on IRC. yonik & ryan indicated that a couple of folks had said they would veto any release with dev-tools in it because that stuff is suppose to be "unsupported" ... this makes no sense to me as we have lots of places in the code base where things are documented as being experimental, subject to change, and/or for developer use only. i don't relaly see how dev-tools should be any different. if there is really such violent oposition to including dev-tools in src releases, then the top level build.xml should not depend on it, and the top level README.txt should not refer to it (except maybe with something like "people interested in hacking on the src should use svn which includes some unofficial 'dev-tools'" --- Now that the src packages are driven by svn exports, more files exist then were in RC1 and some of the changes we made to the solr/README.txt based on the earlier release candidates are missleading. In particular a lot of things are listed as being in the "docs" directory of a binary distribution, but those files *do* exist in the src packages -- if you look in the "site" directory. This seems silly, but at no point is the README.txt factually incorrect, so I guess it's not a big enough deal to worry about. --- running all tests, running the example, and building the javadocs all worked fine. ########################## ### apache-solr-3.1.0.tgz docs look good, basic example usage works fine. ########################## ### apache-solr-3.1.0.zip Diffing the contents of apache-solr-3.1.0.tgz with apache-solr-3.1.0.zip (using "diff --ignore-all-space --strip-trailing-cr -r") turned up a quite a fiew instances where the CRLF fixing in build.xml seems to have corrupted some non-ascii characters in a few files.... contrib/dataimporthandler/lib/activation-LICENSE.txt contrib/dataimporthandler/lib/mail-LICENSE.txt docs/skin/CommonMessages_de.xml docs/skin/CommonMessages_es.xml docs/skin/CommonMessages_fr.xml example/solr/conf/velocity/facet_dates.vm ...but these changes don't seem to have substantively harmed the files. ########################## ### lucene-3.1.0-src.tar.gz tests and javadocs worked fine. ########################## ### lucene-3.1.0.tar.gz docs look good, demo runs fine. ########################## ### lucene-3.1.0.zip no differences found with lucene-3.1.0.tar.gz -Hoss --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
