Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Ignacio Vera]

I have spoken to Adrien offline and I have included LUCENE-90555 which
includes a fix where shape line queries would fail detecting crossing
through edge points.

Thanks Adrien.

On Thu, Dec 19, 2019 at 6:24 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Since there was a re-spin, I added SOLR-14108 to the release branch.
> It is a very minor fix (null check), but solves an important annoyance
> that Erik Hatcher reported while trying to use the package manager.
>
> On Thu, Dec 19, 2019 at 3:31 AM Noble Paul  wrote:
> >
> > I'v ported the commit
> > https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=221d4ed
> >
> > On Thu, Dec 19, 2019 at 8:59 AM Noble Paul  wrote:
> > >
> > > Thanks Adrien.
> > > My apologies for the inconvenience .
> > >
> > > --Noble
> > >
> > > On Thu, Dec 19, 2019 at 8:04 AM Adrien Grand 
> wrote:
> > > >
> > > > Thanks Cassandra for finding this missing commit. I'll start a new
> RC tomorrow morning EU time.
> > > >
> > > > On Wed, Dec 18, 2019 at 9:21 PM Alexandre Rafalovitch <
> arafa...@gmail.com> wrote:
> > > >>
> > > >> If there is a respin, maybe the Changenotes (for Solr) can be fixed
> too:
> > > >> 1) First entry under Upgrade Notes is missing JIRA and probably does
> > > >> not need to include the full class path
> > > >> 2) Optimization section can probably be skipped as it just has "no
> > > >> changes" entry
> > > >> 3) Couple of JIRAs are missing contributor attributions (is it
> > > >> compulsory? I don't know.)
> > > >>
> > > >> Also Lucene's one under "build" section is missing one JIRA number.
> > > >>
> > > >> Regards,
> > > >>Alex.
> > > >>
> > > >> On Wed, 18 Dec 2019 at 14:20, Noble Paul 
> wrote:
> > > >> >
> > > >> > I'm so sorry to come at this moment and tell you that one of the
> > > >> > critical bug fixes I made to master was not ported to 8x and 8.4.
> > > >> >
> > > >> > This breaks a critical functionality of package loading feature.
> > > >> > Is it possible to do a respin?
> > > >> >
> https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
> > > >> >
> > > >> >
> > > >> > On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand 
> wrote:
> > > >> > >
> > > >> > > Hi Gus,
> > > >> > >
> > > >> > > If the test is flaky, would you mind annotating it with
> "@BadApple"? It will make sure this test doesn't get in the way of building
> or voting on a release until the test is fixed.
> > > >> > >
> > > >> > > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck 
> wrote:
> > > >> > >>
> > > >> > >> Hi Mkhail, This is a known flakey test (mine, it's on my to do
> list). Seems to have got slightly more flakey recently possibly because
> other tests have got better at using up CPU?. The flake here is that the
> code in the test didn't manage to wait long enough before running the
> assertion. This failure does not represent an issue with anything other
> than the test.
> > > >> > >>
> > > >> > >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev <
> m...@apache.org> wrote:
> > > >> > >>>
> > > >> > >>> I've got
> > > >> > >>>
> > > >> > >>>   2> NOTE: reproduce with: ant test
> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest
> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B
> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> > > >> > >>>
> > > >> > >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > > >> > >>>
> > > >> > >>> [00:42:59.083] FAILURE 29.4s J1 |
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> > > >> > >>>
> > > >> > >>>> Throwable #1: java.lang.AssertionError: expected:<10>
> but was:<9>
> > > >> > >>>
> > > >> > >>>>at
> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> > > >> > >>>
> > > >> > >>>>at org.junit.Assert.fail(Assert.java:88)
> > > >> > >>>
> > > >> > >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
> > > >> > >>>
> > > >> > >>>>at org.junit.Assert.assertEquals(Assert.java:645)
> > > >> > >>>
> > > >> > >>>>at org.junit.Assert.assertEquals(Assert.java:631)
> > > >> > >>>
> > > >> > >>>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> > > >> > >>>
> > > >> > >>>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> > > >> > >>>
> > > >> > >>>
> > > >> > >>> which didn't reproduce to me when I retry.
> > > >> > >>>
> > > >> > >>> +0
> > > >> > >>>
> > > >> > >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand <
> jpou...@gmail.com> wrote:
> > > >> > 
> > > >> >  Please vote for release candidate 1 for Lucene/Solr 8.4.0
> > > >> > 
> > > >> >  The artifacts can be downloaded from:
> > > >> > 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > > >> > 
> 

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Ishan Chattopadhyaya]

Since there was a re-spin, I added SOLR-14108 to the release branch.
It is a very minor fix (null check), but solves an important annoyance
that Erik Hatcher reported while trying to use the package manager.

