lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Miller <markrmil...@gmail.com>
Subject Re: [VOTE] Release Solr 1.4.1
Date Wed, 16 Jun 2010 23:29:10 GMT
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


Mime
View raw message