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<markrmiller@gmail.com>
> : Reply-To: dev@lucene.apache.org
> : To: dev@lucene.apache.org
> : 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: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org
|