On Thu, Dec 19, 2019 at 3:31 AM Noble Paul  wrote:
>
> I'v ported the commit
> https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=221d4ed
>
> On Thu, Dec 19, 2019 at 8:59 AM Noble Paul  wrote:
> >
> > Thanks Adrien.
> > My apologies for the inconvenience .
> >
> > --Noble
> >
> > On Thu, Dec 19, 2019 at 8:04 AM Adrien Grand  wrote:
> > >
> > > Thanks Cassandra for finding this missing commit. I'll start a new RC 
> > > tomorrow morning EU time.
> > >
> > > On Wed, Dec 18, 2019 at 9:21 PM Alexandre Rafalovitch 
> > >  wrote:
> > >>
> > >> If there is a respin, maybe the Changenotes (for Solr) can be fixed too:
> > >> 1) First entry under Upgrade Notes is missing JIRA and probably does
> > >> not need to include the full class path
> > >> 2) Optimization section can probably be skipped as it just has "no
> > >> changes" entry
> > >> 3) Couple of JIRAs are missing contributor attributions (is it
> > >> compulsory? I don't know.)
> > >>
> > >> Also Lucene's one under "build" section is missing one JIRA number.
> > >>
> > >> Regards,
> > >>Alex.
> > >>
> > >> On Wed, 18 Dec 2019 at 14:20, Noble Paul  wrote:
> > >> >
> > >> > I'm so sorry to come at this moment and tell you that one of the
> > >> > critical bug fixes I made to master was not ported to 8x and 8.4.
> > >> >
> > >> > This breaks a critical functionality of package loading feature.
> > >> > Is it possible to do a respin?
> > >> > https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
> > >> >
> > >> >
> > >> > On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
> > >> > >
> > >> > > Hi Gus,
> > >> > >
> > >> > > If the test is flaky, would you mind annotating it with "@BadApple"? 
> > >> > > It will make sure this test doesn't get in the way of building or 
> > >> > > voting on a release until the test is fixed.
> > >> > >
> > >> > > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
> > >> > >>
> > >> > >> Hi Mkhail, This is a known flakey test (mine, it's on my to do 
> > >> > >> list). Seems to have got slightly more flakey recently possibly 
> > >> > >> because other tests have got better at using up CPU?. The flake 
> > >> > >> here is that the code in the test didn't manage to wait long enough 
> > >> > >> before running the assertion. This failure does not represent an 
> > >> > >> issue with anything other than the test.
> > >> > >>
> > >> > >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  
> > >> > >> wrote:
> > >> > >>>
> > >> > >>> I've got
> > >> > >>>
> > >> > >>>   2> NOTE: reproduce with: ant test  
> > >> > >>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
> > >> > >>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
> > >> > >>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> > >> > >>>
> > >> > >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > >> > >>>
> > >> > >>> [00:42:59.083] FAILURE 29.4s J1 | 
> > >> > >>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> > >> > >>>
> > >> > >>>> Throwable #1: java.lang.AssertionError: expected:<10> but 
> > >> > >>> was:<9>
> > >> > >>>
> > >> > >>>>at 
> > >> > >>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> > >> > >>>
> > >> > >>>>at org.junit.Assert.fail(Assert.java:88)
> > >> > >>>
> > >> > >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
> > >> > >>>
> > >> > >>>>at org.junit.Assert.assertEquals(Assert.java:645)
> > >> > >>>
> > >> > >>>>at org.junit.Assert.assertEquals(Assert.java:631)
> > >> > >>>
> > >> > >>>>at 
> > >> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> > >> > >>>
> > >> > >>>>at 
> > >> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> > >> > >>>
> > >> > >>>
> > >> > >>> which didn't reproduce to me when I retry.
> > >> > >>>
> > >> > >>> +0
> > >> > >>>
> > >> > >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  
> > >> > >>> wrote:
> > >> > 
> > >> >  Please vote for release candidate 1 for Lucene/Solr 8.4.0
> > >> > 
> > >> >  The artifacts can be downloaded from:
> > >> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > >> > 
> > >> >  You can run the smoke tester directly with this command:
> > >> > 
> > >> >  python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > >> > 
> > >> >  The vote will be 

Re: Paying attention to deprecation warnings

[Kevin Risden]

There is some "prior work" in this area [1] and [2]. Not specifically about
deprecations, but the idea is the same. Use the tools we have like the java
compiler to prevent future issues. Yes its going to be work to get to fewer
warnings, but we need to make sure that new ones get added.

[1] https://issues.apache.org/jira/browse/LUCENE-7631
[2] https://issues.apache.org/jira/browse/SOLR-9629

Kevin Risden


On Wed, Dec 18, 2019 at 12:47 PM Erick Erickson 
wrote:

> This’ll be a bit tricky as long as we have Java required 11 on master and
> Java 8 on 8x, we’ll have to sort out the deprecations due to the JDK .vs.
> everything else.
>
> That said, +1 to fixing this up, it’s been on my TODO list for, oh, 2
> years or so, but keeps sliding. A hackathon would be a great venue since
> there’ll be a zillion changes.
>
> Is there a way we can, once we have all the deprecation warnings out of a
> file, somehow fail precommit/test/build/whatever when deprecations sneak
> back in? It’d have to be on a file-by-file basis I’d guess, but that way we
> could keep from backsliding.
>
> You can convince IntelliJ (and I’m sure Eclipse) to show deprecation
> warnings when you pick the “recompile this file” which I recently started
> using.
>
> Ditto with precommit warnings….
>
> > On Dec 18, 2019, at 4:48 AM, Jan Høydahl  wrote:
> >
> > Hi
> >
> > Our project compiles and runs with tons of deprecation warnings.
> >
> > Recently when working on SOLR-14106 and SOLR-14105 we found that there
> has been jetty deprecation warnings in the logs ever since the 8.2 release,
> and these were early warnings that something was wrong, so not
> surprisingly, to get SSL working again in 8.5 the fix was to remove use of
> deprecated classes in Jetty.
> >
> > It may be a too ambitious goal to remove all use of deprecated APIs. But
> what about doing a hackaton to try to nail many of them! I bet we find some
> real bugs during that process as well.
> >
> > Jan
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

OK, my first attempt at a SIP. Safe indexing operations without re-indexing

[Erick Erickson]

https://cwiki.apache.org/confluence/display/SOLR/SIP-2+Support+safe+index+transformations+without+reindexing
JIRA: https://issues.apache.org/jira/browse/SOLR-14116
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Disturbing and steady decrease in boosting by date performance (and maybe others).

[Joel Bernstein]

One of the things that would be interesting would be to analyze the QTimes
for individual queries from the logs for these runs. If you ship me the log
files I can take a look. I'll also be posting a branch with new command
line tool for posting logs to be indexed in Solr tomorrow and you can take
a look at that.

And the profiler is probably the only way to know for sure what's happening
here.





Joel Bernstein
http://joelsolr.blogspot.com/


On Wed, Dec 18, 2019 at 7:37 PM Erick Erickson 
wrote:

> The very short form is that from Solr 6.6.1 to Solr 8.3.1, the throughput
> for date boosting in my tests dropped by 40+%
>
> I’ve been hearing about slowdowns in successive Solr releases with boost
> functions, so I dug into it a bit. The test setup is just a boost-by-date
> with an additional big OR clause of 100 random words so I’d be sure to hit
> a bunch of docs. I figured that if there were few hits, the signal would be
> lost in the noise, but I didn’t look at the actual hit counts.
>
> I saw several Solr JIRAs about this subject, but they were slightly
> different, although quite possibly the same underlying issue. So I tried to
> get this down to a very specific form of a query.
>
> I’ve also seen some cases in the wild where the response was proportional
> to the number of segments, thus my optimize experiments.
>
> Here are the results, explanation below. O stands for optimized to one
> segment. I spot checked pdate against 7x and 8x and they weren’t
> significantly different performance wise from tdate. All have docValues
> enabled. I ran these against a multiValued=“false” field. All the tests
> pegged all my CPUs. Jmeter is being run on a different machine than Solr.
> Only one Solr was running for any test.
>
> Solr version   queries/min
> 6.6.1  3,400
> 6.6.1 O   4,800
>
> 7.1 2,800
> 7.1 O 4,200
>
> 7.7.1  2,400
> 7.7.1 O  3,500
>
> 8.3.1 2,000
> 8.3.1 O  2,600
>
>
> The tests I’ve been running just index 20M docs into a single core, then
> run the exact same 10,000 queries against them from jmeter with 24 threads.
> Spot checks showed no hits on the queryResultCache.
>
> A query looks like this:
> rows=0&{!boost b=recip(ms(NOW,
> INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR
> anyplace…97 more random words)
>
> There is no faceting. No grouping. No sorting.
>
> I fill in INSERT_FIELD_HERE through jmeter magic. I’m running the exact
> same queries for every test.
>
> One wildcard is that I did regenerate the index for each major revision,
> and the chose random words from the same list of words, as well as random
> times (bounded in the same range though) so the docs are not completely
> identical. The index was in the native format for that major version even
> if slightly different between versions. I ran the test once, then ran it
> again after optimizing the index.
>
> I haven’t dug any farther, if anyone’s interested I can throw a profiler
> at, say, 8.3 and see what I can see, although I’m not going to have time to
> dive into this any time soon. I’d be glad to run some tests though. I saved
> the queries and the indexes so running a test would  only take a few
> minutes.
>
> While I concentrated on date fields, the docs have date, int, and long
> fields, both docValues=true and docValues=false, each variant with
> multiValued=true and multiValued=false and both Trie and Point (where
> possible) variants as well as a pretty simple text field.
>
> Erick
>
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Disturbing and steady decrease in boosting by date performance (and maybe others).

[Erick Erickson]

The very short form is that from Solr 6.6.1 to Solr 8.3.1, the throughput for 
date boosting in my tests dropped by 40+%

I’ve been hearing about slowdowns in successive Solr releases with boost 
functions, so I dug into it a bit. The test setup is just a boost-by-date with 
an additional big OR clause of 100 random words so I’d be sure to hit a bunch 
of docs. I figured that if there were few hits, the signal would be lost in the 
noise, but I didn’t look at the actual hit counts.

I saw several Solr JIRAs about this subject, but they were slightly different, 
although quite possibly the same underlying issue. So I tried to get this down 
to a very specific form of a query.

I’ve also seen some cases in the wild where the response was proportional to 
the number of segments, thus my optimize experiments.

Here are the results, explanation below. O stands for optimized to one segment. 
I spot checked pdate against 7x and 8x and they weren’t significantly different 
performance wise from tdate. All have docValues enabled. I ran these against a 
multiValued=“false” field. All the tests pegged all my CPUs. Jmeter is being 
run on a different machine than Solr. Only one Solr was running for any test.

Solr version   queries/min   
6.6.1  3,400  
6.6.1 O   4,800  

7.1 2,800   
7.1 O 4,200   

7.7.1  2,400   
7.7.1 O  3,500

8.3.1 2,000
8.3.1 O  2,600


The tests I’ve been running just index 20M docs into a single core, then run 
the exact same 10,000 queries against them from jmeter with 24 threads. Spot 
checks showed no hits on the queryResultCache.

A query looks like this: 
rows=0&{!boost b=recip(ms(NOW, 
INSERT_FIELD_HERE),3.16e-11,1,1)}text_txt:(campaigners OR adjourned OR 
anyplace…97 more random words)

There is no faceting. No grouping. No sorting.

I fill in INSERT_FIELD_HERE through jmeter magic. I’m running the exact same 
queries for every test.

One wildcard is that I did regenerate the index for each major revision, and 
the chose random words from the same list of words, as well as random times 
(bounded in the same range though) so the docs are not completely identical. 
The index was in the native format for that major version even if slightly 
different between versions. I ran the test once, then ran it again after 
optimizing the index.

I haven’t dug any farther, if anyone’s interested I can throw a profiler at, 
say, 8.3 and see what I can see, although I’m not going to have time to dive 
into this any time soon. I’d be glad to run some tests though. I saved the 
queries and the indexes so running a test would  only take a few minutes.

While I concentrated on date fields, the docs have date, int, and long fields, 
both docValues=true and docValues=false, each variant with multiValued=true and 
multiValued=false and both Trie and Point (where possible) variants as well as 
a pretty simple text field.

Erick



-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Noble Paul]

I'v ported the commit
https://gitbox.apache.org/repos/asf?p=lucene-solr.git;h=221d4ed

On Thu, Dec 19, 2019 at 8:59 AM Noble Paul  wrote:
>
> Thanks Adrien.
> My apologies for the inconvenience .
>
> --Noble
>
> On Thu, Dec 19, 2019 at 8:04 AM Adrien Grand  wrote:
> >
> > Thanks Cassandra for finding this missing commit. I'll start a new RC 
> > tomorrow morning EU time.
> >
> > On Wed, Dec 18, 2019 at 9:21 PM Alexandre Rafalovitch  
> > wrote:
> >>
> >> If there is a respin, maybe the Changenotes (for Solr) can be fixed too:
> >> 1) First entry under Upgrade Notes is missing JIRA and probably does
> >> not need to include the full class path
> >> 2) Optimization section can probably be skipped as it just has "no
> >> changes" entry
> >> 3) Couple of JIRAs are missing contributor attributions (is it
> >> compulsory? I don't know.)
> >>
> >> Also Lucene's one under "build" section is missing one JIRA number.
> >>
> >> Regards,
> >>Alex.
> >>
> >> On Wed, 18 Dec 2019 at 14:20, Noble Paul  wrote:
> >> >
> >> > I'm so sorry to come at this moment and tell you that one of the
> >> > critical bug fixes I made to master was not ported to 8x and 8.4.
> >> >
> >> > This breaks a critical functionality of package loading feature.
> >> > Is it possible to do a respin?
> >> > https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
> >> >
> >> >
> >> > On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
> >> > >
> >> > > Hi Gus,
> >> > >
> >> > > If the test is flaky, would you mind annotating it with "@BadApple"? 
> >> > > It will make sure this test doesn't get in the way of building or 
> >> > > voting on a release until the test is fixed.
> >> > >
> >> > > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
> >> > >>
> >> > >> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). 
> >> > >> Seems to have got slightly more flakey recently possibly because 
> >> > >> other tests have got better at using up CPU?. The flake here is that 
> >> > >> the code in the test didn't manage to wait long enough before running 
> >> > >> the assertion. This failure does not represent an issue with anything 
> >> > >> other than the test.
> >> > >>
> >> > >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  
> >> > >> wrote:
> >> > >>>
> >> > >>> I've got
> >> > >>>
> >> > >>>   2> NOTE: reproduce with: ant test  
> >> > >>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
> >> > >>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
> >> > >>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> >> > >>>
> >> > >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> >> > >>>
> >> > >>> [00:42:59.083] FAILURE 29.4s J1 | 
> >> > >>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> >> > >>>
> >> > >>>> Throwable #1: java.lang.AssertionError: expected:<10> but 
> >> > >>> was:<9>
> >> > >>>
> >> > >>>>at 
> >> > >>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> >> > >>>
> >> > >>>>at org.junit.Assert.fail(Assert.java:88)
> >> > >>>
> >> > >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
> >> > >>>
> >> > >>>>at org.junit.Assert.assertEquals(Assert.java:645)
> >> > >>>
> >> > >>>>at org.junit.Assert.assertEquals(Assert.java:631)
> >> > >>>
> >> > >>>>at 
> >> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> >> > >>>
> >> > >>>>at 
> >> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> >> > >>>
> >> > >>>
> >> > >>> which didn't reproduce to me when I retry.
> >> > >>>
> >> > >>> +0
> >> > >>>
> >> > >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  
> >> > >>> wrote:
> >> > 
> >> >  Please vote for release candidate 1 for Lucene/Solr 8.4.0
> >> > 
> >> >  The artifacts can be downloaded from:
> >> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> >> > 
> >> >  You can run the smoke tester directly with this command:
> >> > 
> >> >  python3 -u dev-tools/scripts/smokeTestRelease.py \
> >> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> >> > 
> >> >  The vote will be open for at least 3 working days, i.e. until 
> >> >  2019-12-20 19:00 UTC.
> >> > 
> >> >  [ ] +1  approve
> >> >  [ ] +0  no opinion
> >> >  [ ] -1  disapprove (and reason why)
> >> > 
> >> >  Here is my +1
> >> > 
> >> >  --
> >> >  Adrien
> >> > >>>
> >> > >>>
> >> > >>>
> >> > >>> --
> >> > >>> Sincerely yours
> >> > >>> Mikhail Khludnev
> >> > >>
> >> > >>
> >> > >>
> >> > >> --
> >> > >> http://www.needhamsoftware.com (work)
> >> > >> 

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Noble Paul]

