Re: [VOTE] release 3.3 (take two)
It looks like the vote has passed... I'll work on getting these artifacts out. Thanks everyone for voting. On Tue, Jun 28, 2011 at 11:08 AM, Yonik Seeley wrote: > +1 > > -Yonik > http://www.lucidimagination.com > > On Sun, Jun 26, 2011 at 11:12 AM, Robert Muir wrote: >> Artifacts here: >> >> http://s.apache.org/lusolr330rc1 >> >> working release notes here: >> >> http://wiki.apache.org/lucene-java/ReleaseNote33 >> http://wiki.apache.org/solr/ReleaseNote33 >> >> To see the changes between the previous release candidate (rc0): >> svn diff -r 1139028:1139775 >> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 >> >> Here is my +1 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3 (take two)
+1 -Yonik http://www.lucidimagination.com On Sun, Jun 26, 2011 at 11:12 AM, Robert Muir wrote: > Artifacts here: > > http://s.apache.org/lusolr330rc1 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > To see the changes between the previous release candidate (rc0): > svn diff -r 1139028:1139775 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 > > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3 (take two)
On Mon, Jun 27, 2011 at 6:55 AM, Uwe Schindler wrote: > - Extracted Lucene and Solr binary packages and checked contents for > completeness (Licenses, Javadocs,...) - fine! Solr.WAR file contains correct > artifact versions, unfortunately the lucene jar files are not available in > the dist folder inside solr binary - is that wanted? I think that's fine for a binary release. The lucene jars are in the solr.war Anyone developing a custom solr plugin could just use the source distro, or explode the war. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3 (take two)
+1 PyLucene built from Lucene 3.3 rc3 passes all tests. Andi.. On Sun, 26 Jun 2011, Robert Muir wrote: Artifacts here: http://s.apache.org/lusolr330rc1 working release notes here: http://wiki.apache.org/lucene-java/ReleaseNote33 http://wiki.apache.org/solr/ReleaseNote33 To see the changes between the previous release candidate (rc0): svn diff -r 1139028:1139775 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 Here is my +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3 (take two)
Hi, This time, all is fine: - Smoke tests with tests.iter=100,tests.multiplicator=100,tests.nightly on Sun Java 1.5.0_22 Solaris-64 passed for Lucene-Core (using Lucene-Src package, so even compiles fine). Lucene-Contrib failed somehow, but with iter=1 passed. One core dump on testing contrib/analysis-common/ (Portuguese), seems Java 5 bug happens sometimes (unfortunately log & hs_err is gone), not reproducible. So all fine, don't want to accuse Java 5 - but policeman is angry and wants an expensive ticket + driver license removed from Java 5 :-) - All signatures are fine, signatures are all from Robert Muir who I know personally: find . -name '*.asc' | xargs -L1 gpg --verify - Artifact META-INFs are correct, versions and revno are correct - Lucene-core-3.3.0.jar from Maven plugged into PANGAEA was successfully without recompiling. No Hotspot issues - MMap is fine - Extracted Solr src package, ant test with iter=1 and multiplicator=100 and nightly passes from root folder (includes lucene tests) - Extracted Lucene and Solr binary packages and checked contents for completeness (Licenses, Javadocs,...) - fine! Solr.WAR file contains correct artifact versions, unfortunately the lucene jar files are not available in the dist folder inside solr binary - is that wanted? Small issue: - systemrequirements.html: The JUNIT version as requirement is ahm, ah, huho very old. We should remove that in future, as JUnit is bundled with src package. So here is my PMC +1 ! Uwe - Generics|Java5|Signature|Manifest Policeman with PMC vote - - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Sunday, June 26, 2011 5:12 PM > To: dev@lucene.apache.org > Subject: [VOTE] release 3.3 (take two) > > Artifacts here: > > http://s.apache.org/lusolr330rc1 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > To see the changes between the previous release candidate (rc0): > svn diff -r 1139028:1139775 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 > > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3 (take two)
+1 On Mon, Jun 27, 2011 at 8:32 AM, Sanne Grinovero wrote: > +1 > > All tests are fine on both Infinispan and Hibernate Search. > > While I understand that often APIs needed changes, I'm very happy to > state that for the first time three mayor releases are fully API > compatible! > (As far as tested on these projects, Lucene versions 3.1.0, 3.2.0, > 3.3.0 are drop-in compatible replacements) > > Regards, > Sanne > > 2011/6/26 Steven A Rowe : > > +1 > > > > I looked at the differences, and then just ran tests on the Solr and > Lucene source tarballs. > > > > Steve > > > >> -Original Message- > >> From: Robert Muir [mailto:rcm...@gmail.com] > >> Sent: Sunday, June 26, 2011 11:12 AM > >> To: dev@lucene.apache.org > >> Subject: [VOTE] release 3.3 (take two) > >> > >> Artifacts here: > >> > >> http://s.apache.org/lusolr330rc1 > >> > >> working release notes here: > >> > >> http://wiki.apache.org/lucene-java/ReleaseNote33 > >> http://wiki.apache.org/solr/ReleaseNote33 > >> > >> To see the changes between the previous release candidate (rc0): > >> svn diff -r 1139028:1139775 > >> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 > >> > >> Here is my +1 > >> > >> - > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > >> For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
Re: [VOTE] release 3.3 (take two)
+1 All tests are fine on both Infinispan and Hibernate Search. While I understand that often APIs needed changes, I'm very happy to state that for the first time three mayor releases are fully API compatible! (As far as tested on these projects, Lucene versions 3.1.0, 3.2.0, 3.3.0 are drop-in compatible replacements) Regards, Sanne 2011/6/26 Steven A Rowe : > +1 > > I looked at the differences, and then just ran tests on the Solr and Lucene > source tarballs. > > Steve > >> -Original Message- >> From: Robert Muir [mailto:rcm...@gmail.com] >> Sent: Sunday, June 26, 2011 11:12 AM >> To: dev@lucene.apache.org >> Subject: [VOTE] release 3.3 (take two) >> >> Artifacts here: >> >> http://s.apache.org/lusolr330rc1 >> >> working release notes here: >> >> http://wiki.apache.org/lucene-java/ReleaseNote33 >> http://wiki.apache.org/solr/ReleaseNote33 >> >> To see the changes between the previous release candidate (rc0): >> svn diff -r 1139028:1139775 >> https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 >> >> Here is my +1 >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3 (take two)
+1 I looked at the differences, and then just ran tests on the Solr and Lucene source tarballs. Steve > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Sunday, June 26, 2011 11:12 AM > To: dev@lucene.apache.org > Subject: [VOTE] release 3.3 (take two) > > Artifacts here: > > http://s.apache.org/lusolr330rc1 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > To see the changes between the previous release candidate (rc0): > svn diff -r 1139028:1139775 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 > > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3 (take two)
+1 Mike McCandless http://blog.mikemccandless.com On Sun, Jun 26, 2011 at 11:12 AM, Robert Muir wrote: > Artifacts here: > > http://s.apache.org/lusolr330rc1 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > To see the changes between the previous release candidate (rc0): > svn diff -r 1139028:1139775 > https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 > > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] release 3.3 (take two)
Artifacts here: http://s.apache.org/lusolr330rc1 working release notes here: http://wiki.apache.org/lucene-java/ReleaseNote33 http://wiki.apache.org/solr/ReleaseNote33 To see the changes between the previous release candidate (rc0): svn diff -r 1139028:1139775 https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3 Here is my +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 1:35 PM, Uwe Schindler wrote:
> Hi Yonik, I wrote atestcase that checks how prevSetBit behaves, if I add you
> patch with optimization. It still had a bug, if the index is beyond last
> word but not at a multiple of bitsPerWord.
Ahh, right, good catch! You want to start at the last bit rather than
calculate the bit via MOD in that case.
> Your additional optimization with negative indexes is invalid,
Well, invalid if negative indexes are valid.
> because on
> negative indexes prevSetBit() must be negative. If we don’t do this, a
> typical loop like would AIOOBE:
>
> for (int i = bs.prevSetBit(0); i >= 0; i = bs.prevSetBit(i-1)) {
> // operate on index i here
> }
Yep, that makes sense to allow.
-Yonik
http://www.lucidimagination.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
Hi Yonik, I wrote atestcase that checks how prevSetBit behaves, if I add you
patch with optimization. It still had a bug, if the index is beyond last
word but not at a multiple of bitsPerWord. The following code is correct:
public int prevSetBit(int index) {
int i = index >> 6;
final int subIndex;
if (i >= wlen) {
i = wlen - 1;
if (i < 0) return -1;
subIndex = 0x3f; // last possible bit
} else {
if (i < 0) return -1;
subIndex = index & 0x3f; // index within the word
}
long word = (bits[i] << (63-subIndex)); // skip all the bits to the
left of index
if (word != 0) {
return (i << 6) + subIndex - Long.numberOfLeadingZeros(word); // See
LUCENE-3197
}
while (--i >= 0) {
word = bits[i];
if (word !=0 ) {
return (i << 6) + 63 - Long.numberOfLeadingZeros(word);
}
}
return -1;
}
Your additional optimization with negative indexes is invalid, because on
negative indexes prevSetBit() must be negative. If we dont do this, a
typical loop like would AIOOBE:
for (int i = bs.prevSetBit(0); i >= 0; i = bs.prevSetBit(i-1)) {
// operate on index i here
}
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Friday, June 24, 2011 6:29 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
> wrote:
> > All that needs to be done is to move the negative index check to the
> > bottom (the first index<0 is not needed since we do a signed shift).
> >
> > public int prevSetBit(int index) {
> > int i = index>>6;
> > if (i >= wlen) {
> > i = wlen - 1;
> > }
> > if (i < 0) return -1;
> > final int subIndex = index & 0x3f; // index within the word
> > long word = (bits[i] << (63-subIndex)); // skip all the bits to
> > the left of index
>
> And a further minor optimization, if we assume that negative indexes are
not
> legal, is to move the (i<0) check inside the if (i>=wlen) block (and just
let a
> negative index passed by the user to cause a natural AIOOB).
>
> -Yonik
> http://www.lucidimagination.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
Yonik,
You are the best. If you look at the test, its also broken somehow, because
it uses length vs. size() wrong (I already reopened the
https://issues.apache.org/jira/browse/LUCENE-3179 issue).
And please stop ranting about Java 5, it helped to find a bug in this impl,
its really broken as OpenBitSet always allows indexes >= size (except fast*
methods).
Uwe
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
> -Original Message-
> From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
> Seeley
> Sent: Friday, June 24, 2011 6:29 PM
> To: dev@lucene.apache.org
> Subject: Re: [VOTE] release 3.3
>
> On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
> wrote:
> > All that needs to be done is to move the negative index check to the
> > bottom (the first index<0 is not needed since we do a signed shift).
> >
> > public int prevSetBit(int index) {
> > int i = index>>6;
> > if (i >= wlen) {
> > i = wlen - 1;
> > }
> > if (i < 0) return -1;
> > final int subIndex = index & 0x3f; // index within the word
> > long word = (bits[i] << (63-subIndex)); // skip all the bits to
> > the left of index
>
> And a further minor optimization, if we assume that negative indexes are
not
> legal, is to move the (i<0) check inside the if (i>=wlen) block (and just
let a
> negative index passed by the user to cause a natural AIOOB).
>
> -Yonik
> http://www.lucidimagination.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
> commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 12:14 PM, Yonik Seeley
wrote:
> All that needs to be done is to move the negative index check to the
> bottom (the first index<0 is not needed since we do a signed shift).
>
> public int prevSetBit(int index) {
> int i = index>>6;
> if (i >= wlen) {
> i = wlen - 1;
> }
> if (i < 0) return -1;
> final int subIndex = index & 0x3f; // index within the word
> long word = (bits[i] << (63-subIndex)); // skip all the bits to
> the left of index
And a further minor optimization, if we assume that negative indexes
are not legal, is to move the (i<0) check inside the if (i>=wlen)
block (and just let a negative index passed by the user to cause a
natural AIOOB).
-Yonik
http://www.lucidimagination.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
I just took a quick peek at the prevBitSet, and the implementation
looks buggy (provided that it's legal for a user to pass an "i" that
may be greater than the largest bit ever set).
Here is the current code, which will cause an exception when wlen==0.
public int prevSetBit(int index) {
if (index < 0) {
return -1;
}
int i = index>>6;
if (i >= wlen) {
i = wlen - 1;
}
final int subIndex = index & 0x3f; // index within the word
long word = (bits[i] << (63-subIndex)); // skip all the bits to
the left of index
All that needs to be done is to move the negative index check to the
bottom (the first index<0 is not needed since we do a signed shift).
public int prevSetBit(int index) {
int i = index>>6;
if (i >= wlen) {
i = wlen - 1;
}
if (i < 0) return -1;
final int subIndex = index & 0x3f; // index within the word
long word = (bits[i] << (63-subIndex)); // skip all the bits to
the left of index
-Yonik
http://www.lucidimagination.com
On Fri, Jun 24, 2011 at 11:33 AM, Robert Muir wrote:
> And -Xint and -client
>
> On Fri, Jun 24, 2011 at 11:32 AM, Uwe Schindler wrote:
>> The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with
>> BitUtils.nlz(word).
>>
>> So this is really strange. Also happens with -Xbatch.
>>
>> -
>> Uwe Schindler
>> H.-H.-Meier-Allee 63, D-28213 Bremen
>> http://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>>
>>> -Original Message-
>>> From: Uwe Schindler [mailto:u...@thetaphi.de]
>>> Sent: Friday, June 24, 2011 5:20 PM
>>> To: dev@lucene.apache.org
>>> Subject: RE: [VOTE] release 3.3
>>>
>>> I assume the problem is the intrinsic, I will replace by the own hacker's
>>> delight impl (like we do everywhere else in OpenBitSet, why did we use the
>>> platform method here?) and try again
>>>
>>> Uwe
>>>
>>> -
>>> Uwe Schindler
>>> H.-H.-Meier-Allee 63, D-28213 Bremen
>>> http://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>>
>>>
>>> > -Original Message-
>>> > From: Robert Muir [mailto:rcm...@gmail.com]
>>> > Sent: Friday, June 24, 2011 5:07 PM
>>> > To: dev@lucene.apache.org
>>> > Subject: Re: [VOTE] release 3.3
>>> >
>>> > Just some more info: i took away the seed and used -Dtests.iter=100 on
>>> > this
>>> > test:
>>> >
>>> > JAVA5:
>>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>>> > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed:
>>> > 21.793 sec
>>> >
>>> > JAVA6:
>>> > junit-sequential:
>>> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet
>>> > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed:
>>> > 19.719 sec
>>> >
>>> > so this test fails 23% of the time on java5.
>>> >
>>> > The reason we never caught it, is that java5 is unmaintained and we
>>> > cannot even test it in hudson... aka we cannot support this monster
>>> anymore
>>> >
>>> > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir wrote:
>>> > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler
>>> > wrote:
>>> > >> The OpenBitSet test is in all cases serious (vs. the skiplist test
>>> > >> is a test bug,
>>> > that true).
>>> > >>
>>> > >> The AIOOBE is caused inside OpenBitSet and that should never ever
>>> > happen, even if you use it incorrectly!
>>> > >
>>> > > Its not clear that its that serious, it only fails with java 5 for
>>> > > me (not java 6) :)
>>> > >
>>> > > Looks like a bug in java 5...
>>> > >
>>> >
>>> > -
>>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
>>> > additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
>>> commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
Here the patch to fix the test bug, it's really a test bug - found thanks to Java 5. It was even wrong to use length(), correct would be size() for both and only use the minimum of both as allocation strategy may not be equal. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, June 24, 2011 6:06 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] release 3.3 > > OK, the bug is not a Java 5 bug, its just a different behavior in the BitSet > impl > between java 5 and java 6. > > Java 5's BitSet impl allocates for new BitSet(0) always at least one word, so > size() differs from OpenBitSet. This makes the test fail. > > The fix is to code the test correctly by using Math.min(BitSet.length(), > OpenBitSet.size()) as upper limit and not assume the allocation strategy of > both bitsets is identical. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Uwe Schindler [mailto:u...@thetaphi.de] > > Sent: Friday, June 24, 2011 5:33 PM > > To: dev@lucene.apache.org > > Subject: RE: [VOTE] release 3.3 > > > > The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) > > with BitUtils.nlz(word). > > > > So this is really strange. Also happens with -Xbatch. > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > > -Original Message- > > > From: Uwe Schindler [mailto:u...@thetaphi.de] > > > Sent: Friday, June 24, 2011 5:20 PM > > > To: dev@lucene.apache.org > > > Subject: RE: [VOTE] release 3.3 > > > > > > I assume the problem is the intrinsic, I will replace by the own > > > hacker's delight impl (like we do everywhere else in OpenBitSet, why > > > did we use the platform method here?) and try again > > > > > > Uwe > > > > > > - > > > Uwe Schindler > > > H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de > > > eMail: u...@thetaphi.de > > > > > > > > > > -Original Message- > > > > From: Robert Muir [mailto:rcm...@gmail.com] > > > > Sent: Friday, June 24, 2011 5:07 PM > > > > To: dev@lucene.apache.org > > > > Subject: Re: [VOTE] release 3.3 > > > > > > > > Just some more info: i took away the seed and used -Dtests.iter=100 > > > > on this > > > > test: > > > > > > > > JAVA5: > > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > > > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: > > > > 21.793 sec > > > > > > > > JAVA6: > > > > junit-sequential: > > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > > > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: > > > > 19.719 sec > > > > > > > > so this test fails 23% of the time on java5. > > > > > > > > The reason we never caught it, is that java5 is unmaintained and we > > > > cannot even test it in hudson... aka we cannot support this monster > > > anymore > > > > > > > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir > > wrote: > > > > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler > > > > wrote: > > > > >> The OpenBitSet test is in all cases serious (vs. the skiplist > > > > >> test is a test bug, > > > > that true). > > > > >> > > > > >> The AIOOBE is caused inside OpenBitSet and that should never ever > > > > happen, even if you use it incorrectly! > > > > > > > > > > Its not clear that its that serious, it only fails with java 5 for > > > > > me (not java 6) :) > > > > > > > > > > Looks like a bug in java 5... > > > > > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > > commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org TestOpenBitSet.patch Description: Binary data - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
OK, the bug is not a Java 5 bug, its just a different behavior in the BitSet impl between java 5 and java 6. Java 5's BitSet impl allocates for new BitSet(0) always at least one word, so size() differs from OpenBitSet. This makes the test fail. The fix is to code the test correctly by using Math.min(BitSet.length(), OpenBitSet.size()) as upper limit and not assume the allocation strategy of both bitsets is identical. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, June 24, 2011 5:33 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] release 3.3 > > The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with > BitUtils.nlz(word). > > So this is really strange. Also happens with -Xbatch. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Uwe Schindler [mailto:u...@thetaphi.de] > > Sent: Friday, June 24, 2011 5:20 PM > > To: dev@lucene.apache.org > > Subject: RE: [VOTE] release 3.3 > > > > I assume the problem is the intrinsic, I will replace by the own > > hacker's delight impl (like we do everywhere else in OpenBitSet, why > > did we use the platform method here?) and try again > > > > Uwe > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > > > -Original Message- > > > From: Robert Muir [mailto:rcm...@gmail.com] > > > Sent: Friday, June 24, 2011 5:07 PM > > > To: dev@lucene.apache.org > > > Subject: Re: [VOTE] release 3.3 > > > > > > Just some more info: i took away the seed and used -Dtests.iter=100 > > > on this > > > test: > > > > > > JAVA5: > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: > > > 21.793 sec > > > > > > JAVA6: > > > junit-sequential: > > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: > > > 19.719 sec > > > > > > so this test fails 23% of the time on java5. > > > > > > The reason we never caught it, is that java5 is unmaintained and we > > > cannot even test it in hudson... aka we cannot support this monster > > anymore > > > > > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir > wrote: > > > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler > > > wrote: > > > >> The OpenBitSet test is in all cases serious (vs. the skiplist > > > >> test is a test bug, > > > that true). > > > >> > > > >> The AIOOBE is caused inside OpenBitSet and that should never ever > > > happen, even if you use it incorrectly! > > > > > > > > Its not clear that its that serious, it only fails with java 5 for > > > > me (not java 6) :) > > > > > > > > Looks like a bug in java 5... > > > > > > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
And -Xint and -client On Fri, Jun 24, 2011 at 11:32 AM, Uwe Schindler wrote: > The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with > BitUtils.nlz(word). > > So this is really strange. Also happens with -Xbatch. > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: Uwe Schindler [mailto:u...@thetaphi.de] >> Sent: Friday, June 24, 2011 5:20 PM >> To: dev@lucene.apache.org >> Subject: RE: [VOTE] release 3.3 >> >> I assume the problem is the intrinsic, I will replace by the own hacker's >> delight impl (like we do everywhere else in OpenBitSet, why did we use the >> platform method here?) and try again >> >> Uwe >> >> - >> Uwe Schindler >> H.-H.-Meier-Allee 63, D-28213 Bremen >> http://www.thetaphi.de >> eMail: u...@thetaphi.de >> >> >> > -----Original Message- >> > From: Robert Muir [mailto:rcm...@gmail.com] >> > Sent: Friday, June 24, 2011 5:07 PM >> > To: dev@lucene.apache.org >> > Subject: Re: [VOTE] release 3.3 >> > >> > Just some more info: i took away the seed and used -Dtests.iter=100 on >> > this >> > test: >> > >> > JAVA5: >> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet >> > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: >> > 21.793 sec >> > >> > JAVA6: >> > junit-sequential: >> > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet >> > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: >> > 19.719 sec >> > >> > so this test fails 23% of the time on java5. >> > >> > The reason we never caught it, is that java5 is unmaintained and we >> > cannot even test it in hudson... aka we cannot support this monster >> anymore >> > >> > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir wrote: >> > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler >> > wrote: >> > >> The OpenBitSet test is in all cases serious (vs. the skiplist test >> > >> is a test bug, >> > that true). >> > >> >> > >> The AIOOBE is caused inside OpenBitSet and that should never ever >> > happen, even if you use it incorrectly! >> > > >> > > Its not clear that its that serious, it only fails with java 5 for >> > > me (not java 6) :) >> > > >> > > Looks like a bug in java 5... >> > > >> > >> > - >> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For >> > additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
The bug is *not* fixed by replacing Long.numberOfLeadingZeros(word) with BitUtils.nlz(word). So this is really strange. Also happens with -Xbatch. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, June 24, 2011 5:20 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] release 3.3 > > I assume the problem is the intrinsic, I will replace by the own hacker's > delight impl (like we do everywhere else in OpenBitSet, why did we use the > platform method here?) and try again > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Robert Muir [mailto:rcm...@gmail.com] > > Sent: Friday, June 24, 2011 5:07 PM > > To: dev@lucene.apache.org > > Subject: Re: [VOTE] release 3.3 > > > > Just some more info: i took away the seed and used -Dtests.iter=100 on > > this > > test: > > > > JAVA5: > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: > > 21.793 sec > > > > JAVA6: > > junit-sequential: > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: > > 19.719 sec > > > > so this test fails 23% of the time on java5. > > > > The reason we never caught it, is that java5 is unmaintained and we > > cannot even test it in hudson... aka we cannot support this monster > anymore > > > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir wrote: > > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler > > wrote: > > >> The OpenBitSet test is in all cases serious (vs. the skiplist test > > >> is a test bug, > > that true). > > >> > > >> The AIOOBE is caused inside OpenBitSet and that should never ever > > happen, even if you use it incorrectly! > > > > > > Its not clear that its that serious, it only fails with java 5 for > > > me (not java 6) :) > > > > > > Looks like a bug in java 5... > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 10:43 AM, Uwe Schindler wrote:
>
> So this release candidate is in my opinion broken! -1 to release.
>
just to respond, thank you for running all these tests however,
The multilevelskiplist thing is a test bug, the tests do not all
guarantee to support iter > 1,
this is an unsupported option for developers to easily 'beast' tests
but its not required.
However, for this test I fixed this by resetting its static counter:
+ public void setUp() throws Exception {
+super.setUp();
+PayloadFilter.count = 0;
+ }
The openbitset thing, is a bug in java 5... and this is not supported.
So I strongly disagree that the release candidate is broken!
Seems like the only thing broken is java5!
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
I assume the problem is the intrinsic, I will replace by the own hacker's delight impl (like we do everywhere else in OpenBitSet, why did we use the platform method here?) and try again Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Friday, June 24, 2011 5:07 PM > To: dev@lucene.apache.org > Subject: Re: [VOTE] release 3.3 > > Just some more info: i took away the seed and used -Dtests.iter=100 on this > test: > > JAVA5: > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: 21.793 sec > > JAVA6: > junit-sequential: > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: 19.719 sec > > so this test fails 23% of the time on java5. > > The reason we never caught it, is that java5 is unmaintained and we cannot > even test it in hudson... aka we cannot support this monster anymore > > On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir wrote: > > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler > wrote: > >> The OpenBitSet test is in all cases serious (vs. the skiplist test is a > >> test bug, > that true). > >> > >> The AIOOBE is caused inside OpenBitSet and that should never ever > happen, even if you use it incorrectly! > > > > Its not clear that its that serious, it only fails with java 5 for me > > (not java 6) :) > > > > Looks like a bug in java 5... > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional > commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
Just some more info: i took away the seed and used -Dtests.iter=100 on this test: JAVA5: [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet [junit] Tests run: 400, Failures: 0, Errors: 23, Time elapsed: 21.793 sec JAVA6: junit-sequential: [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet [junit] Tests run: 400, Failures: 0, Errors: 0, Time elapsed: 19.719 sec so this test fails 23% of the time on java5. The reason we never caught it, is that java5 is unmaintained and we cannot even test it in hudson... aka we cannot support this monster anymore On Fri, Jun 24, 2011 at 11:02 AM, Robert Muir wrote: > On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler wrote: >> The OpenBitSet test is in all cases serious (vs. the skiplist test is a test >> bug, that true). >> >> The AIOOBE is caused inside OpenBitSet and that should never ever happen, >> even if you use it incorrectly! > > Its not clear that its that serious, it only fails with java 5 for me > (not java 6) :) > > Looks like a bug in java 5... > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 10:54 AM, Uwe Schindler wrote: > The OpenBitSet test is in all cases serious (vs. the skiplist test is a test > bug, that true). > > The AIOOBE is caused inside OpenBitSet and that should never ever happen, > even if you use it incorrectly! Its not clear that its that serious, it only fails with java 5 for me (not java 6) :) Looks like a bug in java 5... - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
The OpenBitSet test is in all cases serious (vs. the skiplist test is a test bug, that true). The AIOOBE is caused inside OpenBitSet and that should never ever happen, even if you use it incorrectly! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Friday, June 24, 2011 4:47 PM > To: dev@lucene.apache.org > Subject: Re: [VOTE] release 3.3 > > This might be the cause of the test failures in the skiplist (I will > investigate!). > > In general, not all tests are guaranteed to work correctly with tests.iter > > 1, > some tests have bugs! > > On Fri, Jun 24, 2011 at 10:45 AM, Uwe Schindler wrote: > > I forgot to mention, all tests of core were running 95 minutes using - > Dtests.multiplier=100 and -Dtests.iter=100 ! > > > > - > > Uwe Schindler > > H.-H.-Meier-Allee 63, D-28213 Bremen > > http://www.thetaphi.de > > eMail: u...@thetaphi.de > > > > > >> -Original Message- > >> From: Uwe Schindler [mailto:u...@thetaphi.de] > >> Sent: Friday, June 24, 2011 4:44 PM > >> To: dev@lucene.apache.org > >> Subject: RE: [VOTE] release 3.3 > >> iter > >> Hi, > >> > >> I run some smoke tests yesterday on the Lucene 2.9/3.0 release > >> machine I used. The machine runs Java 1.5.0_22, Solaris x64, Opteron > >> 16 cores. One of the tests was already fixed by Robert (I told him > >> yesterday because it was always failing). > >> > >> The others are maybe serious, maybe not: > >> > >> [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList > >> [junit] Testcase: > >> testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): > >> FAILED > >> [junit] Wrong payload for the target 14: -106 expected:<14> but > >> was:<- > >> 106> > >> [junit] junit.framework.AssertionFailedError: Wrong payload for > >> the target > >> 14: -106 expected:<14> but was:<-106> > >> [junit] at > >> org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiL > >> evel > >> SkipList.java:87) > >> [junit] at > >> org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMul > >> tiLev > >> elSkipList.java:66) > >> [junit] at > >> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L > >> uc > >> eneTestCase.java:1272) > >> [junit] at > >> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L > >> uc > >> eneTestCase.java:1190) > >> > >> ...( 100 repetitions of same stack trace) and then about 100 times > >> with different seeds: > >> > >> [junit] NOTE: reproduce with: ant test > >> -Dtestcase=TestMultiLevelSkipList - Dtestmethod=testSimpleSkip - > >> Dtests.seed=2861480580591035682:880958701285368932 > >> > >> But it's not reproduceable, so maybe its only the repetition causing this! > >> > >> This one is very serious and easy to reproduce with every printed seed: > >> > >> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > >> [junit] Testcase: > >> testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an > >> ERROR > >> [junit] -1 > >> [junit] java.lang.ArrayIndexOutOfBoundsException: -1 > >> [junit] at > >> org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671) > >> [junit] at > >> org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.jav > >> a:53 > >> ) > >> [junit] at > >> > org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java: > >> 148) > >> [junit] at > >> org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:1 > >> 92) > >> [junit] at > >> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L > >> uc > >> eneTestCase.java:1272) > >> [junit] at > >> > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(L > >> uc > >> eneTestCase.java:1190) > >> [junit] > >> [junit] > >> [junit] Testcase: > >> testSmall(org.apache.lucene.util.TestOpenBitSet): Caused an > >> ERROR > >> [junit] (null) > >> [junit] java.l
Re: [VOTE] release 3.3
This might be the cause of the test failures in the skiplist (I will investigate!). In general, not all tests are guaranteed to work correctly with tests.iter > 1, some tests have bugs! On Fri, Jun 24, 2011 at 10:45 AM, Uwe Schindler wrote: > I forgot to mention, all tests of core were running 95 minutes using > -Dtests.multiplier=100 and -Dtests.iter=100 ! > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -Original Message- >> From: Uwe Schindler [mailto:u...@thetaphi.de] >> Sent: Friday, June 24, 2011 4:44 PM >> To: dev@lucene.apache.org >> Subject: RE: [VOTE] release 3.3 >> iter >> Hi, >> >> I run some smoke tests yesterday on the Lucene 2.9/3.0 release machine I >> used. The machine runs Java 1.5.0_22, Solaris x64, Opteron 16 cores. One of >> the tests was already fixed by Robert (I told him yesterday because it was >> always failing). >> >> The others are maybe serious, maybe not: >> >> [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList >> [junit] Testcase: >> testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): FAILED >> [junit] Wrong payload for the target 14: -106 expected:<14> but was:<- >> 106> >> [junit] junit.framework.AssertionFailedError: Wrong payload for the >> target >> 14: -106 expected:<14> but was:<-106> >> [junit] at >> org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiLevel >> SkipList.java:87) >> [junit] at >> org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMultiLev >> elSkipList.java:66) >> [junit] at >> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc >> eneTestCase.java:1272) >> [junit] at >> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc >> eneTestCase.java:1190) >> >> ...( 100 repetitions of same stack trace) and then about 100 times with >> different seeds: >> >> [junit] NOTE: reproduce with: ant test -Dtestcase=TestMultiLevelSkipList >> - >> Dtestmethod=testSimpleSkip - >> Dtests.seed=2861480580591035682:880958701285368932 >> >> But it's not reproduceable, so maybe its only the repetition causing this! >> >> This one is very serious and easy to reproduce with every printed seed: >> >> [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet >> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): >> Caused >> an ERROR >> [junit] -1 >> [junit] java.lang.ArrayIndexOutOfBoundsException: -1 >> [junit] at >> org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671) >> [junit] at >> org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.java:53 >> ) >> [junit] at >> org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java: >> 148) >> [junit] at >> org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:192) >> [junit] at >> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc >> eneTestCase.java:1272) >> [junit] at >> org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc >> eneTestCase.java:1190) >> [junit] >> [junit] >> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): >> Caused >> an ERROR >> [junit] (null) >> [junit] java.lang.ArrayIndexOutOfBoundsException >> [junit] >> [junit] >> [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): >> Caused >> an ERROR >> [junit] (null) >> [junit] java.lang.ArrayIndexOutOfBoundsException >> [junit] >> [junit] >> >> ... following lots of times the (null) AIOOBE message... >> >> [junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet - >> Dtestmethod=testSmall -Dtests.seed=- >> 4526826707499307278:4139930264431857886 >> >> Again with different seeds. But not all 100 repetitions fail, so the ones >> mentioned should fail, but reproduceible. >> >> >> The good news: PANGAEA index works fine, no readVInt hotspot problems >> with Java 6! Thanks Robert for fixing in 3.1, but after changes in MMap they >> could have reappeared. >> >> So this release candidate is in my opinion broken! -1 to release. >> >> Uwe >> >> - >
RE: [VOTE] release 3.3
I forgot to mention, all tests of core were running 95 minutes using -Dtests.multiplier=100 and -Dtests.iter=100 ! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Uwe Schindler [mailto:u...@thetaphi.de] > Sent: Friday, June 24, 2011 4:44 PM > To: dev@lucene.apache.org > Subject: RE: [VOTE] release 3.3 > iter > Hi, > > I run some smoke tests yesterday on the Lucene 2.9/3.0 release machine I > used. The machine runs Java 1.5.0_22, Solaris x64, Opteron 16 cores. One of > the tests was already fixed by Robert (I told him yesterday because it was > always failing). > > The others are maybe serious, maybe not: > > [junit] Testsuite: org.apache.lucene.index.TestMultiLevelSkipList > [junit] Testcase: > testSimpleSkip(org.apache.lucene.index.TestMultiLevelSkipList): FAILED > [junit] Wrong payload for the target 14: -106 expected:<14> but was:<- > 106> > [junit] junit.framework.AssertionFailedError: Wrong payload for the target > 14: -106 expected:<14> but was:<-106> > [junit] at > org.apache.lucene.index.TestMultiLevelSkipList.checkSkipTo(TestMultiLevel > SkipList.java:87) > [junit] at > org.apache.lucene.index.TestMultiLevelSkipList.testSimpleSkip(TestMultiLev > elSkipList.java:66) > [junit] at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1272) > [junit] at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1190) > > ...( 100 repetitions of same stack trace) and then about 100 times with > different seeds: > > [junit] NOTE: reproduce with: ant test -Dtestcase=TestMultiLevelSkipList - > Dtestmethod=testSimpleSkip - > Dtests.seed=2861480580591035682:880958701285368932 > > But it's not reproduceable, so maybe its only the repetition causing this! > > This one is very serious and easy to reproduce with every printed seed: > > [junit] Testsuite: org.apache.lucene.util.TestOpenBitSet > [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): > Caused > an ERROR > [junit] -1 > [junit] java.lang.ArrayIndexOutOfBoundsException: -1 > [junit] at > org.apache.lucene.util.OpenBitSet.prevSetBit(OpenBitSet.java:671) > [junit] at > org.apache.lucene.util.TestOpenBitSet.doPrevSetBit(TestOpenBitSet.java:53 > ) > [junit] at > org.apache.lucene.util.TestOpenBitSet.doRandomSets(TestOpenBitSet.java: > 148) > [junit] at > org.apache.lucene.util.TestOpenBitSet.testSmall(TestOpenBitSet.java:192) > [junit] at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1272) > [junit] at > org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(Luc > eneTestCase.java:1190) > [junit] > [junit] > [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): > Caused > an ERROR > [junit] (null) > [junit] java.lang.ArrayIndexOutOfBoundsException > [junit] > [junit] > [junit] Testcase: testSmall(org.apache.lucene.util.TestOpenBitSet): > Caused > an ERROR > [junit] (null) > [junit] java.lang.ArrayIndexOutOfBoundsException > [junit] > [junit] > > ... following lots of times the (null) AIOOBE message... > > [junit] NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet - > Dtestmethod=testSmall -Dtests.seed=- > 4526826707499307278:4139930264431857886 > > Again with different seeds. But not all 100 repetitions fail, so the ones > mentioned should fail, but reproduceible. > > > The good news: PANGAEA index works fine, no readVInt hotspot problems > with Java 6! Thanks Robert for fixing in 3.1, but after changes in MMap they > could have reappeared. > > So this release candidate is in my opinion broken! -1 to release. > > Uwe > > - > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > > -Original Message- > > From: Robert Muir [mailto:rcm...@gmail.com] > > Sent: Thursday, June 23, 2011 10:18 PM > > To: dev@lucene.apache.org > > Subject: [VOTE] release 3.3 > > > > Artifacts here: > > > > http://s.apache.org/lusolr33rc0 > > > > working release notes here: > > > > http://wiki.apache.org/lucene-java/ReleaseNote33 > > http://wiki.apache.org/solr/ReleaseNote33 > > > > I ran the automated release test script in trunk/dev- > > tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top level > > 50 times on windows. > > Here is my +1 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For > > additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
+1 I built PyLucene from the Lucene 3.3 sources, fixed a bug due to FieldComparator becoming generic and all tests passed. Andi.. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 1:48 AM, Robert Muir wrote: > Artifacts here: > > http://s.apache.org/lusolr33rc0 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > Thanks for leading this release Robert. I compared SolrJ's pom.xml with past releases and I noticed that since v3.1.0, SolrJ has a dependency on lucene-core. I'm not sure why SolrJ needs that dependency. Also in v3.1, SolrJ had a test dependency on solr-test-framework but it was removed in v3.2. I have been missing from the action since Solr v1.4 so I'm not sure if those changes were intentional or mistakes. -- Regards, Shalin Shekhar Mangar.
Re: [VOTE] release 3.3
On Fri, Jun 24, 2011 at 2:15 AM, Steven A Rowe wrote: > +1 > > I did the following: > > - compared the Solr & Lucene binary .zip and .tgz archives' contents for any > differences (other than line endings) > - skimmed Changes.html for generation problems > - looked at random pages from each module's javadocs > - ran the Lucene demo, indexed and searched > - ran the Solr example server, indexed and searched > - eyeballed all modules' Maven artifacts & sanity checked their POMs > - ran all tests from the Solr & Lucene source tarballs, separately > Thanks Steven, these look like good checks, and I think as much as possible it would be great if we can add any of these to the 'smokeTestRelease.py' script in dev-tools/scripts (e.g. startup solr, index the example docs and do a search). I could also imagine sometime soon we might even want to have this release-tester testing nightly builds or something, so we catch problems continuously. > Two non-release-blocking nits: > > 1. In the Solr source tarball, solr/example/README.txt recommends using the > command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does > not have executable permissions. In the binary tarball, however, post.sh has > executable permissions. > > 2. I checked the source for references to older versions, and I found the > following; I think these just point to a missing item in the release todo > (post-branching), and should not block the release: > I took care of these: the deprecations are already nuked in trunk, and I don't think we achieve a ton by nuking them in a 3.x minor release. As far as the demo links, these were totally broken links, so i replaced them with a description of what the thing is doing (seems more useful) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
Ok, thanks Robert. This is a trivial correction. I didn't find log4j refs. anywhere under contrib/clustering (just to make sure), so I think it won't break anything. Dawid On Fri, Jun 24, 2011 at 9:03 AM, Robert Muir wrote: > there is no code freeze anywhere... in my opinion, if you find little > things to fix, just commit!!! (and backport also to > http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3/) > > I named the RC with the revision number, if we decide to go with it > anyway, we just use that rev for svn tagging. > But if lots of good things are found/fixed, then 'svn update' + 'ant > prepare-release' + sftp to create a second release candidate is no big > deal. > > On Fri, Jun 24, 2011 at 2:55 AM, Dawid Weiss > wrote: >> Is there a code freeze on 3x or can I apply SOLR-2620 to it? >> >> Dawid >> >> On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss >> wrote: >>> I checked the clustering contrib, went through the Solr example (on >>> ubuntu). One thing I noticed: >>> >>> - we have duplicated log4j*.jar in the distribution; the one in >>> clustering contrib is not needed, in fact, because we use slf4j for >>> logging anyway (and this one is picked from the war's WEB-INF/lib. >>> I'll file an issue to remove it. >>> >>> Dawid >>> >>> On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe wrote: >>>> +1 >>>> >>>> I did the following: >>>> >>>> - compared the Solr & Lucene binary .zip and .tgz archives' contents for >>>> any differences (other than line endings) >>>> - skimmed Changes.html for generation problems >>>> - looked at random pages from each module's javadocs >>>> - ran the Lucene demo, indexed and searched >>>> - ran the Solr example server, indexed and searched >>>> - eyeballed all modules' Maven artifacts & sanity checked their POMs >>>> - ran all tests from the Solr & Lucene source tarballs, separately >>>> >>>> Two non-release-blocking nits: >>>> >>>> 1. In the Solr source tarball, solr/example/README.txt recommends using >>>> the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh >>>> does not have executable permissions. In the binary tarball, however, >>>> post.sh has executable permissions. >>>> >>>> 2. I checked the source for references to older versions, and I found the >>>> following; I think these just point to a missing item in the release todo >>>> (post-branching), and should not block the release: >>>> >>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: >>>> @Deprecated // TODO remove in 3.2 (this is present twice in this file) >>>> >>>> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: >>>> /** @deprecated remove all this test mode code in lucene 3.2! */ >>>> >>>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: >>>> // TODO make this private in 3.1 (this is present twice in this file) >>>> >>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** >>>> Index all text files under a directory. See >>>> http://lucene.apache.org/java/3_1/demo.html. */ >>>> >>>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + >>>> "See http://lucene.apache.org/java/3_1/demo.html for details."; >>>> >>>> Steve >>>> >>>>> -Original Message- >>>>> From: Robert Muir [mailto:rcm...@gmail.com] >>>>> Sent: Thursday, June 23, 2011 4:18 PM >>>>> To: dev@lucene.apache.org >>>>> Subject: [VOTE] release 3.3 >>>>> >>>>> Artifacts here: >>>>> >>>>> http://s.apache.org/lusolr33rc0 >>>>> >>>>> working release notes here: >>>>> >>>>> http://wiki.apache.org/lucene-java/ReleaseNote33 >>>>> http://wiki.apache.org/solr/ReleaseNote33 >>>>> >>>>> I ran the automated release test script in >>>>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the >>>>> top level 50 times on windows. >>>>> Here is my +1 >>>> >>>> >>> >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
there is no code freeze anywhere... in my opinion, if you find little things to fix, just commit!!! (and backport also to http://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_3_3/) I named the RC with the revision number, if we decide to go with it anyway, we just use that rev for svn tagging. But if lots of good things are found/fixed, then 'svn update' + 'ant prepare-release' + sftp to create a second release candidate is no big deal. On Fri, Jun 24, 2011 at 2:55 AM, Dawid Weiss wrote: > Is there a code freeze on 3x or can I apply SOLR-2620 to it? > > Dawid > > On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss > wrote: >> I checked the clustering contrib, went through the Solr example (on >> ubuntu). One thing I noticed: >> >> - we have duplicated log4j*.jar in the distribution; the one in >> clustering contrib is not needed, in fact, because we use slf4j for >> logging anyway (and this one is picked from the war's WEB-INF/lib. >> I'll file an issue to remove it. >> >> Dawid >> >> On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe wrote: >>> +1 >>> >>> I did the following: >>> >>> - compared the Solr & Lucene binary .zip and .tgz archives' contents for >>> any differences (other than line endings) >>> - skimmed Changes.html for generation problems >>> - looked at random pages from each module's javadocs >>> - ran the Lucene demo, indexed and searched >>> - ran the Solr example server, indexed and searched >>> - eyeballed all modules' Maven artifacts & sanity checked their POMs >>> - ran all tests from the Solr & Lucene source tarballs, separately >>> >>> Two non-release-blocking nits: >>> >>> 1. In the Solr source tarball, solr/example/README.txt recommends using the >>> command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does >>> not have executable permissions. In the binary tarball, however, post.sh >>> has executable permissions. >>> >>> 2. I checked the source for references to older versions, and I found the >>> following; I think these just point to a missing item in the release todo >>> (post-branching), and should not block the release: >>> >>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: >>> @Deprecated // TODO remove in 3.2 (this is present twice in this file) >>> >>> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: >>> /** @deprecated remove all this test mode code in lucene 3.2! */ >>> >>> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: >>> // TODO make this private in 3.1 (this is present twice in this file) >>> >>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** >>> Index all text files under a directory. See >>> http://lucene.apache.org/java/3_1/demo.html. */ >>> >>> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + >>> "See http://lucene.apache.org/java/3_1/demo.html for details."; >>> >>> Steve >>> >>>> -Original Message- >>>> From: Robert Muir [mailto:rcm...@gmail.com] >>>> Sent: Thursday, June 23, 2011 4:18 PM >>>> To: dev@lucene.apache.org >>>> Subject: [VOTE] release 3.3 >>>> >>>> Artifacts here: >>>> >>>> http://s.apache.org/lusolr33rc0 >>>> >>>> working release notes here: >>>> >>>> http://wiki.apache.org/lucene-java/ReleaseNote33 >>>> http://wiki.apache.org/solr/ReleaseNote33 >>>> >>>> I ran the automated release test script in >>>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the >>>> top level 50 times on windows. >>>> Here is my +1 >>> >>> >> > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
Is there a code freeze on 3x or can I apply SOLR-2620 to it? Dawid On Fri, Jun 24, 2011 at 8:51 AM, Dawid Weiss wrote: > I checked the clustering contrib, went through the Solr example (on > ubuntu). One thing I noticed: > > - we have duplicated log4j*.jar in the distribution; the one in > clustering contrib is not needed, in fact, because we use slf4j for > logging anyway (and this one is picked from the war's WEB-INF/lib. > I'll file an issue to remove it. > > Dawid > > On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe wrote: >> +1 >> >> I did the following: >> >> - compared the Solr & Lucene binary .zip and .tgz archives' contents for any >> differences (other than line endings) >> - skimmed Changes.html for generation problems >> - looked at random pages from each module's javadocs >> - ran the Lucene demo, indexed and searched >> - ran the Solr example server, indexed and searched >> - eyeballed all modules' Maven artifacts & sanity checked their POMs >> - ran all tests from the Solr & Lucene source tarballs, separately >> >> Two non-release-blocking nits: >> >> 1. In the Solr source tarball, solr/example/README.txt recommends using the >> command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does >> not have executable permissions. In the binary tarball, however, post.sh >> has executable permissions. >> >> 2. I checked the source for references to older versions, and I found the >> following; I think these just point to a missing item in the release todo >> (post-branching), and should not block the release: >> >> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: >> @Deprecated // TODO remove in 3.2 (this is present twice in this file) >> >> ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: >> /** @deprecated remove all this test mode code in lucene 3.2! */ >> >> ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: >> // TODO make this private in 3.1 (this is present twice in this file) >> >> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** >> Index all text files under a directory. See >> http://lucene.apache.org/java/3_1/demo.html. */ >> >> ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + >> "See http://lucene.apache.org/java/3_1/demo.html for details."; >> >> Steve >> >>> -Original Message- >>> From: Robert Muir [mailto:rcm...@gmail.com] >>> Sent: Thursday, June 23, 2011 4:18 PM >>> To: dev@lucene.apache.org >>> Subject: [VOTE] release 3.3 >>> >>> Artifacts here: >>> >>> http://s.apache.org/lusolr33rc0 >>> >>> working release notes here: >>> >>> http://wiki.apache.org/lucene-java/ReleaseNote33 >>> http://wiki.apache.org/solr/ReleaseNote33 >>> >>> I ran the automated release test script in >>> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the >>> top level 50 times on windows. >>> Here is my +1 >> >> > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] release 3.3
I checked the clustering contrib, went through the Solr example (on ubuntu). One thing I noticed: - we have duplicated log4j*.jar in the distribution; the one in clustering contrib is not needed, in fact, because we use slf4j for logging anyway (and this one is picked from the war's WEB-INF/lib. I'll file an issue to remove it. Dawid On Fri, Jun 24, 2011 at 8:15 AM, Steven A Rowe wrote: > +1 > > I did the following: > > - compared the Solr & Lucene binary .zip and .tgz archives' contents for any > differences (other than line endings) > - skimmed Changes.html for generation problems > - looked at random pages from each module's javadocs > - ran the Lucene demo, indexed and searched > - ran the Solr example server, indexed and searched > - eyeballed all modules' Maven artifacts & sanity checked their POMs > - ran all tests from the Solr & Lucene source tarballs, separately > > Two non-release-blocking nits: > > 1. In the Solr source tarball, solr/example/README.txt recommends using the > command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does > not have executable permissions. In the binary tarball, however, post.sh has > executable permissions. > > 2. I checked the source for references to older versions, and I found the > following; I think these just point to a missing item in the release todo > (post-branching), and should not block the release: > > ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: > @Deprecated // TODO remove in 3.2 (this is present twice in this file) > > ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** > @deprecated remove all this test mode code in lucene 3.2! */ > > ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: > // TODO make this private in 3.1 (this is present twice in this file) > > ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** > Index all text files under a directory. See > http://lucene.apache.org/java/3_1/demo.html. */ > > ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See > http://lucene.apache.org/java/3_1/demo.html for details."; > > Steve > >> -Original Message- >> From: Robert Muir [mailto:rcm...@gmail.com] >> Sent: Thursday, June 23, 2011 4:18 PM >> To: dev@lucene.apache.org >> Subject: [VOTE] release 3.3 >> >> Artifacts here: >> >> http://s.apache.org/lusolr33rc0 >> >> working release notes here: >> >> http://wiki.apache.org/lucene-java/ReleaseNote33 >> http://wiki.apache.org/solr/ReleaseNote33 >> >> I ran the automated release test script in >> trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the >> top level 50 times on windows. >> Here is my +1 > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] release 3.3
+1 I did the following: - compared the Solr & Lucene binary .zip and .tgz archives' contents for any differences (other than line endings) - skimmed Changes.html for generation problems - looked at random pages from each module's javadocs - ran the Lucene demo, indexed and searched - ran the Solr example server, indexed and searched - eyeballed all modules' Maven artifacts & sanity checked their POMs - ran all tests from the Solr & Lucene source tarballs, separately Two non-release-blocking nits: 1. In the Solr source tarball, solr/example/README.txt recommends using the command "./post.sh *.xml" from solr/example/exampledocs/, but post.sh does not have executable permissions. In the binary tarball, however, post.sh has executable permissions. 2. I checked the source for references to older versions, and I found the following; I think these just point to a missing item in the release todo (post-branching), and should not block the release: ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/fr/FrenchStemFilter.java: @Deprecated // TODO remove in 3.2 (this is present twice in this file) ./lucene/src/java/org/apache/lucene/index/ConcurrentMergeScheduler.java: /** @deprecated remove all this test mode code in lucene 3.2! */ ./lucene/contrib/analyzers/common/src/java/org/apache/lucene/analysis/br/BrazilianAnalyzer.java: // TODO make this private in 3.1 (this is present twice in this file) ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java:/** Index all text files under a directory. See http://lucene.apache.org/java/3_1/demo.html. */ ./lucene/contrib/demo/src/java/org/apache/lucene/demo/IndexFiles.java: + "See http://lucene.apache.org/java/3_1/demo.html for details."; Steve > -Original Message- > From: Robert Muir [mailto:rcm...@gmail.com] > Sent: Thursday, June 23, 2011 4:18 PM > To: dev@lucene.apache.org > Subject: [VOTE] release 3.3 > > Artifacts here: > > http://s.apache.org/lusolr33rc0 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > I ran the automated release test script in > trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the > top level 50 times on windows. > Here is my +1
Re: [VOTE] release 3.3
+1 Tommaso 2011/6/23 Robert Muir > Artifacts here: > > http://s.apache.org/lusolr33rc0 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > I ran the automated release test script in > trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the > top level 50 times on windows. > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: [VOTE] release 3.3
+1 Thanks for pulling the release together Robert. On Fri, Jun 24, 2011 at 9:33 AM, Michael McCandless < luc...@mikemccandless.com> wrote: > +1 > > Smoke testing passed for me, except for the Java 1.5 only hang in > TestDoubleBarrelLRUCache (LUCENE-3235) but I don't think that should > block the release. > > Mike McCandless > > http://blog.mikemccandless.com > > On Thu, Jun 23, 2011 at 4:18 PM, Robert Muir wrote: > > Artifacts here: > > > > http://s.apache.org/lusolr33rc0 > > > > working release notes here: > > > > http://wiki.apache.org/lucene-java/ReleaseNote33 > > http://wiki.apache.org/solr/ReleaseNote33 > > > > I ran the automated release test script in > > trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the > > top level 50 times on windows. > > Here is my +1 > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > > For additional commands, e-mail: dev-h...@lucene.apache.org > > > > > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Chris Male | Software Developer | JTeam BV.| www.jteam.nl
Re: [VOTE] release 3.3
+1 Smoke testing passed for me, except for the Java 1.5 only hang in TestDoubleBarrelLRUCache (LUCENE-3235) but I don't think that should block the release. Mike McCandless http://blog.mikemccandless.com On Thu, Jun 23, 2011 at 4:18 PM, Robert Muir wrote: > Artifacts here: > > http://s.apache.org/lusolr33rc0 > > working release notes here: > > http://wiki.apache.org/lucene-java/ReleaseNote33 > http://wiki.apache.org/solr/ReleaseNote33 > > I ran the automated release test script in > trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the > top level 50 times on windows. > Here is my +1 > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] release 3.3
Artifacts here: http://s.apache.org/lusolr33rc0 working release notes here: http://wiki.apache.org/lucene-java/ReleaseNote33 http://wiki.apache.org/solr/ReleaseNote33 I ran the automated release test script in trunk/dev-tools/scripts/smokeTestRelease.py, and ran 'ant test' at the top level 50 times on windows. Here is my +1 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
