Inline responses:
On 6/16/10 7:00 PM, Chris Hostetter wrote:
On Tue, 15 Jun 2010, Mark Miller wrote:
: Date: Tue, 15 Jun 2010 11:54:46 -0400
: From: Mark Miller<[email protected]>
: Reply-To: [email protected]
: To: [email protected]
: Subject: [VOTE] Release Solr 1.4.1
:
: Please vote on releasing the Solr 1.4.1 artifacts located at
: http://http://people.apache.org/~markrmiller/staging-area/
Source wise things look good -- but I think we're going to need another RC
because of some cruft i'm seeing in the release. full details below...
----------
### Review of these artifacts...
md5sum apache-solr-1.4.1.tgz apache-solr-1.4.1.zip
915febc17bd40eb7db2f8be318fd439d apache-solr-1.4.1.tgz
f672e3759e8f0d3d0eb738f2dbca5bf1 apache-solr-1.4.1.zip
### Things I looked at
- recursive diff of tgz and zip artifacts to make sure they match
- ignoring line endings for obvious reasons
- basic usage of example via the tutorial
- recursive diff of 1.4.0 with 1.4.1
- verify that file lists are the same, except where expected
- detailed reviewed all src diffs
### Notes
all src diffs corrispond with my expecations based on CHANGES.txt
--
the javadocs seem to have been built with javadoc 1.6 (not 1.5)
... this seems to have changed the link style somewhat significantly.
doesn't seem like it's a problem, but it was a little hard to review
for changes. If we do another RC it may be worthwhile to ensure
Javadoc 1.5 is used for consistency with Solr 1.4.0
(if JAVA_HOME is set to a 1.5 java install during build this shouldn't
be a problem)
Interesting - I'll look into it - def using java 1.5 for the build
(build 1.6 and 1.7 are also on this machine though).
--
there is an odd looking "bin" directory at the top level of the
release containing all the test files and the *.class files. not sure
where that came from (artifact of miller's IDE?) ... it's 7MB of cruft.
Very weird - Eclipse does work with a bin folder, but its at the top
level of the project (eg next to build) - why the heck does the Solr
dist process pull that in? I'll take care of it, but I don't see why
that should happen - part of pulling in the src dirs or something? Easy
enough to remove the bin folder first.
--
I'm seeing multiple velocity contrib jars w/odd file names...
$ ls contrib/velocity/src/main/solr/lib/*solr*
contrib/velocity/src/main/solr/lib/apache-solr-velocity-1.4.1-dev.jar
contrib/velocity/src/main/solr/lib/apache-solr-velocity-1.4.1.jar
contrib/velocity/src/main/solr/lib/apache-solr-velocity-1.4.2-dev.jar
contrib/velocity/src/main/solr/lib/apache-solr-velocity-X.Y.M.jar
...this is probably a show stopper that will require a new RC.
Yuck - this gets created by the build (and I had done the build a couple
times with the wrong system params - version x.y.m and 1.4.2 and the
default of 1.4.1-dev) - and clean doesn't remove them. Will take care of
- this should be cleaned up - will likely be fixed by changing where
this jar is created as you mention below - I'll handle will a manual
clean for now.
having multiple versions of the jar could easily break things with
class incompatibilities depending on what version they get loaded in
by the classloader.
(FWIW: all of the "solr" jars are all suppose to be in "dist" ... but
it looks like that dir is where the apache-solr-velocity jar was in
1.4.0 as well so probably not something we should change in this
release)
--
the example has an uncompressed war, a request log file, and
an already constructed index in it...
Only in tgz/apache-solr-1.4.1/example/logs: 2010_06_16.request.log
Only in tgz/apache-solr-1.4.1/example/solr: data
Only in tgz/apache-solr-1.4.1/example/work:
Jetty_0_0_0_0_8983_solr.war__solr__k1kf17
...these aren't suppose to be there (but probably don't hurt much)
Will kills these too - more stuff that it would be ideal if a master
clean removed. Would be ideal if a clean prepare-release or clean-all
prepare-release or something put you in the right shape with regards to
all this cruft.
--
version info says...
Solr Implementation Version: 1.4.1 954930M - mark - 2010-06-15 11:23:44
...that "M" indicates local modifications. it's not really a blocker,
but ideally the build should be from a known reproducable state of
SVN (ie: since it looks like we may do another release candidate,
let's make sure it's an unmodified checkout, but it's not a huge deal)
Ugg - yeah, the local modifications are because I have to modify the
prepare-release target to pass my username to svn - else it tries to use
mark rather than markrmiller. That is a major pain (I don't like that it
tries to commit for me anyway). It would be easy to get around by
calling other targets (and skipping build-site) if it didn't have some
maven cruft it did in it - I'll look into a workaround.
I don't mind the auto stuff for building the site, but I'd rather the
commit part was either a separate target or something to be done manually.
---
-Hoss
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
Will def do another RC (I havn't finished looking through for a vote yet
myself), but please keep inspecting this one everyone else - hopefully
the next will be the last.
--
- Mark
http://www.lucidimagination.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