Thanks Adrien.
My apologies for the inconvenience .

--Noble

On Thu, Dec 19, 2019 at 8:04 AM Adrien Grand  wrote:
>
> Thanks Cassandra for finding this missing commit. I'll start a new RC 
> tomorrow morning EU time.
>
> On Wed, Dec 18, 2019 at 9:21 PM Alexandre Rafalovitch  
> wrote:
>>
>> If there is a respin, maybe the Changenotes (for Solr) can be fixed too:
>> 1) First entry under Upgrade Notes is missing JIRA and probably does
>> not need to include the full class path
>> 2) Optimization section can probably be skipped as it just has "no
>> changes" entry
>> 3) Couple of JIRAs are missing contributor attributions (is it
>> compulsory? I don't know.)
>>
>> Also Lucene's one under "build" section is missing one JIRA number.
>>
>> Regards,
>>Alex.
>>
>> On Wed, 18 Dec 2019 at 14:20, Noble Paul  wrote:
>> >
>> > I'm so sorry to come at this moment and tell you that one of the
>> > critical bug fixes I made to master was not ported to 8x and 8.4.
>> >
>> > This breaks a critical functionality of package loading feature.
>> > Is it possible to do a respin?
>> > https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
>> >
>> >
>> > On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
>> > >
>> > > Hi Gus,
>> > >
>> > > If the test is flaky, would you mind annotating it with "@BadApple"? It 
>> > > will make sure this test doesn't get in the way of building or voting on 
>> > > a release until the test is fixed.
>> > >
>> > > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
>> > >>
>> > >> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). 
>> > >> Seems to have got slightly more flakey recently possibly because other 
>> > >> tests have got better at using up CPU?. The flake here is that the code 
>> > >> in the test didn't manage to wait long enough before running the 
>> > >> assertion. This failure does not represent an issue with anything other 
>> > >> than the test.
>> > >>
>> > >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  
>> > >> wrote:
>> > >>>
>> > >>> I've got
>> > >>>
>> > >>>   2> NOTE: reproduce with: ant test  
>> > >>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
>> > >>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
>> > >>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
>> > >>>
>> > >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
>> > >>>
>> > >>> [00:42:59.083] FAILURE 29.4s J1 | 
>> > >>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
>> > >>>
>> > >>>> Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
>> > >>>
>> > >>>>at 
>> > >>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
>> > >>>
>> > >>>>at org.junit.Assert.fail(Assert.java:88)
>> > >>>
>> > >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
>> > >>>
>> > >>>>at org.junit.Assert.assertEquals(Assert.java:645)
>> > >>>
>> > >>>>at org.junit.Assert.assertEquals(Assert.java:631)
>> > >>>
>> > >>>>at 
>> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
>> > >>>
>> > >>>>at 
>> > >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
>> > >>>
>> > >>>
>> > >>> which didn't reproduce to me when I retry.
>> > >>>
>> > >>> +0
>> > >>>
>> > >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
>> > 
>> >  Please vote for release candidate 1 for Lucene/Solr 8.4.0
>> > 
>> >  The artifacts can be downloaded from:
>> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>> > 
>> >  You can run the smoke tester directly with this command:
>> > 
>> >  python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>> > 
>> >  The vote will be open for at least 3 working days, i.e. until 
>> >  2019-12-20 19:00 UTC.
>> > 
>> >  [ ] +1  approve
>> >  [ ] +0  no opinion
>> >  [ ] -1  disapprove (and reason why)
>> > 
>> >  Here is my +1
>> > 
>> >  --
>> >  Adrien
>> > >>>
>> > >>>
>> > >>>
>> > >>> --
>> > >>> Sincerely yours
>> > >>> Mikhail Khludnev
>> > >>
>> > >>
>> > >>
>> > >> --
>> > >> http://www.needhamsoftware.com (work)
>> > >> http://www.the111shift.com (play)
>> > >
>> > >
>> > >
>> > > --
>> > > Adrien
>> >
>> >
>> >
>> > --
>> > -
>> > Noble Paul
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>> 

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Adrien Grand]

