Please vote on releasing the Solr 1.4.1 artifacts located at
http://http://people.apache.org/~markrmiller/staging-area/

CHANGES are spelled out at
https://svn.apache.org/repos/asf/lucene/solr/branches/branch-1.4/CHANGES.txt

Note that I am not voting yet - I have not thoroughly gone over
everything yet (though I have done the basics - verified the signed
files, ran through the tutorial with tomcat/jetty (not resin yet),
browsed the documentation, etc) - but in the interest of time, I'm
putting up this RC early to give others a chance to start nit-picking as
well. Testers wanted.

I wouldn't at all be surprised if there was an RC2 or if there was not
(as this is just a bug release off 1.4, most things should be kosher).

Also note, this is my first time as Solr RM - so I may have just totally
f'd up the world in ways that no one would think possible.

Lets try to find any and all issues so that at most we have one more RC.
Thanks,

--
- Mark

http://www.lucidimagination.com

---------------------------------------------------------------------

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)

--

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.

--

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.  

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)

--

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)

---
-Hoss
---------------------------------------------------------------------

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.
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.
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

: 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).

it may just be that the 1.6 version of javadoc is first in your PATH ...
not sure how <ant> calls javadoc.

: 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.

yeah .. the bug is definitely in the velocity build process, but changing
the location of the jar in a X.Y.1 release seems bad.
: 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'm not really familiar with that target -- but you should just commit
that modification to all the branches (1.4, 3x, and trunk) .. that's a
horribly assumption for our build file to make.

-Hoss
---------------------------------------------------------------------

On 6/16/10 7:00 PM, Chris Hostetter wrote:

> 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.
>
> 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)
>

I'm actually seeing both
contrib/velocity/src/main/solr/lib/apache-solr-velocity-1.4.0.jar
contrib/velocity/src/main/solr/lib/apache-solr-velocity-1.4.1-dev.jar

In the Solr 1.4 release...

Won't happen this time though.

--
- Mark

http://www.lucidimagination.com

---------------------------------------------------------------------

On 6/16/10 7:00 PM, Chris Hostetter wrote:

> 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)
>

Hmmm...it actually looks like the reverse happend?

1.4 was built with javadoc 1.6:

<!-- Generated by javadoc (build 1.6.0_15) on Fri Nov 06 12:35:41 EST
2009 -->

and my 1.4.1 rc was built with 1.5:

<!-- Generated by javadoc (build 1.5.0_19) on Wed Jun 16 20:02:56 EDT
2010 -->

I'll try doing the next RC with 1.6 instead?

--
- Mark

http://www.lucidimagination.com

---------------------------------------------------------------------

The newly provided patch at
https://issues.apache.org/jira/browse/SOLR-1885 looks correct.
Should we include it?

-Yonik
http://www.lucidimagination.com
On Wed, Jun 16, 2010 at 8:21 PM, Mark Miller <[EMAIL PROTECTED]> wrote:
> On 6/16/10 7:00 PM, Chris Hostetter wrote:
>
>> 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)
>>
>
> Hmmm...it actually looks like the reverse happend?
>
> 1.4 was built with javadoc 1.6:
>
> <!-- Generated by javadoc (build 1.6.0_15) on Fri Nov 06 12:35:41 EST 2009
> -->
>
> and my 1.4.1 rc was built with 1.5:
>
> <!-- Generated by javadoc (build 1.5.0_19) on Wed Jun 16 20:02:56 EDT 2010
> -->
>
> I'll try doing the next RC with 1.6 instead?
>
> --
> - Mark
>
> http://www.lucidimagination.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

---------------------------------------------------------------------

On 6/16/10 8:31 PM, Yonik Seeley wrote:
> The newly provided patch at
> https://issues.apache.org/jira/browse/SOLR-1885 looks correct.
> Should we include it?
>
> -Yonik
> http://www.lucidimagination.com
>

+1

--
- Mark

http://www.lucidimagination.com

---------------------------------------------------------------------

:
: Hmmm...it actually looks like the reverse happend?
:
: 1.4 was built with javadoc 1.6:

whoops! ... you're correct, i missread the diff.

: I'll try doing the next RC with 1.6 instead?

for hte javadoc's you mean? .. yeah that's probably wise -- just to
minimize the total changes (it's a minor thing, but if it's easy to do
we might as well)

-Hoss
---------------------------------------------------------------------

On Jun 16, 2010, at 7:00 PM, Chris Hostetter wrote:
> --
>
> 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.
>
> having multiple versions of the jar could easily break things with
> class incompatibilities depending on what version they get loaded in
> by the classloader.

A change was made on trunk to contrib/velocity/build.xml to clean up  
these old JARs:

   <target name="clean">
   <delete failonerror="false" dir="target"/>
   <delete>
    <fileset dir="src/main/solr/lib" includes="apache-solr-velocity-
*.jar"/>
   </delete>
   </target>

It's not on branch-1.4 though.  Should it be?  But at the very least,  
indeed those apache-solr-velocity-*.jar should be removed prior to a  
build.

> (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)

Noted - I'll fix this as VrW is moved to core.

Erik
---------------------------------------------------------------------