Thanks Cassandra for finding this missing commit. I'll start a new RC
tomorrow morning EU time.

On Wed, Dec 18, 2019 at 9:21 PM Alexandre Rafalovitch 
wrote:

> If there is a respin, maybe the Changenotes (for Solr) can be fixed too:
> 1) First entry under Upgrade Notes is missing JIRA and probably does
> not need to include the full class path
> 2) Optimization section can probably be skipped as it just has "no
> changes" entry
> 3) Couple of JIRAs are missing contributor attributions (is it
> compulsory? I don't know.)
>
> Also Lucene's one under "build" section is missing one JIRA number.
>
> Regards,
>Alex.
>
> On Wed, 18 Dec 2019 at 14:20, Noble Paul  wrote:
> >
> > I'm so sorry to come at this moment and tell you that one of the
> > critical bug fixes I made to master was not ported to 8x and 8.4.
> >
> > This breaks a critical functionality of package loading feature.
> > Is it possible to do a respin?
> >
> https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
> >
> >
> > On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
> > >
> > > Hi Gus,
> > >
> > > If the test is flaky, would you mind annotating it with "@BadApple"?
> It will make sure this test doesn't get in the way of building or voting on
> a release until the test is fixed.
> > >
> > > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
> > >>
> > >> Hi Mkhail, This is a known flakey test (mine, it's on my to do list).
> Seems to have got slightly more flakey recently possibly because other
> tests have got better at using up CPU?. The flake here is that the code in
> the test didn't manage to wait long enough before running the assertion.
> This failure does not represent an issue with anything other than the test.
> > >>
> > >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev 
> wrote:
> > >>>
> > >>> I've got
> > >>>
> > >>>   2> NOTE: reproduce with: ant test
> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest
> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B
> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> > >>>
> > >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > >>>
> > >>> [00:42:59.083] FAILURE 29.4s J1 |
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> > >>>
> > >>>> Throwable #1: java.lang.AssertionError: expected:<10> but
> was:<9>
> > >>>
> > >>>>at
> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> > >>>
> > >>>>at org.junit.Assert.fail(Assert.java:88)
> > >>>
> > >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
> > >>>
> > >>>>at org.junit.Assert.assertEquals(Assert.java:645)
> > >>>
> > >>>>at org.junit.Assert.assertEquals(Assert.java:631)
> > >>>
> > >>>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> > >>>
> > >>>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> > >>>
> > >>>
> > >>> which didn't reproduce to me when I retry.
> > >>>
> > >>> +0
> > >>>
> > >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand 
> wrote:
> > 
> >  Please vote for release candidate 1 for Lucene/Solr 8.4.0
> > 
> >  The artifacts can be downloaded from:
> > 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > 
> >  You can run the smoke tester directly with this command:
> > 
> >  python3 -u dev-tools/scripts/smokeTestRelease.py \
> > 
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > 
> >  The vote will be open for at least 3 working days, i.e. until
> 2019-12-20 19:00 UTC.
> > 
> >  [ ] +1  approve
> >  [ ] +0  no opinion
> >  [ ] -1  disapprove (and reason why)
> > 
> >  Here is my +1
> > 
> >  --
> >  Adrien
> > >>>
> > >>>
> > >>>
> > >>> --
> > >>> Sincerely yours
> > >>> Mikhail Khludnev
> > >>
> > >>
> > >>
> > >> --
> > >> http://www.needhamsoftware.com (work)
> > >> http://www.the111shift.com (play)
> > >
> > >
> > >
> > > --
> > > Adrien
> >
> >
> >
> > --
> > -
> > Noble Paul
> >
> > -
> > 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
>
>

-- 
Adrien

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Alexandre Rafalovitch]

If there is a respin, maybe the Changenotes (for Solr) can be fixed too:
1) First entry under Upgrade Notes is missing JIRA and probably does
not need to include the full class path
2) Optimization section can probably be skipped as it just has "no
changes" entry
3) Couple of JIRAs are missing contributor attributions (is it
compulsory? I don't know.)

Also Lucene's one under "build" section is missing one JIRA number.

Regards,
   Alex.

On Wed, 18 Dec 2019 at 14:20, Noble Paul  wrote:
>
> I'm so sorry to come at this moment and tell you that one of the
> critical bug fixes I made to master was not ported to 8x and 8.4.
>
> This breaks a critical functionality of package loading feature.
> Is it possible to do a respin?
> https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49
>
>
> On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
> >
> > Hi Gus,
> >
> > If the test is flaky, would you mind annotating it with "@BadApple"? It 
> > will make sure this test doesn't get in the way of building or voting on a 
> > release until the test is fixed.
> >
> > On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
> >>
> >> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). 
> >> Seems to have got slightly more flakey recently possibly because other 
> >> tests have got better at using up CPU?. The flake here is that the code in 
> >> the test didn't manage to wait long enough before running the assertion. 
> >> This failure does not represent an issue with anything other than the test.
> >>
> >> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:
> >>>
> >>> I've got
> >>>
> >>>   2> NOTE: reproduce with: ant test  
> >>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
> >>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
> >>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> >>>
> >>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> >>>
> >>> [00:42:59.083] FAILURE 29.4s J1 | 
> >>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> >>>
> >>>> Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
> >>>
> >>>>at 
> >>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> >>>
> >>>>at org.junit.Assert.fail(Assert.java:88)
> >>>
> >>>>at org.junit.Assert.failNotEquals(Assert.java:834)
> >>>
> >>>>at org.junit.Assert.assertEquals(Assert.java:645)
> >>>
> >>>>at org.junit.Assert.assertEquals(Assert.java:631)
> >>>
> >>>>at 
> >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> >>>
> >>>>at 
> >>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> >>>
> >>>
> >>> which didn't reproduce to me when I retry.
> >>>
> >>> +0
> >>>
> >>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
> 
>  Please vote for release candidate 1 for Lucene/Solr 8.4.0
> 
>  The artifacts can be downloaded from:
>  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> 
>  You can run the smoke tester directly with this command:
> 
>  python3 -u dev-tools/scripts/smokeTestRelease.py \
>  https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> 
>  The vote will be open for at least 3 working days, i.e. until 2019-12-20 
>  19:00 UTC.
> 
>  [ ] +1  approve
>  [ ] +0  no opinion
>  [ ] -1  disapprove (and reason why)
> 
>  Here is my +1
> 
>  --
>  Adrien
> >>>
> >>>
> >>>
> >>> --
> >>> Sincerely yours
> >>> Mikhail Khludnev
> >>
> >>
> >>
> >> --
> >> http://www.needhamsoftware.com (work)
> >> http://www.the111shift.com (play)
> >
> >
> >
> > --
> > Adrien
>
>
>
> --
> -
> Noble Paul
>
> -
> 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 Lucene/Solr 8.4.0 RC1

[Noble Paul]

I'm so sorry to come at this moment and tell you that one of the
critical bug fixes I made to master was not ported to 8x and 8.4.

This breaks a critical functionality of package loading feature.
Is it possible to do a respin?
https://github.com/apache/lucene-solr/commit/f98555854cbdb9d396c34a93fde9c1610df74882#diff-04f78a3e0960a743f6b4267e2d0f7f49


On Thu, Dec 19, 2019 at 6:11 AM Adrien Grand  wrote:
>
> Hi Gus,
>
> If the test is flaky, would you mind annotating it with "@BadApple"? It will 
> make sure this test doesn't get in the way of building or voting on a release 
> until the test is fixed.
>
> On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:
>>
>> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). Seems 
>> to have got slightly more flakey recently possibly because other tests have 
>> got better at using up CPU?. The flake here is that the code in the test 
>> didn't manage to wait long enough before running the assertion. This failure 
>> does not represent an issue with anything other than the test.
>>
>> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:
>>>
>>> I've got
>>>
>>>   2> NOTE: reproduce with: ant test  
>>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
>>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
>>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
>>>
>>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
>>>
>>> [00:42:59.083] FAILURE 29.4s J1 | 
>>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
>>>
>>>> Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
>>>
>>>>at 
>>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
>>>
>>>>at org.junit.Assert.fail(Assert.java:88)
>>>
>>>>at org.junit.Assert.failNotEquals(Assert.java:834)
>>>
>>>>at org.junit.Assert.assertEquals(Assert.java:645)
>>>
>>>>at org.junit.Assert.assertEquals(Assert.java:631)
>>>
>>>>at 
>>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
>>>
>>>>at 
>>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
>>>
>>>
>>> which didn't reproduce to me when I retry.
>>>
>>> +0
>>>
>>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:

 Please vote for release candidate 1 for Lucene/Solr 8.4.0

 The artifacts can be downloaded from:
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670

 You can run the smoke tester directly with this command:

 python3 -u dev-tools/scripts/smokeTestRelease.py \
 https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670

 The vote will be open for at least 3 working days, i.e. until 2019-12-20 
 19:00 UTC.

 [ ] +1  approve
 [ ] +0  no opinion
 [ ] -1  disapprove (and reason why)

 Here is my +1

 --
 Adrien
>>>
>>>
>>>
>>> --
>>> Sincerely yours
>>> Mikhail Khludnev
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>
>
> --
> Adrien



--
-
Noble Paul

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Adrien Grand]

Hi Gus,

If the test is flaky, would you mind annotating it with "@BadApple"? It
will make sure this test doesn't get in the way of building or voting on a
release until the test is fixed.

On Wed, Dec 18, 2019 at 3:52 PM Gus Heck  wrote:

> Hi Mkhail, This is a known flakey test (mine, it's on my to do list).
> Seems to have got slightly more flakey recently possibly because other
> tests have got better at using up CPU?. The flake here is that the code in
> the test didn't manage to wait long enough before running the assertion.
> This failure does not represent an issue with anything other than the test.
>
> On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:
>
>> I've got
>>
>>   2> NOTE: reproduce with: ant test  
>> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest
>> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B
>> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
>>
>> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
>>
>> [00:42:59.083] FAILURE 29.4s J1 |
>> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
>>
>>> Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
>>
>>>at
>> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
>>
>>>at org.junit.Assert.fail(Assert.java:88)
>>
>>>at org.junit.Assert.failNotEquals(Assert.java:834)
>>
>>>at org.junit.Assert.assertEquals(Assert.java:645)
>>
>>>at org.junit.Assert.assertEquals(Assert.java:631)
>>
>>>at
>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
>>
>>>at
>> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
>>
>> which didn't reproduce to me when I retry.
>>
>> +0
>>
>> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
>>
>>> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>>
>>> The vote will be open for at least 3 working days, i.e. until 2019-12-20
>>> 19:00 UTC.
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> Here is my +1
>>>
>>> --
>>> Adrien
>>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>


-- 
Adrien

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Cassandra Targett]

A little late for some votes, but the Draft version of the 8.4 Solr Ref Guide 
is up now: https://lucene.apache.org/solr/guide/8_4/

(I need to get on automating it soon.)
On Dec 18, 2019, 8:52 AM -0600, Gus Heck , wrote:
> Hi Mkhail, This is a known flakey test (mine, it's on my to do list). Seems 
> to have got slightly more flakey recently possibly because other tests have 
> got better at using up CPU?. The flake here is that the code in the test 
> didn't manage to wait long enough before running the assertion. This failure 
> does not represent an issue with anything other than the test.
>
> > On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:
> > > I've got
> > >   2> NOTE: reproduce with: ant test  
> > > -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest 
> > > -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B 
> > > -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
> > > ests.asserts=true -Dtests.file.encoding=ISO-8859-1
> > > [00:42:59.083] FAILURE 29.4s J1 | 
> > > DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
> > >    > Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
> > >    >    at 
> > > __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
> > >    >    at org.junit.Assert.fail(Assert.java:88)
> > >    >    at org.junit.Assert.failNotEquals(Assert.java:834)
> > >    >    at org.junit.Assert.assertEquals(Assert.java:645)
> > >    >    at org.junit.Assert.assertEquals(Assert.java:631)
> > >    >    at 
> > > org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
> > >    >    at 
> > > org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
> > >
> > > > which didn't reproduce to me when I retry.
> > > >
> > > > +0
> > > >
> > > > On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
> > > > > Please vote for release candidate 1 for Lucene/Solr 8.4.0
> > > > >
> > > > > The artifacts can be downloaded from:
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > > > >
> > > > > You can run the smoke tester directly with this command:
> > > > >
> > > > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > > > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
> > > > >
> > > > > The vote will be open for at least 3 working days, i.e. until 
> > > > > 2019-12-20 19:00 UTC.
> > > > >
> > > > > [ ] +1  approve
> > > > > [ ] +0  no opinion
> > > > > [ ] -1  disapprove (and reason why)
> > > > >
> > > > > Here is my +1
> > > > >
> > > > > --
> > > > > Adrien
> > >
> > >
> > > --
> > > Sincerely yours
> > > Mikhail Khludnev
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

Re: Paying attention to deprecation warnings

[Erick Erickson]

This’ll be a bit tricky as long as we have Java required 11 on master and Java 
8 on 8x, we’ll have to sort out the deprecations due to the JDK .vs. everything 
else.

That said, +1 to fixing this up, it’s been on my TODO list for, oh, 2 years or 
so, but keeps sliding. A hackathon would be a great venue since there’ll be a 
zillion changes.

Is there a way we can, once we have all the deprecation warnings out of a file, 
somehow fail precommit/test/build/whatever when deprecations sneak back in? 
It’d have to be on a file-by-file basis I’d guess, but that way we could keep 
from backsliding.

You can convince IntelliJ (and I’m sure Eclipse) to show deprecation warnings 
when you pick the “recompile this file” which I recently started using.

Ditto with precommit warnings….

> On Dec 18, 2019, at 4:48 AM, Jan Høydahl  wrote:
> 
> Hi
> 
> Our project compiles and runs with tons of deprecation warnings.
> 
> Recently when working on SOLR-14106 and SOLR-14105 we found that there has 
> been jetty deprecation warnings in the logs ever since the 8.2 release, and 
> these were early warnings that something was wrong, so not surprisingly, to 
> get SSL working again in 8.5 the fix was to remove use of deprecated classes 
> in Jetty.
> 
> It may be a too ambitious goal to remove all use of deprecated APIs. But what 
> about doing a hackaton to try to nail many of them! I bet we find some real 
> bugs during that process as well.
> 
> Jan


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Atri Sharma]

+1


SUCCESS! [1:26:38.49393]

On Tue, Dec 17, 2019 at 11:53 PM Adrien Grand  wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>
> The vote will be open for at least 3 working days, i.e. until 2019-12-20 
> 19:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien

-- 
Regards,

Atri
Apache Concerted

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Gus Heck]

Hi Mkhail, This is a known flakey test (mine, it's on my to do list). Seems
to have got slightly more flakey recently possibly because other tests have
got better at using up CPU?. The flake here is that the code in the test
didn't manage to wait long enough before running the assertion. This
failure does not represent an issue with anything other than the test.

On Wed, Dec 18, 2019 at 1:06 AM Mikhail Khludnev  wrote:

> I've got
>
>   2> NOTE: reproduce with: ant test  
> -Dtestcase=DimensionalRoutedAliasUpdateProcessorTest
> -Dtests.method=testTimeCat -Dtests.seed=D05700662AF3B95B
> -Dtests.locale=en-GB -Dtests.timezone=Australia/North -Dt
>
> ests.asserts=true -Dtests.file.encoding=ISO-8859-1
>
> [00:42:59.083] FAILURE 29.4s J1 |
> DimensionalRoutedAliasUpdateProcessorTest.testTimeCat <<<
>
>> Throwable #1: java.lang.AssertionError: expected:<10> but was:<9>
>
>>at
> __randomizedtesting.SeedInfo.seed([D05700662AF3B95B:E9AF41D56AD2F530]:0)
>
>>at org.junit.Assert.fail(Assert.java:88)
>
>>at org.junit.Assert.failNotEquals(Assert.java:834)
>
>>at org.junit.Assert.assertEquals(Assert.java:645)
>
>>at org.junit.Assert.assertEquals(Assert.java:631)
>
>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.assertCatTimeInvariants(DimensionalRoutedAliasUpdateProcessorTest.java:678)
>
>>at
> org.apache.solr.update.processor.DimensionalRoutedAliasUpdateProcessorTest.testTimeCat(DimensionalRoutedAliasUpdateProcessorTest.java:196)
>
> which didn't reproduce to me when I retry.
>
> +0
>
> On Tue, Dec 17, 2019 at 9:23 PM Adrien Grand  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> The vote will be open for at least 3 working days, i.e. until 2019-12-20
>> 19:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> --
>> Adrien
>>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>


-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Tommaso Teofili]

+1


SUCCESS! [1:33:40.587556]

On Wed, 18 Dec 2019 at 11:37, Shalin Shekhar Mangar 
wrote:

> +1
>
> SUCCESS! [0:50:00.981792]
>
> On Tue, Dec 17, 2019 at 11:53 PM Adrien Grand  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> The vote will be open for at least 3 working days, i.e. until 2019-12-20
>> 19:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> --
>> Adrien
>>
>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Shalin Shekhar Mangar]

+1

SUCCESS! [0:50:00.981792]

On Tue, Dec 17, 2019 at 11:53 PM Adrien Grand  wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>
> The vote will be open for at least 3 working days, i.e. until 2019-12-20
> 19:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien
>


-- 
Regards,
Shalin Shekhar Mangar.

Paying attention to deprecation warnings

[Jan Høydahl]

Hi

Our project compiles and runs with tons of deprecation warnings.

Recently when working on SOLR-14106 
 and SOLR-14105 
 we found that there has been 
jetty deprecation warnings in the logs ever since the 8.2 release, and these 
were early warnings that something was wrong, so not surprisingly, to get SSL 
working again in 8.5 the fix was to remove use of deprecated classes in Jetty.

It may be a too ambitious goal to remove all use of deprecated APIs. But what 
about doing a hackaton to try to nail many of them! I bet we find some real 
bugs during that process as well.

Jan

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Munendra S N]

+1

SUCCESS! [1:30:13.695296]



On Wed, Dec 18, 2019 at 2:01 PM Andrzej Białecki  wrote:

> +1
>
> SUCCESS! [1:34:39.788377]
>
> On 17 Dec 2019, at 21:13, Anshum Gupta  wrote:
>
> +1
>
> SUCCESS! [1:21:44.176149]
>
> On Tue, Dec 17, 2019 at 10:23 AM Adrien Grand  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.4.0
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> You can run the smoke tester directly with this command:
>>
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>>
>> The vote will be open for at least 3 working days, i.e. until 2019-12-20
>> 19:00 UTC.
>>
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>>
>> Here is my +1
>>
>> --
>> Adrien
>>
>
>
> --
> Anshum Gupta
>
>
>

Re: [VOTE] Release Lucene/Solr 8.4.0 RC1

[Andrzej Białecki]

+1

SUCCESS! [1:34:39.788377]

> On 17 Dec 2019, at 21:13, Anshum Gupta  wrote:
> 
> +1
> 
> SUCCESS! [1:21:44.176149]
> 
> On Tue, Dec 17, 2019 at 10:23 AM Adrien Grand  > wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.4.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.4.0-RC1-revc91d36f50efb62e55bcc3a1adc0442b207018670
>  
> 
> 
> The vote will be open for at least 3 working days, i.e. until 2019-12-20 
> 19:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> Adrien
> 
> 
> -- 
> Anshum Gupta