Re: Welcome Zhang Chao as Lucene committer

[Alan Woodward]

Congratulations and welcome!

- Alan

> On 20 Feb 2024, at 17:28, Adrien Grand  wrote:
> 
> I'm pleased to announce that Zhang Chao has accepted the PMC's
> invitation to become a committer.
> 
> Chao, the tradition is that new committers introduce themselves with a
> brief bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien


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

Re: Welcome Stefan Vodita as Lucene committter

[Alan Woodward]

Welcome Stefan!

> On 18 Jan 2024, at 15:53, Michael McCandless  
> wrote:
> 
> Hi Team,
> 
> I'm pleased to announce that Stefan Vodita has accepted the Lucene PMC's 
> invitation to become a committer!
> 
> Stefan, the tradition is that new committers introduce themselves with a 
> brief bio.
> 
> Congratulations, welcome, and thank you for all your improvements to Lucene 
> and our community,
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com 

Re: [lucene] 01/04: Introduced the Word2VecSynonymFilter (#12169)

[Alan Woodward]

Hey Alessandro, I just spotted this going into 9.x which introduces some 
breaking changes to the QueryBuilder API (specifically, moving TermAndBoost to 
its own class).  This will make upgrading 9.6 to 9.7 difficult as it means 
anything that extends QueryBuilder will need to change imports and recompile.

Can we at least keep QueryBuilder.TermAndBoost in the same place in 9.x?  I’m 
not sure it needs to move in main either, but we can discuss that later!

> On 30 May 2023, at 16:29, abenede...@apache.org wrote:
> 
> This is an automated email from the ASF dual-hosted git repository.
> 
> abenedetti pushed a commit to branch branch_9x
> in repository https://gitbox.apache.org/repos/asf/lucene.git
> 
> commit 64b48b89b501a89e303f6201f3a25ed0fb901f80
> Author: Daniele Antuzi 
> AuthorDate: Mon Apr 24 13:35:26 2023 +0200
> 
>   Introduced the Word2VecSynonymFilter (#12169)
> 
>   Co-authored-by: Alessandro Benedetti 
> ---
> .../lucene/analysis/tests/TestRandomChains.java|  25 
> lucene/analysis/common/src/java/module-info.java   |   2 +
> .../analysis/synonym/word2vec/Dl4jModelReader.java | 126 
> .../analysis/synonym/word2vec/Word2VecModel.java   |  95 
> .../synonym/word2vec/Word2VecSynonymFilter.java| 108 ++
> .../word2vec/Word2VecSynonymFilterFactory.java | 101 +
> .../synonym/word2vec/Word2VecSynonymProvider.java  | 104 ++
> .../word2vec/Word2VecSynonymProviderFactory.java   |  63 
> .../analysis/synonym/word2vec/package-info.java|  19 +++
> .../org.apache.lucene.analysis.TokenFilterFactory  |   1 +
> .../synonym/word2vec/TestDl4jModelReader.java  |  98 +
> .../word2vec/TestWord2VecSynonymFilter.java| 152 
> .../word2vec/TestWord2VecSynonymFilterFactory.java | 159 +
> .../word2vec/TestWord2VecSynonymProvider.java  | 132 +
> .../word2vec-corrupted-vector-dimension-model.zip  | Bin 0 -> 323 bytes
> .../synonym/word2vec/word2vec-empty-model.zip  | Bin 0 -> 195 bytes
> .../analysis/synonym/word2vec/word2vec-model.zip   | Bin 0 -> 439678 bytes
> .../java/org/apache/lucene/util/QueryBuilder.java  |  14 --
> .../java/org/apache/lucene/util/TermAndBoost.java  |  31 
> .../java/org/apache/lucene/util/TermAndVector.java |  72 ++
> .../apache/lucene/util/hnsw/HnswGraphBuilder.java  |   9 ++
> .../test/org/apache/lucene/index/TestKnnGraph.java |  11 +-
> .../tests/analysis/BaseTokenStreamTestCase.java| 149 ++-
> 23 files changed, 1448 insertions(+), 23 deletions(-)
> 
> diff --git 
> a/lucene/analysis.tests/src/test/org/apache/lucene/analysis/tests/TestRandomChains.java
>  
> b/lucene/analysis.tests/src/test/org/apache/lucene/analysis/tests/TestRandomChains.java
> index 8c245e7058c..988deaf99e5 100644
> --- 
> a/lucene/analysis.tests/src/test/org/apache/lucene/analysis/tests/TestRandomChains.java
> +++ 
> b/lucene/analysis.tests/src/test/org/apache/lucene/analysis/tests/TestRandomChains.java
> @@ -89,6 +89,8 @@ import org.apache.lucene.analysis.shingle.ShingleFilter;
> import org.apache.lucene.analysis.standard.StandardTokenizer;
> import org.apache.lucene.analysis.stempel.StempelStemmer;
> import org.apache.lucene.analysis.synonym.SynonymMap;
> +import org.apache.lucene.analysis.synonym.word2vec.Word2VecModel;
> +import org.apache.lucene.analysis.synonym.word2vec.Word2VecSynonymProvider;
> import org.apache.lucene.store.ByteBuffersDirectory;
> import org.apache.lucene.tests.analysis.BaseTokenStreamTestCase;
> import org.apache.lucene.tests.analysis.MockTokenFilter;
> @@ -99,8 +101,10 @@ import org.apache.lucene.tests.util.TestUtil;
> import org.apache.lucene.tests.util.automaton.AutomatonTestUtil;
> import org.apache.lucene.util.AttributeFactory;
> import org.apache.lucene.util.AttributeSource;
> +import org.apache.lucene.util.BytesRef;
> import org.apache.lucene.util.CharsRef;
> import org.apache.lucene.util.IgnoreRandomChains;
> +import org.apache.lucene.util.TermAndVector;
> import org.apache.lucene.util.Version;
> import org.apache.lucene.util.automaton.Automaton;
> import org.apache.lucene.util.automaton.CharacterRunAutomaton;
> @@ -415,6 +419,27 @@ public class TestRandomChains extends 
> BaseTokenStreamTestCase {
>  }
>}
>  });
> +  put(
> +  Word2VecSynonymProvider.class,
> +  random -> {
> +final int numEntries = atLeast(10);
> +final int vectorDimension = random.nextInt(99) + 1;
> +Word2VecModel model = new Word2VecModel(numEntries, 
> vectorDimension);
> +for (int j = 0; j < numEntries; j++) {
> +  String s = TestUtil.randomSimpleString(random, 10, 20);
> +  float[] vec = new float[vectorDimension];
> +  for (int i = 0; i < vectorDimension; i++) {
> +

Re: New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

Thanks Ishan, turns out the error was between chair and keyboard - I’d told the 
wizard to use the gradle java plugin to sign things when I should have been 
using gpg.

> On 2 May 2023, at 14:19, Ishan Chattopadhyaya  
> wrote:
> 
> Don't remember the specifics, but I ran into GPG issues during Solr 9.1.0 
> release. The fix for me was https://github.com/apache/solr/pull/1125, but I 
> don't know if this is the same problem or if it is applicable in Lucene's 
> case.
> 
> On Tue, 2 May 2023 at 18:27, Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
>> I am fighting with gradle and GPG yet again… Gradle fails when trying to 
>> sign artefacts with the message "Cannot perform signing task 
>> ':lucene:distribution:signReleaseArchives' because it has no configured 
>> signatory”.  I have GPG configured in ~/.gradle/gradle.properties as follows:
>> 
>> org.gradle.caching=true
>> signing.keyId=
>> signing.secretKeyRingFile=/Users/romseygeek/.gnupg/secring.gpg
>> signing.gnupg.executable=gpg
>> 
>> This worked last time I did a release.  Does anybody know if anything has 
>> changed in gradle that means I need to change the properties file, or have 
>> any other ideas?
>> 
>> > On 27 Apr 2023, at 10:54, Alan Woodward > > <mailto:romseyg...@gmail.com>> wrote:
>> > 
>> > I have started a release note here: 
>> > https://cwiki.apache.org/confluence/display/LUCENE/Release+Notes+9.6
>> > 
>> >> On 27 Apr 2023, at 09:45, Alan Woodward > >> <mailto:romseyg...@gmail.com>> wrote:
>> >> 
>> >> I have successfully wrestled Jenkins into submission, and there are now 
>> >> 9.6 jobs for Artifacts, Check and NightlyTests.
>> >> 
>> >>> On 26 Apr 2023, at 16:53, Alan Woodward > >>> <mailto:romseyg...@gmail.com>> wrote:
>> >>> 
>> >>> NOTICE:
>> >>> 
>> >>> Branch branch_9_6 has been cut and versions updated to 9.7 on stable 
>> >>> branch.
>> >>> 
>> >>> Please observe the normal rules:
>> >>> 
>> >>> * No new features may be committed to the branch.
>> >>> * Documentation patches, build patches and serious bug fixes may be
>> >>> committed to the branch. However, you should submit all patches you
>> >>> want to commit as pull requests first to give others the chance to review
>> >>> and possibly vote against them. Keep in mind that it is our
>> >>> main intention to keep the branch as stable as possible.
>> >>> * All patches that are intended for the branch should first be committed
>> >>> to the unstable branch, merged into the stable branch, and then into
>> >>> the current release branch.
>> >>> * Normal unstable and stable branch development may continue as usual.
>> >>> However, if you plan to commit a big change to the unstable branch
>> >>> while the branch feature freeze is in effect, think twice: can't the
>> >>> addition wait a couple more days? Merges of bug fixes into the branch
>> >>> may become more difficult.
>> >>> * Only Github issues with Milestone 9.6
>> >>> and priority "Blocker" will delay a release candidate build.
>> >>> 
>> >>> 
>> >>> I am struggling to find the lucene Jenkins jobs on the new apache build 
>> >>> server at https://jenkins-ccos.apache.org/ - if anybody has any hints as 
>> >>> to how to navigate the helpful new interface with a non-functional 
>> >>> search box, I would be very grateful…
>> >>> 
>> >>> It’s a holiday weekend coming up in the UK, so my plan is to give 
>> >>> Jenkins a few days to chew things over (once I actually get the jobs 
>> >>> running) and then build a RC on Tuesday 2nd May.
>> >> 
>> > 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 

[ANNOUNCE] Apache Lucene 9.6.0 released

[Alan Woodward]

The Lucene PMC is pleased to announce the release of Apache Lucene 9.6.0.

Apache Lucene is a high-performance, full-featured search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires structured search, full-text search, faceting, 
nearest-neighbor search across high-dimensionality vectors, spell correction or 
query suggestions.

This release contains numerous bug fixes, optimizations, and improvements, some 
of which are highlighted below. The release is available for immediate download 
at:

 

### Lucene 9.6.0 Release Highlights:

* Introduce a new KeywordField for simple and efficient  filtering, sorting and 
faceting.
* Add support for Java 20 foreign memory API. If exactly Java 19 or 20 is used, 
MMapDirectory will mmap Lucene indexes in chunks of 16 GiB (instead of 1 GiB) 
and indexes closed while queries are running can no longer crash the JVM.
* Improved performance for TermInSetQuery, PrefixQuery, WildcardQuery and 
TermRangeQuery
* Lower memory usage for BloomFilteringPostingsFormat
* Faster merges for HNSW indexes
* Improvements to concurrent indexing throughput under heavy load
* Correct equals implementation in SynonymQuery
* 'explain' is now implemented on TermAutomatonQuery

Please read CHANGES.txt for a full list of new features and changes:

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

[RESULT] [VOTE] Release Lucene 9.6.0 RC2

[Alan Woodward]

It's been >72h since the vote was initiated and the result is:

+1  9  (7 binding)
0  0
-1  0

This vote has PASSED

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

Re: Building the website

[Alan Woodward]

Ah never mind, it looks like GitHub is having problems today, will see if it 
picks things up again later...

> On 9 May 2023, at 13:02, Alan Woodward  wrote:
> 
> I’m trying to update the website with details of the 9.6 release, and the 
> website staging build is failing with the following error messages:
> 
> remote: Error running update hook: /x1/gitbox/hooks/update.d/01-sync-repo.py  
>   
> remote: error: hook declined to update refs/heads/asf-staging
> To https://gitbox.apache.org/repos/asf/lucene-site.git
> ! [remote rejected] asf-staging -> asf-staging (hook declined)
> error: failed to push some refs to 
> 'https://gitbox.apache.org/repos/asf/lucene-site.git’
> 
> Does anybody have any idea how to debug this?


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

Building the website

[Alan Woodward]

I’m trying to update the website with details of the 9.6 release, and the 
website staging build is failing with the following error messages:

remote: Error running update hook: /x1/gitbox/hooks/update.d/01-sync-repo.py

remote: error: hook declined to update refs/heads/asf-staging
To https://gitbox.apache.org/repos/asf/lucene-site.git
 ! [remote rejected] asf-staging -> asf-staging (hook declined)
error: failed to push some refs to 
'https://gitbox.apache.org/repos/asf/lucene-site.git’

Does anybody have any idea how to debug this?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[VOTE] Release Lucene 9.6.0 RC2

[Alan Woodward]

Please vote for release candidate 2 for Lucene 9.6.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-9.6.0-RC2-rev-f94cd1750d198cd0294fb1d967c4e511a7035f1e

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-9.6.0-RC2-rev-f94cd1750d198cd0294fb1d967c4e511a7035f1e

Given weekends and UK holidays, the vote will be open until next Monday, i.e. 
until 2023-05-08 11:00 UTC.

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

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] [CANCELLED] Release Lucene 9.6.0 RC1

[Alan Woodward]

Luca found a nasty bug in SynonymQuery - 
https://github.com/apache/lucene/pull/12260.  I think this is worth a respin, 
so I will cancel the vote and build a new release candidate.

> On 3 May 2023, at 09:06, Ignacio Vera  wrote:
> 
> +1
> 
> SUCCESS! [2:07:32.970671]
> 
> On Wed, May 3, 2023 at 5:08 AM Nhat Nguyen  
> wrote:
>> +1. Thanks Alan!
>> 
>> SUCCESS! [0:48:46.465752]
>> 
>> On Tue, May 2, 2023 at 11:33 AM Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>>> Please vote for release candidate 1 for Lucene 9.6.0
>>> 
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.6.0-RC1-rev-246ac4bcbe6c0ea7bebcc4f90b2be0536f00d842
>>> 
>>> 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-9.6.0-RC1-rev-246ac4bcbe6c0ea7bebcc4f90b2be0536f00d842
>>> 
>>> It is another long holiday weekend here in the UK, so the vote is likely to 
>>> be held open until at least Monday.
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> Here is my +1
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> <mailto:dev-h...@lucene.apache.org>
>>> 

Re: New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

Thanks Ishan, turns out the error was between chair and keyboard - I’d told the 
wizard to use the gradle java plugin to sign things when I should have been 
using gpg.

> On 2 May 2023, at 14:19, Ishan Chattopadhyaya  
> wrote:
> 
> Don't remember the specifics, but I ran into GPG issues during Solr 9.1.0 
> release. The fix for me was https://github.com/apache/solr/pull/1125, but I 
> don't know if this is the same problem or if it is applicable in Lucene's 
> case.
> 
> On Tue, 2 May 2023 at 18:27, Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
>> I am fighting with gradle and GPG yet again… Gradle fails when trying to 
>> sign artefacts with the message "Cannot perform signing task 
>> ':lucene:distribution:signReleaseArchives' because it has no configured 
>> signatory”.  I have GPG configured in ~/.gradle/gradle.properties as follows:
>> 
>> org.gradle.caching=true
>> signing.keyId=
>> signing.secretKeyRingFile=/Users/romseygeek/.gnupg/secring.gpg
>> signing.gnupg.executable=gpg
>> 
>> This worked last time I did a release.  Does anybody know if anything has 
>> changed in gradle that means I need to change the properties file, or have 
>> any other ideas?
>> 
>> > On 27 Apr 2023, at 10:54, Alan Woodward > > <mailto:romseyg...@gmail.com>> wrote:
>> > 
>> > I have started a release note here: 
>> > https://cwiki.apache.org/confluence/display/LUCENE/Release+Notes+9.6
>> > 
>> >> On 27 Apr 2023, at 09:45, Alan Woodward > >> <mailto:romseyg...@gmail.com>> wrote:
>> >> 
>> >> I have successfully wrestled Jenkins into submission, and there are now 
>> >> 9.6 jobs for Artifacts, Check and NightlyTests.
>> >> 
>> >>> On 26 Apr 2023, at 16:53, Alan Woodward > >>> <mailto:romseyg...@gmail.com>> wrote:
>> >>> 
>> >>> NOTICE:
>> >>> 
>> >>> Branch branch_9_6 has been cut and versions updated to 9.7 on stable 
>> >>> branch.
>> >>> 
>> >>> Please observe the normal rules:
>> >>> 
>> >>> * No new features may be committed to the branch.
>> >>> * Documentation patches, build patches and serious bug fixes may be
>> >>> committed to the branch. However, you should submit all patches you
>> >>> want to commit as pull requests first to give others the chance to review
>> >>> and possibly vote against them. Keep in mind that it is our
>> >>> main intention to keep the branch as stable as possible.
>> >>> * All patches that are intended for the branch should first be committed
>> >>> to the unstable branch, merged into the stable branch, and then into
>> >>> the current release branch.
>> >>> * Normal unstable and stable branch development may continue as usual.
>> >>> However, if you plan to commit a big change to the unstable branch
>> >>> while the branch feature freeze is in effect, think twice: can't the
>> >>> addition wait a couple more days? Merges of bug fixes into the branch
>> >>> may become more difficult.
>> >>> * Only Github issues with Milestone 9.6
>> >>> and priority "Blocker" will delay a release candidate build.
>> >>> 
>> >>> 
>> >>> I am struggling to find the lucene Jenkins jobs on the new apache build 
>> >>> server at https://jenkins-ccos.apache.org/ - if anybody has any hints as 
>> >>> to how to navigate the helpful new interface with a non-functional 
>> >>> search box, I would be very grateful…
>> >>> 
>> >>> It’s a holiday weekend coming up in the UK, so my plan is to give 
>> >>> Jenkins a few days to chew things over (once I actually get the jobs 
>> >>> running) and then build a RC on Tuesday 2nd May.
>> >> 
>> > 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 

[VOTE] Release Lucene 9.6.0 RC1

[Alan Woodward]

Please vote for release candidate 1 for Lucene 9.6.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-9.6.0-RC1-rev-246ac4bcbe6c0ea7bebcc4f90b2be0536f00d842

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-9.6.0-RC1-rev-246ac4bcbe6c0ea7bebcc4f90b2be0536f00d842

It is another long holiday weekend here in the UK, so the vote is likely to be 
held open until at least Monday.

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

Here is my +1


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

Re: New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

I am fighting with gradle and GPG yet again… Gradle fails when trying to sign 
artefacts with the message "Cannot perform signing task 
':lucene:distribution:signReleaseArchives' because it has no configured 
signatory”.  I have GPG configured in ~/.gradle/gradle.properties as follows:

org.gradle.caching=true
signing.keyId=
signing.secretKeyRingFile=/Users/romseygeek/.gnupg/secring.gpg
signing.gnupg.executable=gpg

This worked last time I did a release.  Does anybody know if anything has 
changed in gradle that means I need to change the properties file, or have any 
other ideas?

> On 27 Apr 2023, at 10:54, Alan Woodward  wrote:
> 
> I have started a release note here: 
> https://cwiki.apache.org/confluence/display/LUCENE/Release+Notes+9.6
> 
>> On 27 Apr 2023, at 09:45, Alan Woodward  wrote:
>> 
>> I have successfully wrestled Jenkins into submission, and there are now 9.6 
>> jobs for Artifacts, Check and NightlyTests.
>> 
>>> On 26 Apr 2023, at 16:53, Alan Woodward  wrote:
>>> 
>>> NOTICE:
>>> 
>>> Branch branch_9_6 has been cut and versions updated to 9.7 on stable branch.
>>> 
>>> Please observe the normal rules:
>>> 
>>> * No new features may be committed to the branch.
>>> * Documentation patches, build patches and serious bug fixes may be
>>> committed to the branch. However, you should submit all patches you
>>> want to commit as pull requests first to give others the chance to review
>>> and possibly vote against them. Keep in mind that it is our
>>> main intention to keep the branch as stable as possible.
>>> * All patches that are intended for the branch should first be committed
>>> to the unstable branch, merged into the stable branch, and then into
>>> the current release branch.
>>> * Normal unstable and stable branch development may continue as usual.
>>> However, if you plan to commit a big change to the unstable branch
>>> while the branch feature freeze is in effect, think twice: can't the
>>> addition wait a couple more days? Merges of bug fixes into the branch
>>> may become more difficult.
>>> * Only Github issues with Milestone 9.6
>>> and priority "Blocker" will delay a release candidate build.
>>> 
>>> 
>>> I am struggling to find the lucene Jenkins jobs on the new apache build 
>>> server at https://jenkins-ccos.apache.org/ - if anybody has any hints as to 
>>> how to navigate the helpful new interface with a non-functional search box, 
>>> I would be very grateful…
>>> 
>>> It’s a holiday weekend coming up in the UK, so my plan is to give Jenkins a 
>>> few days to chew things over (once I actually get the jobs running) and 
>>> then build a RC on Tuesday 2nd May.
>> 
> 


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

Re: New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

I have started a release note here: 
https://cwiki.apache.org/confluence/display/LUCENE/Release+Notes+9.6

> On 27 Apr 2023, at 09:45, Alan Woodward  wrote:
> 
> I have successfully wrestled Jenkins into submission, and there are now 9.6 
> jobs for Artifacts, Check and NightlyTests.
> 
>> On 26 Apr 2023, at 16:53, Alan Woodward  wrote:
>> 
>> NOTICE:
>> 
>> Branch branch_9_6 has been cut and versions updated to 9.7 on stable branch.
>> 
>> Please observe the normal rules:
>> 
>> * No new features may be committed to the branch.
>> * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you
>> want to commit as pull requests first to give others the chance to review
>> and possibly vote against them. Keep in mind that it is our
>> main intention to keep the branch as stable as possible.
>> * All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into
>> the current release branch.
>> * Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch
>> while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch
>> may become more difficult.
>> * Only Github issues with Milestone 9.6
>> and priority "Blocker" will delay a release candidate build.
>> 
>> 
>> I am struggling to find the lucene Jenkins jobs on the new apache build 
>> server at https://jenkins-ccos.apache.org/ - if anybody has any hints as to 
>> how to navigate the helpful new interface with a non-functional search box, 
>> I would be very grateful…
>> 
>> It’s a holiday weekend coming up in the UK, so my plan is to give Jenkins a 
>> few days to chew things over (once I actually get the jobs running) and then 
>> build a RC on Tuesday 2nd May.
> 


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

Re: New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

I have successfully wrestled Jenkins into submission, and there are now 9.6 
jobs for Artifacts, Check and NightlyTests.

> On 26 Apr 2023, at 16:53, Alan Woodward  wrote:
> 
> NOTICE:
> 
> Branch branch_9_6 has been cut and versions updated to 9.7 on stable branch.
> 
> Please observe the normal rules:
> 
> * No new features may be committed to the branch.
> * Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you
> want to commit as pull requests first to give others the chance to review
> and possibly vote against them. Keep in mind that it is our
> main intention to keep the branch as stable as possible.
> * All patches that are intended for the branch should first be committed
> to the unstable branch, merged into the stable branch, and then into
> the current release branch.
> * Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch
> may become more difficult.
> * Only Github issues with Milestone 9.6
> and priority "Blocker" will delay a release candidate build.
> 
> 
> I am struggling to find the lucene Jenkins jobs on the new apache build 
> server at https://jenkins-ccos.apache.org/ - if anybody has any hints as to 
> how to navigate the helpful new interface with a non-functional search box, I 
> would be very grateful…
> 
> It’s a holiday weekend coming up in the UK, so my plan is to give Jenkins a 
> few days to chew things over (once I actually get the jobs running) and then 
> build a RC on Tuesday 2nd May.


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

New branch and feature freeze for Lucene 9.6.0

[Alan Woodward]

NOTICE:

Branch branch_9_6 has been cut and versions updated to 9.7 on stable branch.

Please observe the normal rules:

* No new features may be committed to the branch.
* Documentation patches, build patches and serious bug fixes may be
 committed to the branch. However, you should submit all patches you
 want to commit as pull requests first to give others the chance to review
 and possibly vote against them. Keep in mind that it is our
 main intention to keep the branch as stable as possible.
* All patches that are intended for the branch should first be committed
 to the unstable branch, merged into the stable branch, and then into
 the current release branch.
* Normal unstable and stable branch development may continue as usual.
 However, if you plan to commit a big change to the unstable branch
 while the branch feature freeze is in effect, think twice: can't the
 addition wait a couple more days? Merges of bug fixes into the branch
 may become more difficult.
* Only Github issues with Milestone 9.6
 and priority "Blocker" will delay a release candidate build.


I am struggling to find the lucene Jenkins jobs on the new apache build server 
at https://jenkins-ccos.apache.org/ - if anybody has any hints as to how to 
navigate the helpful new interface with a non-functional search box, I would be 
very grateful…

It’s a holiday weekend coming up in the UK, so my plan is to give Jenkins a few 
days to chew things over (once I actually get the jobs running) and then build 
a RC on Tuesday 2nd May.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Lucene 9.6 release

[Alan Woodward]

Hi all,

It’s been a while since our last release, and we have a number of nice 
improvements and optimisations sitting in the 9x branch.  I propose that we 
start the process for a 9.6 release, and I will volunteer to be the release 
manager.  If there are no objections, I will cut a release branch one week 
today, April 26th.

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

Re: Change score with distance SortField

[Alan Woodward]

Unfortunately this wouldn’t have worked in earlier versions of lucene where you 
could pass a SortField to the bindings API either, as that only understood 
certain types of sort - part of the reason we removed it in favour of the more 
explicit DoubleValuesSource API.

You have a few options here:
- if you want to continue to use expressions, then there is some example code 
in TestDemoExpressions that uses separate latitude and longitude fields and the 
javascript haversin function that should act as a guide.
- another option with expressions is to code up your own DoubleValuesSource 
that re-uses some of the code from LatLonPointDistanceComparator to produce the 
distance for each document from a particular point.  This is a bit of coding, 
but I can see that it would be generally useful and might be a nice contribution
- My more general recommendation would be to avoid using expressions and 
instead combine your scores using a boolean query with a 
LatLonPoint.newDistanceFeatureQuery() as a SHOULD clause.  This is likely to be 
much more efficient, particularly if you don’t need an exact total hit count, 
as feature queries can make use of skip data to avoid scoring large numbers of 
documents.

- Alan

> On 6 Feb 2023, at 09:24, Michal Hlavac  wrote:
> 
> Hi,
> 
> I would like to influence the score using geographical distance. More distant 
> documents lower the score.
> I have sort field:
> SortField geoSort = LatLonDocValuesField.newDistanceSort("location", 
> pos.getLatitude(), pos.getLongitude());
> 
> Then I tried add this sort field to SimpleBindings. I've found some code, 
> where SortField is added to SimpleBindings, but
> lucene 9.4.x API doesn't have this capability.
> 
> What is the proper way to do this?
> 
> thank you, Michal Hlavac


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

Re: Welcome Ben Trent as Lucene committer

[Alan Woodward]

Congratulations Ben!

> On 27 Jan 2023, at 15:18, Adrien Grand  wrote:
> 
> I'm pleased to announce that Ben Trent has accepted the PMC's
> invitation to become a committer.
> 
> Ben, the tradition is that new committers introduce themselves with a
> brief bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> -
> 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: Lucene 9.5.0 release

[Alan Woodward]

+1, thanks Luca!

> On 13 Jan 2023, at 09:54, Luca Cavanna  > wrote:
> 
> Hi all, 
> I'd like to propose that we release Lucene 9.5.0. There is a decent amount of 
> changes that would go into it looking at the github milestone: 
> https://github.com/apache/lucene/milestone/4 
>  . I'd volunteer to be the 
> release manager. There is one PR open listed for the 9.5 milestone: 
> https://github.com/apache/lucene/pull/11873 
>  . Is this something that we do 
> want to address before we release? Is anybody aware of outstanding work that 
> we would like to include or known blocker issues that are not listed in the 
> 9.5 milestone?
> 
> Cheers
> Luca
> 
>  
> 
> 

Re: Welcome Luca Cavanna as Lucene committer

[Alan Woodward]

Congratulations Luca!

> On 5 Oct 2022, at 18:03, Adrien Grand  wrote:
> 
> I'm pleased to announce that Luca Cavanna has accepted the PMC's
> invitation to become a committer.
> 
> Luca, the tradition is that new committers introduce themselves with a
> brief bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien


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

Re: Subject: New branch and feature freeze for Lucene 9.4.0

[Alan Woodward]

Done.  Thanks!

> On 9 Sep 2022, at 16:32, Michael Sokolov  wrote:
> 
> Hi Alan - I checked out the interval queries patch; seems pretty safe,
> please go ahead and port to 9.4.  Thanks!
> 
> Mike
> 
> On Fri, Sep 9, 2022 at 10:41 AM Alan Woodward  wrote:
>> 
>> Hi Mike,
>> 
>> I’ve opened https://github.com/apache/lucene/pull/11760 as a small bug fix 
>> PR for a problem with interval queries.  Am I OK to port this to the 9.4 
>> branch?
>> 
>> Thanks, Alan
>> 
>> On 2 Sep 2022, at 20:42, Michael Sokolov  wrote:
>> 
>> NOTICE:
>> 
>> Branch branch_9_4 has been cut and versions updated to 9.5 on stable branch.
>> 
>> Please observe the normal rules:
>> 
>> * No new features may be committed to the branch.
>> * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you
>> want to commit to Jira first to give others the chance to review
>> and possibly vote against the patch. Keep in mind that it is our
>> main intention to keep the branch as stable as possible.
>> * All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into
>> the current release branch.
>> * Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch
>> while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch
>> may become more difficult.
>> * Only Jira issues with Fix version 9.4 and priority "Blocker" will delay
>> a release candidate build.
>> 
>> -
>> 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: Subject: New branch and feature freeze for Lucene 9.4.0

[Alan Woodward]

Hi Mike, 

I’ve opened https://github.com/apache/lucene/pull/11760 
 as a small bug fix PR for a 
problem with interval queries.  Am I OK to port this to the 9.4 branch?

Thanks, Alan

> On 2 Sep 2022, at 20:42, Michael Sokolov  > wrote:
> 
> NOTICE:
> 
> Branch branch_9_4 has been cut and versions updated to 9.5 on stable branch.
> 
> Please observe the normal rules:
> 
> * No new features may be committed to the branch.
> * Documentation patches, build patches and serious bug fixes may be
>  committed to the branch. However, you should submit all patches you
>  want to commit to Jira first to give others the chance to review
>  and possibly vote against the patch. Keep in mind that it is our
>  main intention to keep the branch as stable as possible.
> * All patches that are intended for the branch should first be committed
>  to the unstable branch, merged into the stable branch, and then into
>  the current release branch.
> * Normal unstable and stable branch development may continue as usual.
>  However, if you plan to commit a big change to the unstable branch
>  while the branch feature freeze is in effect, think twice: can't the
>  addition wait a couple more days? Merges of bug fixes into the branch
>  may become more difficult.
> * Only Jira issues with Fix version 9.4 and priority "Blocker" will delay
>  a release candidate build.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: Welcome Vigya Sharma as Lucene committer

[Alan Woodward]

Congratulations and welcome, Vigya!

- Alan

> On 28 Jul 2022, at 20:44, Vigya Sharma  > wrote:
> 
> Thanks everyone for the warm welcome. It is an honor to be invited as a 
> Lucene committer, and I look forward to contributing more to the community.
> 
> A little bit about me - I currently work for the Product Search team at 
> Amazon, and am based out of the San Francisco Bay Area in California, US. 
> I am interested in a wide variety of computer science areas, and, in the last 
> few years, have focused more on distributed systems, concurrency, system 
> software and performance. Outside of tech., I like spending my time outdoors 
> - running, skiing, and long road trips. I completed my first marathon (the 
> SFMarathon) last week, and now, getting this invitation has made this month a 
> highlight of the year.
> 
> I had known that Lucene powers some of the most popular search and analytics 
> use cases across the globe, but as I've gotten more involved, the depth and 
> breadth of this software has blown my mind. I am deeply impressed by what 
> this community has built, and how it continues to work together and grow. It 
> is a great honor to be trusted with committer privileges, and I look forward 
> to learning and contributing to multiple different parts of the library.
> 
> Thank you,
> Vigya
> 
> 
> On Thu, Jul 28, 2022 at 12:20 PM Anshum Gupta  > wrote:
> Congratulations and welcome, Vigya! 
> 
> On Thu, Jul 28, 2022 at 12:34 AM Adrien Grand  > wrote:
> I'm pleased to announce that Vigya Sharma has accepted the PMC's
> invitation to become a committer.
> 
> Vigya, the tradition is that new committers introduce themselves with a
> brief bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> 
> -- 
> Anshum Gupta
> 
> 
> -- 
> - Vigya

Re: Lucene 9.3.0 release

[Alan Woodward]

+1, thanks Ignacio

> On 11 Jul 2022, at 15:02, Ignacio Vera  > wrote:
> 
> Hello!
> 
> Lucene 9.2.0 was released around 2 months ago and we are accumulating 
>  a good 
> bunch of new features, optimizations and bug fixes. Would there be support 
> for releasing Lucene 9.3 soon?
> 
> I am happy being the release manager. I did not see any issues marked 
> "blocker", but please let me know if there are any.
> 
> Thanks,
> 
>  Ignacio

Re: Finding out which fields matched the query

[Alan Woodward]

I think it depends on what information we actually want to get here.  If it’s 
just finding which fields matched in which document, then running Matches over 
the top-k results is fine.  If you want to get some kind of aggregate data, as 
in you want to get a list of fields that matched in *any* document (or 
conversely, a list of fields that *didn’t* match - useful if you want to prune 
your schema, for example), then Matches will be too slow.  But at the same 
time, queries are designed to tell you which *documents* match efficiently, and 
they are allowed to advance their sub-queries lazily or indeed not at all if 
the result isn’t needed for scoring.  So we don’t really have any way of 
finding this kind of information via a collector that is accurate and performs 
reasonably.

It *might* be possible to rework Matches so that they act more like an iterator 
and maintain their state within a segment, but there hasn’t been a pressing 
need for that so far.

> On 27 Jun 2022, at 12:46, Shai Erera  <mailto:ser...@gmail.com>> wrote:
> 
> Thanks Alan, yeah I guess I was thinking about the usecase I described, which 
> involves (usually) simple term queries, but you're definitely right about 
> complex boolean clauses as well non-term queries.
> 
> I think the case for highlighter is different though? I mean you usually 
> generate highlights only for the top-K results and therefore are probably 
> less affected by whether the matches() API is slower than a Collector. And if 
> you invoke the API for every document in the index, it might be much slower 
> (depending on the index size) than the Collector.
> 
> Maybe a hybrid approach which runs the query and caches the docs in a 
> DocIdSet (like FacetsCollector does) and then invokes the matches() API only 
> on those hits, will let you enjoy the best of both worlds? Assuming though 
> that the number of matching documents is not huge.
> 
> So it seems there are several options and one should choose based on their 
> usecase. Do you see an advantage for Lucene to offer a Collector for this 
> usecase? Or should we tell users to use the matches API
> 
> Shai
> 
> On Mon, Jun 27, 2022 at 2:22 PM Dawid Weiss  <mailto:dawid.we...@gmail.com>> wrote:
> A side note - I've been using a highlighter based on matches API for
> quite some time now and it's been fantastic. Very precise and handles
> non-trivial queries (interval queries) very well.
> 
> https://lucene.apache.org/core/9_2_0/highlighter/org/apache/lucene/search/matchhighlight/package-summary.html
>  
> <https://lucene.apache.org/core/9_2_0/highlighter/org/apache/lucene/search/matchhighlight/package-summary.html>
> 
> Dawid
> 
> On Mon, Jun 27, 2022 at 1:10 PM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> >
> > Your approach is almost certainly more efficient, but it might give you 
> > false matches in some cases - for example, if you have a complex query with 
> > many nested MUST and SHOULD clauses, you can have a leaf TermScorer that is 
> > positioned on the correct document, but which is part of a clause that 
> > doesn’t actually match.  It also only works for term queries, so it won’t 
> > match phrases or span/interval groups.  And Matches will work on points or 
> > docvalues queries as well.  The reason I added Matches in the first place 
> > was precisely to handle these weird corner cases - I had written 
> > highlighters which more or less did the same thing you describe with a 
> > Collector and the Scorable tree, and I would occasionally get bad 
> > highlights back.
> >
> > On 27 Jun 2022, at 10:51, Shai Erera  > <mailto:ser...@gmail.com>> wrote:
> >
> > Out of curiosity and for education purposes, is the Collector approach I 
> > proposed wrong/inefficient? Or less efficient than the matches() API?
> >
> > I'm thinking, if you want to both match/rank documents and as a side effect 
> > know which fields matched, the Collector will perform better than 
> > Weight.matches(), but I could be wrong.
> >
> > Shai
> >
> > On Mon, Jun 27, 2022 at 11:57 AM Dawid Weiss  > <mailto:dawid.we...@gmail.com>> wrote:
> >>
> >> The matches API is awesome. Use it. You can also get a rough glimpse
> >> into a superset of fields potentially matching the query via:
> >>
> >> query.visit(
> >> new QueryVisitor() {
> >>   @Override
> >>   public boolean acceptField(String field) {
> >> affectedFields.add(field);
> >> return false;
> >>   }
> >> });
> >>
> >> https://lucene.apache.org/core/9_2_0/core/org/apac

Re: Finding out which fields matched the query

[Alan Woodward]

Your approach is almost certainly more efficient, but it might give you false 
matches in some cases - for example, if you have a complex query with many 
nested MUST and SHOULD clauses, you can have a leaf TermScorer that is 
positioned on the correct document, but which is part of a clause that doesn’t 
actually match.  It also only works for term queries, so it won’t match phrases 
or span/interval groups.  And Matches will work on points or docvalues queries 
as well.  The reason I added Matches in the first place was precisely to handle 
these weird corner cases - I had written highlighters which more or less did 
the same thing you describe with a Collector and the Scorable tree, and I would 
occasionally get bad highlights back.

> On 27 Jun 2022, at 10:51, Shai Erera  wrote:
> 
> Out of curiosity and for education purposes, is the Collector approach I 
> proposed wrong/inefficient? Or less efficient than the matches() API?
> 
> I'm thinking, if you want to both match/rank documents and as a side effect 
> know which fields matched, the Collector will perform better than 
> Weight.matches(), but I could be wrong.
> 
> Shai
> 
> On Mon, Jun 27, 2022 at 11:57 AM Dawid Weiss  <mailto:dawid.we...@gmail.com>> wrote:
> The matches API is awesome. Use it. You can also get a rough glimpse
> into a superset of fields potentially matching the query via:
> 
> query.visit(
> new QueryVisitor() {
>   @Override
>   public boolean acceptField(String field) {
> affectedFields.add(field);
> return false;
>   }
> });
> 
> https://lucene.apache.org/core/9_2_0/core/org/apache/lucene/search/Query.html#visit(org.apache.lucene.search.QueryVisitor)
>  
> <https://lucene.apache.org/core/9_2_0/core/org/apache/lucene/search/Query.html#visit(org.apache.lucene.search.QueryVisitor)>
> 
> I'd go with the Matches API though.
> 
> Dawid
> 
> On Mon, Jun 27, 2022 at 10:48 AM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> >
> > The Matches API will give you this information - it’s still likely to be 
> > fairly slow, but it’s a lot easier to use than trying to parse Explain 
> > output.
> >
> > Query q = ….;
> > Weight w = searcher.createWeight(searcher.rewrite(query), 
> > ScoreMode.COMPLETE_NO_SCORES, 1.0f);
> >
> > Matches m = w.matches(context, doc);
> > List matchingFields = new ArrayList();
> > for (String field : m) {
> >  matchingFields.add(field);
> > }
> >
> > Bear in mind that `matches` doesn’t maintain any state between calls, so 
> > calling it for every matching document is likely to be slow; for those 
> > cases Shai’s suggestion of using a Collector and examining low-level 
> > scorers will perform better, but it won’t work for every query type.
> >
> >
> > > On 25 Jun 2022, at 04:14, Yichen Sun  > > <mailto:yiche...@bu.edu>> wrote:
> > >
> > > Hello!
> > >
> > > I’m a MSCS student from BU and learning to use Lucene. Recently I try to 
> > > output matched fields by one query. For example, for one document, there 
> > > are 10 fields and 2 of them match the query. I want to get the name of 
> > > these fields.
> > >
> > > I have tried using explain() method and getting description then regex. 
> > > However it cost so much time.
> > >
> > > I wonder what is the efficient way to get the matched fields. Would you 
> > > please offer some help? Thank you so much!
> > >
> > > Best regards,
> > > Yichen Sun
> >
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > <mailto:dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > <mailto:dev-h...@lucene.apache.org>
> >
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 

Re: Finding out which fields matched the query

[Alan Woodward]

The Matches API will give you this information - it’s still likely to be fairly 
slow, but it’s a lot easier to use than trying to parse Explain output.

Query q = ….;
Weight w = searcher.createWeight(searcher.rewrite(query), 
ScoreMode.COMPLETE_NO_SCORES, 1.0f);

Matches m = w.matches(context, doc);
List matchingFields = new ArrayList();
for (String field : m) {
 matchingFields.add(field);
}

Bear in mind that `matches` doesn’t maintain any state between calls, so 
calling it for every matching document is likely to be slow; for those cases 
Shai’s suggestion of using a Collector and examining low-level scorers will 
perform better, but it won’t work for every query type.


> On 25 Jun 2022, at 04:14, Yichen Sun  wrote:
> 
> Hello!
> 
> I’m a MSCS student from BU and learning to use Lucene. Recently I try to 
> output matched fields by one query. For example, for one document, there are 
> 10 fields and 2 of them match the query. I want to get the name of these 
> fields.
> 
> I have tried using explain() method and getting description then regex. 
> However it cost so much time.
> 
> I wonder what is the efficient way to get the matched fields. Would you 
> please offer some help? Thank you so much!
> 
> Best regards,
> Yichen Sun


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

[ANNOUNCE] Apache Lucene 9.2.0 released

[Alan Woodward]

23 May 2022 - Apache Lucene™ 9.2.0 available 

The Lucene PMC is pleased to announce the release of Apache Lucene 9.2.0.

Apache Lucene is a high-performance, full-featured search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires structured search, full-text search, faceting, 
nearest-neighbor search across high-dimensionality vectors, spell correction or 
query suggestions.

This release contains numerous bug fixes, optimizations, and improvements, some 
of which are highlighted below. The release is available for immediate download 
at:
https://lucene.apache.org/core/downloads.html

Lucene 9.2.0 Release Highlights:
• Numerous improvements to indexing and query performance for KNN 
vectors
• More efficient implementations for count operations on range queries
• A new FieldExistsQuery that chooses the best index structures to run 
over for you
• A new Persian stemmer

Please read CHANGES.txt for a full list of new features and changes:

https://lucene.apache.org/core/9_2_0/changes/Changes.html

Note: The Apache Software Foundation uses an extensive mirroring network for
distributing releases. It is possible that the mirror you are using may not have
replicated the release yet. If that is the case, please try another mirror.
This also applies to Maven access.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[RESULT] [VOTE] Release Lucene 9.2.0 RC2

[Alan Woodward]

It's been >72h since the vote was initiated and the result is:

+1  10  (8 binding)
0  0
-1  0

This vote has PASSED

Thanks to everyone who voted!

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

[VOTE] Release Lucene 9.2.0 RC2

[Alan Woodward]

Please vote for release candidate 2 for Lucene 9.2.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC2-rev-ba8c3a806ada3d7b3c34d408e449a92376a8481b

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-9.2.0-RC2-rev-ba8c3a806ada3d7b3c34d408e449a92376a8481b

The vote will be open until 2022-05-23 16:00 UTC.

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

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] [CANCELLED] Release Lucene 9.2.0 RC1

[Alan Woodward]

Thanks to Tomoko for fixing this quickly.  I’ll cancel the vote for RC1 and 
prepare a new release candidate.

> On 19 May 2022, at 04:10, Tomoko Uchida  <mailto:tomoko.uchida.1...@gmail.com>> wrote:
> 
> Alan noticed a backward compatibility issue in LUCENE-10312 and I'm working 
> on it.
> I think respin would be needed - sorry for the additional work.
> 
> Tomoko
> 
> 
> 2022年5月19日(木) 9:02 Patrick Zhai  <mailto:zhai7...@gmail.com>>:
> +1 SUCCESS! [1:12:17.482213]
> 
> Thank you Alan!
> 
> On Wed, May 18, 2022 at 4:31 PM Julie Tibshirani  <mailto:juliet...@gmail.com>> wrote:
> +1 SUCCESS! [0:57:28.654665]
> 
> Thanks Alan!
> 
> On Wed, May 18, 2022 at 1:51 PM Anshum Gupta  <mailto:ans...@anshumgupta.net>> wrote:
> +1 SUCCESS! [0:59:19.002348]
> 
> On Wed, May 18, 2022 at 5:59 AM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> Please vote for release candidate 1 for Lucene 9.2.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0>
> 
> 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-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0>
> 
> Given that we have a weekend coming up, the vote will be open for at least 5 
> days i.e. until 2022-05-23 13:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 
> 
> 
> -- 
> Anshum Gupta

[VOTE] Release Lucene 9.2.0 RC1

[Alan Woodward]

Please vote for release candidate 1 for Lucene 9.2.0

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0

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-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0

Given that we have a weekend coming up, the vote will be open for at least 5 
days i.e. until 2022-05-23 13:00 UTC.

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

Here is my +1
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene 9.2 release

[Alan Woodward]

I think this release is the first time I’ve used Java 11 since 2019, yes!

I’ll get the latest AdoptOpenJDK version and try and persuade my Mac to use 
it...

> On 18 May 2022, at 10:19, Dawid Weiss  wrote:
> 
> Living in the past, aren't we? :)
> 
> D.
> 
> On Wed, May 18, 2022 at 10:49 AM Alan Woodward  wrote:
>> 
>> $ /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java 
>> -version
>> 
>> openjdk version "11" 2018-09-25
>> OpenJDK Runtime Environment 18.9 (build 11+28)
>> OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)
>> 
>> 
>>> On 18 May 2022, at 09:35, Dawid Weiss  wrote:
>>> 
>>> Alan, what's the exact JDK vendor/ release number you used that had
>>> this problem? If we can reproduce it then we'd know where to look
>>> (bisect until we know javadoc works correctly).
>>> 
>>> D.
>>> 
>>> On Wed, May 18, 2022 at 10:33 AM Dawid Weiss  wrote:
>>>> 
>>>>> I'd like to draw attention to my second question while we are still 
>>>>> here... should we limit the OpenJDK distribution (for building)? My worry 
>>>>> here is, that minor versions could depend on the distributor.
>>>> 
>>>> This is a valid concern but it'd take some trial and error to verify
>>>> which version numbers are used by packaging openjdk for various
>>>> releases. Realistically, the JDK part (standard library) is nearly the
>>>> same in all/ most of them? The least that could be done is to apply
>>>> the restriction to just a particular vendor/ release and emit a
>>>> warning for unrecognized ones.
>>>> 
>>>> Dawid
>> 


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

Re: Lucene 9.2 release

[Alan Woodward]

$ /Library/Java/JavaVirtualMachines/jdk-11.jdk/Contents/Home/bin/java -version

openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)


> On 18 May 2022, at 09:35, Dawid Weiss  wrote:
> 
> Alan, what's the exact JDK vendor/ release number you used that had
> this problem? If we can reproduce it then we'd know where to look
> (bisect until we know javadoc works correctly).
> 
> D.
> 
> On Wed, May 18, 2022 at 10:33 AM Dawid Weiss  wrote:
>> 
>>> I'd like to draw attention to my second question while we are still here... 
>>> should we limit the OpenJDK distribution (for building)? My worry here is, 
>>> that minor versions could depend on the distributor.
>> 
>> This is a valid concern but it'd take some trial and error to verify
>> which version numbers are used by packaging openjdk for various
>> releases. Realistically, the JDK part (standard library) is nearly the
>> same in all/ most of them? The least that could be done is to apply
>> the restriction to just a particular vendor/ release and emit a
>> warning for unrecognized ones.
>> 
>> Dawid


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

Re: New branch and feature freeze for Lucene 9.2.0

[Alan Woodward]

Thanks Uwe!

> On 16 May 2022, at 17:39, Uwe Schindler  wrote:
> 
> Hi,
> 
> I enabled Policeman Jenkins builds of 9.2.
> 
> I will enable ASF Jenkins, too. Takes a few minutes.
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Alan Woodward 
>> Sent: Monday, May 16, 2022 3:59 PM
>> To: dev@lucene.apache.org
>> Subject: New branch and feature freeze for Lucene 9.2.0
>> 
>> NOTICE:
>> 
>> Branch branch_9_2 has been cut and versions updated to 9.3 on stable branch.
>> 
>> Please observe the normal rules:
>> 
>> * No new features may be committed to the branch.
>> * Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you
>> want to commit to Jira first to give others the chance to review
>> and possibly vote against the patch. Keep in mind that it is our
>> main intention to keep the branch as stable as possible.
>> * All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into
>> the current release branch.
>> * Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch
>> while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch
>> may become more difficult.
>> * Only Jira issues with Fix version 9.2 and priority "Blocker" will delay
>> a release candidate build.
>> 
>> I’ve added Jenkins builds for the new 9.2.0 version. I’ll start working on 
>> release
>> notes, and I plan to try and build a release candidate in the next couple of 
>> days.
>> 
>> Thanks, Alan
>> -
>> 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: Lucene 9.2 release

[Alan Woodward]

It was part of the release process, which runs with Java 11.  It should be 
fixed now.

> Newer java versions won't make a broken link, you just won't have a link at 
> all.

This seems a bit of a shame, as some of the problems were genuine API bugs - 
public methods with package-private parameter classes, and so on.  Do we have 
other ways of detecting these? Warning levels on the compiler maybe?

> On 16 May 2022, at 18:14, Uwe Schindler  wrote:
> 
> Hi,
> 
> Jenkins runs with JDK 11, so it should hit that problem. Was this in smoke 
> tester or during normal gradle build?
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Robert Muir 
>> Sent: Monday, May 16, 2022 3:30 PM
>> To: dev@lucene.apache.org
>> Subject: Re: Lucene 9.2 release
>> 
>> On Mon, May 16, 2022 at 9:28 AM Dawid Weiss 
>> wrote:
>>> - different jvms producing different javadoc? Could this be the cause?
>>> 
>> 
>> This is it, it is always a bug when javadoc produces broken links like
>> this. It happens "at release time" because otherwise nobody is messing
>> with java 11.
>> 
>> Newer java versions won't make a broken link, you just won't have a link at 
>> all.
>> 
>> -
>> 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

New branch and feature freeze for Lucene 9.2.0

[Alan Woodward]

NOTICE:

Branch branch_9_2 has been cut and versions updated to 9.3 on stable branch.

Please observe the normal rules:

* No new features may be committed to the branch.
* Documentation patches, build patches and serious bug fixes may be
committed to the branch. However, you should submit all patches you
want to commit to Jira first to give others the chance to review
and possibly vote against the patch. Keep in mind that it is our
main intention to keep the branch as stable as possible.
* All patches that are intended for the branch should first be committed
to the unstable branch, merged into the stable branch, and then into
the current release branch.
* Normal unstable and stable branch development may continue as usual.
However, if you plan to commit a big change to the unstable branch
while the branch feature freeze is in effect, think twice: can't the
addition wait a couple more days? Merges of bug fixes into the branch
may become more difficult.
* Only Jira issues with Fix version 9.2 and priority "Blocker" will delay
a release candidate build.

I’ve added Jenkins builds for the new 9.2.0 version. I’ll start working on 
release notes, and I plan to try and build a release candidate in the next 
couple of days.

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

Re: Lucene 9.2 release

[Alan Woodward]

Hi all,

I was ill at the end of last week so this took a little longer than expected! 
I’ve started the release process using the wizard, which has found some broken 
links in javadoc.  Somewhat strangely, these broken links don’t seem to be 
found when not running from a clean checkout, which suggests that there’s 
something being cached somewhere?  I’ll open a PR to fix the immediate problem 
but I’ll see if I can work out what’s going on with those links not being 
picked up during normal development - it’s not ideal if we only find these 
problems when preparing a release.

- A

> On 12 May 2022, at 21:11, Mayya Sharipova  <mailto:mayya.sharip...@elastic.co.INVALID>> wrote:
> 
> Hi Alan,
> I want to report that all scheduled changes to vectors' format have been 
> merged to 9.x, and from our side we are good to proceed with the 9.2 release. 
> Sorry for the delay and thank you for waiting.
> 
> On Tue, May 10, 2022 at 9:24 AM Mayya Sharipova  <mailto:mayya.sharip...@elastic.co>> wrote:
> Hi Alan,
> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872 
> <https://github.com/apache/lucene/pull/872>) in progress that involve format 
> changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I can 
> update here once these PRs are merged.
> 
> Thank you in advance
> 
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida  <mailto:tomoko.uchida.1...@gmail.com>> wrote:
> +1
> 
> Thank you Alan!
> 
> I wonder if it makes sense to include in the highlighted updates that pull 
> requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and there 
> is a related issue https://issues.apache.org/jira/browse/LUCENE-10543 
> <https://issues.apache.org/jira/browse/LUCENE-10543>, an announcement could 
> be helpful to proceed with it (if it gains basic agreement among committers). 
> 
> Tomoko
> 
> 
> 2022年5月4日(水) 2:26 Ignacio Vera mailto:iver...@gmail.com>>:
> +1 
> 
> Thanks Alan!
> 
> > On 3. May 2022, at 13:01, Alan Woodward  > <mailto:romseyg...@gmail.com>> wrote:
> > 
> > Hi all,
> > 
> > It’s been six weeks or so since we released 9.1, and we have a bunch of 
> > nice new features and enhancements piling up in the 9.x branch.  I’d like 
> > to volunteer to be a release manager for a 9.2 release.  I propose to cut a 
> > branch this time next week, 10th May.
> > 
> > - Alan
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > <mailto:dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > <mailto:dev-h...@lucene.apache.org>
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 

Re: Lucene 9.2 release

[Alan Woodward]

Hi Mayya,

Yes, that’s fine.  I will hold off until you have merged those two PRs.

- Alan

> On 10 May 2022, at 14:24, Mayya Sharipova  <mailto:mayya.sharip...@elastic.co.INVALID>> wrote:
> 
> Hi Alan,
> we have PRs (870 <https://github.com/apache/lucene/pull/870>, 872 
> <https://github.com/apache/lucene/pull/872>) in progress that involve format 
> changes to vectors. We would like to merge them for 9.2.
> Would it be possible to wait for a couple of days for the branch cut? I can 
> update here once these PRs are merged.
> 
> Thank you in advance
> 
> On Wed, May 4, 2022 at 2:59 AM Tomoko Uchida  <mailto:tomoko.uchida.1...@gmail.com>> wrote:
> +1
> 
> Thank you Alan!
> 
> I wonder if it makes sense to include in the highlighted updates that pull 
> requests to the github repository no longer require Jira issues?
> I'm trying to adjust the contribution workflow more GitHub-oriented and there 
> is a related issue https://issues.apache.org/jira/browse/LUCENE-10543 
> <https://issues.apache.org/jira/browse/LUCENE-10543>, an announcement could 
> be helpful to proceed with it (if it gains basic agreement among committers). 
> 
> Tomoko
> 
> 
> 2022年5月4日(水) 2:26 Ignacio Vera mailto:iver...@gmail.com>>:
> +1 
> 
> Thanks Alan!
> 
> > On 3. May 2022, at 13:01, Alan Woodward  > <mailto:romseyg...@gmail.com>> wrote:
> > 
> > Hi all,
> > 
> > It’s been six weeks or so since we released 9.1, and we have a bunch of 
> > nice new features and enhancements piling up in the 9.x branch.  I’d like 
> > to volunteer to be a release manager for a 9.2 release.  I propose to cut a 
> > branch this time next week, 10th May.
> > 
> > - Alan
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> > <mailto:dev-unsubscr...@lucene.apache.org>
> > For additional commands, e-mail: dev-h...@lucene.apache.org 
> > <mailto:dev-h...@lucene.apache.org>
> > 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 

Re: XML retrieval with Intervals

[Alan Woodward]

I *think* it would be possible to write an IntervalsSource implementation that 
took opening and closing tags, and did the right thing here - as you say, a 
standard `contains` will try and minimise things, but you could write something 
that attempted to match an opening tag with its corresponding closing tag by 
taking into account how many other opening tags there are before the next 
closing tag.  You’d need to do some caching to handle the look-ahead aspect but 
I don’t think that would be too tricky.

It’s a fun idea to think about, I’ll see if I can come up with something over 
the weekend :)

> On 6 May 2022, at 10:22, Mikhail Khludnev  wrote:
> 
> Hi Devs!
> 
> I found intervals quite nice and natural for retrieving scoped data (thanks, 
> Alan!): 
> foo stuff bar
> I.containing(I.ordered(I.term(""), I.term("")), 
>   I.unordered(I.term("bar"), I.term("foo")));
> It works like a charm until it encounter ill nested tags:
> foo bug bar
> Due to intrinsic minimalizations it picks the internal tag. I feel like plain 
> intervals backed on positions lack tag scoping information. 
> Do you know any approaches for retrieving XML in Lucene?  
> 
> -- 
> Sincerely yours
> Mikhail Khludnev


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

Lucene 9.2 release

[Alan Woodward]

Hi all,

It’s been six weeks or so since we released 9.1, and we have a bunch of nice 
new features and enhancements piling up in the 9.x branch.  I’d like to 
volunteer to be a release manager for a 9.2 release.  I propose to cut a branch 
this time next week, 10th May.

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

Re: Monitor enhancements

[Alan Woodward]

These sound like nice improvements to me! I don’t know that anyone is actively 
working on Monitor stuff at the moment so please feel free open PRs or create 
patches.

> On 11 Feb 2022, at 08:41, Niko Usai  wrote:
> 
> Hi all,
> 
> I'm working on a project where I use very heavily Lucene Monitor package, but 
> I miss some features that I intend to implement and make a PR on main project.
> 
> Before start to do it, I wanted to check if it makes sense for you or if 
> something is already on the way to be developed or not.
> 
> What I miss is some simple things in how Monitor manages it's Directory, 
> IndexWriter and IndexReader, what I want to do is extend MonitorConfiguration 
> to make possible mainly these two things:
>   • option to use a custom Directory implementation 
>   • option to have a readonly QueryIndex in order to have more Monitor 
> instance on different server reading from the same index (now the index 
> reader is created from the index writer so it is impossible to make a 
> readonly Monitor)
> 
> Is this something worth contributing ? what do you think?
> 
> 
> m0gui - Keep calm & code in C
> ---
> pub   1024D/3BF6890C
> Key fingerprint = CEDD 4512 3248 4C9C 2493 FE56 2E55 A884 3BF6 890C
> server: pgp.mit.edu
> -
> 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: Welcome Guo Feng as Lucene committer

[Alan Woodward]

Congratulations and Welcome!

> On 25 Jan 2022, at 09:09, Adrien Grand  wrote:
> 
> I'm pleased to announce that Guo Feng has accepted the PMC's
> invitation to become a committer.
> 
> Feng, the tradition is that new committers introduce themselves with a
> brief bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien
> 
> -
> 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: gradlew check failure

[Alan Woodward]

AIUI no, it’s a problem when loading gradle’s JVM, but Dawid might have a 
better idea?

> On 24 Jan 2022, at 13:50, Mike Drob  wrote:
> 
> Is there a way to check for these missing module exports early and fail with 
> a more informative message?
> 
> On Mon, Jan 24, 2022 at 7:42 AM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> Hey Joel,
> 
> The fix for this is to delete the gradle.properties file in the root 
> directory and stop any daemons before running gradle check again.  The build 
> will regenerate the gradle.properties file with some module exports that work 
> around this problem in the formatter.
> 
> - A
> 
>> On 24 Jan 2022, at 13:33, Joel Bernstein > <mailto:joels...@gmail.com>> wrote:
>> 
>> Hi.
>> 
>> I'm getting the following gradlew check failure with Java 17 on the lucene 
>> main branch:
>> 
>> Caused by: java.lang.IllegalAccessError: class 
>> com.google.googlejavaformat.java.JavaInput (in unnamed module @0x3d6a6107) 
>> cannot access class com.sun.tools.javac.parser.Tokens$TokenKind (in module 
>> jdk.compiler) because module jdk.compiler does not export 
>> com.sun.tools.javac.parser to unnamed module @0x3d6a6107
>> at 
>> com.google.googlejavaformat.java.JavaInput.buildToks(JavaInput.java:349)
>> at 
>> com.google.googlejavaformat.java.JavaInput.buildToks(JavaInput.java:334)
>> at 
>> com.google.googlejavaformat.java.JavaInput.(JavaInput.java:276)
>> at 
>> com.google.googlejavaformat.java.Formatter.getFormatReplacements(Formatter.java:280)
>> at 
>> com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:267)
>> at 
>> com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:233)
>> ... 142 more
>> 
>> Is there a step I'm missing in the setup process?
>> 
>> Thanks,
>> Joel
>> 
> 

Re: gradlew check failure

[Alan Woodward]

Hey Joel,

The fix for this is to delete the gradle.properties file in the root directory 
and stop any daemons before running gradle check again.  The build will 
regenerate the gradle.properties file with some module exports that work around 
this problem in the formatter.

- A

> On 24 Jan 2022, at 13:33, Joel Bernstein  > wrote:
> 
> Hi.
> 
> I'm getting the following gradlew check failure with Java 17 on the lucene 
> main branch:
> 
> Caused by: java.lang.IllegalAccessError: class 
> com.google.googlejavaformat.java.JavaInput (in unnamed module @0x3d6a6107) 
> cannot access class com.sun.tools.javac.parser.Tokens$TokenKind (in module 
> jdk.compiler) because module jdk.compiler does not export 
> com.sun.tools.javac.parser to unnamed module @0x3d6a6107
> at 
> com.google.googlejavaformat.java.JavaInput.buildToks(JavaInput.java:349)
> at 
> com.google.googlejavaformat.java.JavaInput.buildToks(JavaInput.java:334)
> at 
> com.google.googlejavaformat.java.JavaInput.(JavaInput.java:276)
> at 
> com.google.googlejavaformat.java.Formatter.getFormatReplacements(Formatter.java:280)
> at 
> com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:267)
> at 
> com.google.googlejavaformat.java.Formatter.formatSource(Formatter.java:233)
> ... 142 more
> 
> Is there a step I'm missing in the setup process?
> 
> Thanks,
> Joel
> 

Re: Welcome Julie Tibshirani to the Lucene PMC

[Alan Woodward]

Congratulations and welcome!

- Alan

> On 30 Nov 2021, at 21:49, Adrien Grand  wrote:
> 
> I'm pleased to announce that Julie Tibshirani has accepted an invitation to 
> join the Lucene PMC!
> 
> Congratulations Julie, and welcome aboard!
> 
> -- 
> Adrien


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

Warnings from gradle rat task

[Alan Woodward]

Hi all,

When running `./gradlew check` against the latest master I get a whole bunch of 
output messages like this:

> Task :lucene:analysis:smartcn:rat
Trying to override old definition of task javadoc

> Task :lucene:analysis:stempel:rat
Trying to override old definition of task javadoc

> Task :lucene:analysis:common:rat
Trying to override old definition of task javadoc

I don’t think it’s breaking anything but it’s a bit disconcerting.  Maybe 
something to do with a gradle upgrade?

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

Re: Slow DV equivalent of TermInSetQuery

[Alan Woodward]

We have SortedSetDocValuesField.newSlowRangeQuery() which does something close 
to what you want here, I think.

> On 26 Oct 2021, at 15:23, Michael McCandless  > wrote:
> 
> Hi Team,
> 
> I was discussing this problem with Greg Miller (also at Amazon Product 
> Search):
> 
> If I want to make a query that filters out a few primary keys (ASIN in our 
> Amazon Product Search world), I can make a TermInSetQuery and add it as a 
> MUST_NOT onto a BooleanQuery that has all the other interesting clauses for 
> my query.
> 
> But if I have many, many ASINs to filter out, at some point it may become 
> more efficient to just use doc values and filter them out like Solr's 
> "post-filter" / during collection, e.g. by loading the BINARY value or SORTED 
> (globalized) ordinal, and checking e.g. a HashSet to see if it should be 
> skipped.  Not using the inverted index at all...
> 
> Do we already have such a "slow DV TermInSet" query?
> 
> It seems like it could belong in SortedDocValues where we already have 
> newSlowRangeQuery, newSlowExactQuery, we could add a newSlowInSetQuery?
> 
> And then we could make an IndexOrDocValuesQuery with both the TermInSetQuery 
> and this SDV.newSlowInSetQuery?
> 
> Or maybe there is already a good way to do this in Lucene?
> 
> Thanks!,
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com 

Re: Welcome Michael Gibney as Lucene committer

[Alan Woodward]

Congratulations and welcome, Michael!

> On 6 Oct 2021, at 14:33, Dawid Weiss  wrote:
> 
> Hello everyone!
> 
> Please welcome Michael Gibney as the latest Lucene committer. Michael
> - it's a tradition for you to introduce yourself, even if we've been
> seeing you for quite a while! :)
> 
> Dawid
> 
> -
> 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: Now that 8.10 is out ... let's get rolling on 9!

[Alan Woodward]

+1 to start pushing for a 9.0 release.

There isn’t an 8.10 version constant in the 9.0 branch at the moment - are 
there some release tasks that have been missed?

> On 29 Sep 2021, at 17:58, Timothy Potter  wrote:
> 
> Hi Folks,
> 
> Having just finished up the 8.10 release, it feels like this is a good
> time to start pushing harder for a 9.0 release.
> 
> There are so many improvements in the 9 (main) branches and
> backporting features to 8x is becoming onerous. I realize Solr needs a
> Lucene 9 release before it can proceed. I'm seeing one open blocker on
> the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638
> 
> Can we at least start to nail down a more concrete timeline on a 9.0 release?
> 
> Cheers,
> Tim
> 
> -
> 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: Accessibility of QueryParserBase::handleBareFuzzy

[Alan Woodward]

Hi Chris,

The difference between the elasticsearch query parser and the built-in lucene 
one appears to be based around how they parse fuzziness, so I think the best 
solution here is to add another protected method, something like this:

protected float parseFuzzyDistance(String input, float default) {
try {
return Float.parseFloat(fuzzySlop.image.substring(1));
} catch (@SuppressWarnings("unused”) Exception ignored) {
return default;
}
}

Then handleBareFuzzy() can call out to this, and the ES version can overload it 
and do its own parsing.

- A

> On 20 Sep 2021, at 15:39, Chris Hegarty 
>  wrote:
> 
> Hi, 
> 
> In an effort to prepare Elasticsearch for modularization, we are
> investigating and eliminating split packages. The situation has improved
> through recent refactoring in Lucene 9.0 [1], but a number of split
> packages still remain. This message identifies one such so that it can
> be discussed in isolation, with a view to a potential solution either in
> Lucene or possibly within Elasticsearch itself.
> 
> Elasticsearch has a query parser, `QueryStringQueryParser`[2], that
> builds queries based on mapping information. This parser has a need to
> override its superclass's 
> `org.apache.lucene.queryparser.classic.QueryParserBase::handleBareFuzzy` [3]
> method, in order to provide custom handling of fuzzy queries. This is
> clearly not "best practice", since to do so requires the use of
> effectively (but not literally) injecting into a lucene package, which
> is done through `XQueryParser` [4]. We want to eliminate the need for
> `XQueryParser`, and hence the split package at run time.
> 
> Clearly, but likely not right, we could simply make `handleBareFuzzy` a
> a protected method in Lucene's `QueryParser` or `QueryParserBase` - this
> would satisfy the need of the Elasticsearch `QueryStringQueryParser`. If
> not this, I don't see an alternative that could be coded in
> Elasticsearch's `QueryStringQueryParser`, but maybe there is a different
> API extension point that could be used, or a new one provided?
> 
> -Chris.
> 
> [1] https://issues.apache.org/jira/browse/LUCENE-9319
> [2] 
> https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/elasticsearch/index/search/QueryStringQueryParser.java#L436
> [3] 
> https://github.com/apache/lucene/blob/8ac26737913d0c1555019e93bc6bf7db1ab9047e/lucene/queryparser/src/java/org/apache/lucene/queryparser/classic/QueryParserBase.java#L813
> [4] 
> https://github.com/elastic/elasticsearch/blob/master/server/src/main/java/org/apache/lucene/queryparser/classic/XQueryParser.java
> 
> 
> -
> 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: getField vs getDeclaredField in analysis SPI

[Alan Woodward]

Thanks for opening the issue Uwe! I agree that option #1 is the best long term 
fix (although for the moment I’ve wrapped the relevant ES code in a 
doPrivileged block which solves the immediate problem).

> Is Elasticsearch now using the Analysis Factory framework instead of their 
> own factories?

No, we still have our own factory implementations.  In fact, looking more 
closely at this, I don’t think we need to call these reload SPI methods at all 
and I can probably remove it entirely :) Still, it found a possible bug!


> On 13 Sep 2021, at 12:48, Uwe Schindler  wrote:
> 
> See https://issues.apache.org/jira/browse/LUCENE-10101
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Uwe Schindler 
>> Sent: Monday, September 13, 2021 9:59 AM
>> To: dev@lucene.apache.org
>> Subject: RE: getField vs getDeclaredField in analysis SPI
>> 
>> Hi Alan,
>> 
>> I will open an issue about this!
>> 
>> Uwe
>> 
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>> 
>>> -Original Message-
>>> From: Uwe Schindler 
>>> Sent: Monday, September 6, 2021 4:57 PM
>>> To: dev@lucene.apache.org
>>> Subject: RE: getField vs getDeclaredField in analysis SPI
>>> 
>>> Hi Alan,
>>> 
>>> Would you open issue, I will take it!?
>>> 
>>> Maybe also post your opinion about think fix #1 or fix #2 is better. I tend 
>>> to
>> go
>>> for fix #1. getDeclaredField() should theoretically be faster, but that 
>>> won't
>>> matter here: If it goes the slow path (going up to superclass) it will fail
>> anyways
>>> and that's the exceptional case. A correct factory should have a NAME field
>> and
>>> its lookup is fast and the additional check introduced for the class is 
>>> cheap.
>>> 
>>> Uwe
>>> 
>>> -
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de
>>> eMail: u...@thetaphi.de
>>> 
>>>> -Original Message-
>>>> From: Alan Woodward 
>>>> Sent: Monday, September 6, 2021 3:48 PM
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: getField vs getDeclaredField in analysis SPI
>>>> 
>>>> Thanks Uwe!
>>>> 
>>>>> On 6 Sep 2021, at 13:11, Uwe Schindler  wrote:
>>>>> 
>>>>> Hi Alan,
>>>>> 
>>>>>> LUCENE-9281 moved the `lookupSPIName` method from
>>>>>> AbstractAnalysisFactory to AnalysisSPILoader; the method is mostly the
>>>> same,
>>>>>> but one line has been changed from Class.getField() to
>>>> Class.getDeclaredField().
>>>>>> This can fall foul of the Security Manager, which wants a higher level of
>>>>>> permission for getDeclaredField.  Was this an intentional change? As I
>>>>> 
>>>>> This was intentional because the previous code wasn't fully correct,
>> because
>>> I
>>>> had some safety check in mind: The main reason for the getDeclaredField()
>> is
>>> to
>>>> lookup the field only in this class; while getField() also looks into
>> superclasses.
>>>> E.g. if the superclass has a NAME field because of a programming error it
>>> would
>>>> pick that up, which would be wrong. When investigating other
>>>> implementations using "named" lookups out there (even in JDK), they used
>>>> getDeclaredField() when accessing a static member.
>>>>> 
>>>>> There are 2 solutions:
>>>>> - Change to getField(), but in the if statement below check the actual
>> class:
>>>> (field.getDeclaringClass()==service) (see https://github.com/apache/lucene-
>>>> solr/pull/1360/files#diff-
>>>> 
>>> 
>> 6a65d91199a18bc4ee2d00a1e9dc283aedc4134846e0d7aafdc484f8263e250bR
>>>> 159-R162)
>>>>> - Wrap with doPrivileged in Lucene code. As far as I remember Lucene
>> needs
>>>> the permission anyways. With doPrivileged you would delegate
>> responsibility.
>>>>> 
>>>>> I'd open a JIRA issue, I can fix this. It only affects Lucene 9.0.
>>>>> 
>>>>>> understand it it’s looking for a NAME static field on the class in 
>>>&

Re: getField vs getDeclaredField in analysis SPI

[Alan Woodward]

Thanks Uwe!

> On 6 Sep 2021, at 13:11, Uwe Schindler  wrote:
> 
> Hi Alan,
> 
>> LUCENE-9281 moved the `lookupSPIName` method from
>> AbstractAnalysisFactory to AnalysisSPILoader; the method is mostly the same,
>> but one line has been changed from Class.getField() to 
>> Class.getDeclaredField().
>> This can fall foul of the Security Manager, which wants a higher level of
>> permission for getDeclaredField.  Was this an intentional change? As I
> 
> This was intentional because the previous code wasn't fully correct, because 
> I had some safety check in mind: The main reason for the getDeclaredField() 
> is to lookup the field only in this class; while getField() also looks into 
> superclasses. E.g. if the superclass has a NAME field because of a 
> programming error it would pick that up, which would be wrong. When 
> investigating other implementations using "named" lookups out there (even in 
> JDK), they used getDeclaredField() when accessing a static member.
> 
> There are 2 solutions:
> - Change to getField(), but in the if statement below check the actual class: 
> (field.getDeclaringClass()==service) (see 
> https://github.com/apache/lucene-solr/pull/1360/files#diff-6a65d91199a18bc4ee2d00a1e9dc283aedc4134846e0d7aafdc484f8263e250bR159-R162)
> - Wrap with doPrivileged in Lucene code. As far as I remember Lucene needs 
> the permission anyways. With doPrivileged you would delegate responsibility.
> 
> I'd open a JIRA issue, I can fix this. It only affects Lucene 9.0.
> 
>> understand it it’s looking for a NAME static field on the class in question, 
>> which
>> should always be public. I’m in the process of upgrading elasticsearch to 
>> use a
>> lucene 9 snapshot, and this change means that I need to wrap SPI reloading
>> code in doPrivileged() blocks, which is a bit of a pain.
> 
> Thansk for doing this. Is Elasticsearch now using the Analysis Factory 
> framework instead of their own factories?
> 
>> Thanks, Alan
> 
> No problem,
> Uwe
> 
> 
> 
> -
> 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

getField vs getDeclaredField in analysis SPI

[Alan Woodward]

Hi all,

LUCENE-9281 moved the `lookupSPIName` method from AbstractAnalysisFactory to 
AnalysisSPILoader; the method is mostly the same, but one line has been changed 
from Class.getField() to Class.getDeclaredField().  This can fall foul of the 
Security Manager, which wants a higher level of permission for 
getDeclaredField.  Was this an intentional change? As I understand it it’s 
looking for a NAME static field on the class in question, which should always 
be public. I’m in the process of upgrading elasticsearch to use a lucene 9 
snapshot, and this change means that I need to wrap SPI reloading code in 
doPrivileged() blocks, which is a bit of a pain.

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

Jar manifest target versions

[Alan Woodward]

Hi all,

I’m testing out snapshot versions of Lucene’s main branch, and I noticed that 
the jar manifests produced by running mavenToLocalFolder have the following 
entries:

X-Compile-Source-JDK: 15
X-Compile-Target-JDK: 15
X-Build-JDK: 15.0.1 (Oracle Corporation 15.0.1+9-18)
The java min version for lucene 9 will be Java 11 though.  Is there some 
configuration missing that will pass the target java version to javac as part 
of the build?

- Alan

Re: Getting Matches in a document

[Alan Woodward]

Hi Arihant,

Getting Matches is a fairly heavy operation and is designed to be used for 
top-k hits only, a bit like the explain API.  Collectors by contrast are 
supposed to be very lightweight - collect(doc) could get called millions of 
times during a search.  So the two APIs are not really meant to be used 
together.

Thanks, Alan

> On 15 Jul 2021, at 04:18, Arihant Samar  > wrote:
> 
> Hi,
> Is there any way to get the matches of a document in the collect(int doc) 
> function of the collector, other than calling the matches function of the 
> Weight Class again?
> 
> Thanking you in advance,
> Arihant.

Re: Welcome Mayya Sharipova to the Lucene PMC

[Alan Woodward]

Welcome Mayya!

> On 29 Jun 2021, at 02:22, Koji Sekiguchi  wrote:
> 
> Congrats and welcome Mayya!
> 
> Koji
> 
> On 2021/06/28 22:16, Robert Muir wrote:
>> I am pleased to announce that Mayya has accepted an invitation to join
>> the Lucene PMC!
>> Congratulations, and welcome aboard!
>> -
>> 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: Analyzer lifecycles

[Alan Woodward]

Hey Robert,

Analyzers themselves can be heavy and load large data files, etc, I agree, but 
I’m really talking about token stream construction.  The way things are set up, 
we expect the heavy lifting to be done when the Analyzer is constructed, but 
these heavy resources should then be shared between token streams (I fixed a 
bug in the Ukrainian analyzer a while back that was getting this wrong, see 
LUCENE-9930).  So you’d build your Analyzers once and use the same instances at 
query and at index time, and there’s no worry about reloading large 
dictionaries on every use.

But re-using token streams is different. The reason we have 
TokenStreamComponents and ReuseStrategies (as I understand it) is not because 
they may have to load large resource files or dictionaries or whatever, but 
it’s because building a TokenStream is itself quite a heavy operation due to 
AttributeFactories and reflection.  My argument is that this is only heavy 
relative to the cost of indexing a single field, and that this only really 
matters when you have documents with lots of small fields in them.  For query 
building or highlighting or MoreLlikeThis, the cost of building a small number 
of token streams is tiny compared to all the other heavy lifting and IO going 
on.  And so if we pushed this *TokenStream* reuse into IndexWriter we wouldn’t 
have to have a close() method on Analyzer (because the thread locals go away, 
and we expect file resources etc to be closed once the analyzer has finished 
building itself), and delegating or wrapping analyzers becomes much simpler.

Does that make more sense?

(I agree on the thread pool stuff, but we need to be careful about not blowing 
up users systems even if they are implementing anti-patterns!)

> On 8 Jun 2021, at 16:12, Robert Muir  wrote:
> 
> Alan: a couple thoughts:
> 
> Analyzers are not just used for formulating queries, but also may be
> used by highlighters and other things on document results at query
> time.
> Some analyzers may do too-expensive/garbage-creating stuff on
> construction, that you wouldn't want to do at query-time.
> Separately, I think Analyzer being closable makes sense.
> Users still need to carefully consider the lifecycle of this thing for
> performance, and may want to return their own resources for some
> reason (close() is a non-final method today)
> Analyzers might require large amounts of resources (such as parsing
> files/lists, ml models, who knows what).
> For the built-in minimal resources that we ship, we try to make
> construction cheap and use static holder classes, and so on. I'm
> concerned some of these are costly.
> But I'm definitely worried about longer files and stuff that many
> users might use.
> 
> I feel like some of this "large threadpool" stuff is just a java
> antipattern for search. I configure servers with fixed threadpools
> matching the number of CPU cores, and tell my load balancer about that
> number (e.g. haproxy maxconn), so that it can effectively queue and
> not overload search servers.
> 
> On Tue, Jun 8, 2021 at 10:23 AM Alan Woodward  wrote:
>> 
>> Hi all,
>> 
>> I’ve been on holiday and away from a keyboard for a week, so that means I of 
>> course spent my time thinking about lucene Analyzers and specifically their 
>> ReuseStrategies…
>> 
>> Building a TokenStream can be quite a heavy operation, and so we try and 
>> reuse already-constructed token streams as much as possible.  This is 
>> particularly important at index time, as having to create lots and lots of 
>> very short-lived token streams for documents with many short text fields 
>> could mean that we spend longer building these objects than we do pulling 
>> data from them.  To help support this, lucene Analyzers have a 
>> ReuseStrategy, which defaults to storing a map of fields to token streams in 
>> a ThreadLocal object.  Because ThreadLocals can behave badly when it comes 
>> to containers that have large thread pools, we use a special 
>> CloseableThreadLocal class that can null out its contents once the Analyzer 
>> is done with, and this leads to Analyzer itself being Closeable.  This makes 
>> extending analyzers more complicated, as delegating wrappers need to ensure 
>> that they don’t end up sharing token streams with their delegates.
>> 
>> It’s common to use the same analyzer for indexing and for parsing user 
>> queries.  At query time, reusing token streams is a lot less important - the 
>> amount of time spent building the query is typically much lower than the 
>> amount of time spent rewriting and executing it.  The fact that this re-use 
>> is only really useful for index time and that the lifecycle of the analyzer 
>> is therefore very closely tied to the lifecycle of 

Analyzer lifecycles

[Alan Woodward]

Hi all,

I’ve been on holiday and away from a keyboard for a week, so that means I of 
course spent my time thinking about lucene Analyzers and specifically their 
ReuseStrategies…

Building a TokenStream can be quite a heavy operation, and so we try and reuse 
already-constructed token streams as much as possible.  This is particularly 
important at index time, as having to create lots and lots of very short-lived 
token streams for documents with many short text fields could mean that we 
spend longer building these objects than we do pulling data from them.  To help 
support this, lucene Analyzers have a ReuseStrategy, which defaults to storing 
a map of fields to token streams in a ThreadLocal object.  Because ThreadLocals 
can behave badly when it comes to containers that have large thread pools, we 
use a special CloseableThreadLocal class that can null out its contents once 
the Analyzer is done with, and this leads to Analyzer itself being Closeable.  
This makes extending analyzers more complicated, as delegating wrappers need to 
ensure that they don’t end up sharing token streams with their delegates.

It’s common to use the same analyzer for indexing and for parsing user queries. 
 At query time, reusing token streams is a lot less important - the amount of 
time spent building the query is typically much lower than the amount of time 
spent rewriting and executing it.  The fact that this re-use is only really 
useful for index time and that the lifecycle of the analyzer is therefore very 
closely tied to the lifecycle of its associated IndexWriter makes me think that 
we should think about moving the re-use strategies into IndexWriter itself.  
One option would be to have token streams be constructed once per 
DocumentsWriterPerThread, which would lose some re-use but would mean we could 
avoid ThreadLocals entirely.

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

Re: Misconfigured gradle rat inputs?

[Alan Woodward]

I will defer to the sophisticated gradle policeman on this!

> On 25 May 2021, at 18:40, Uwe Schindler  wrote:
> 
> Hi,
> 
> the problem is that the RAT task has only some patterns for filenames as 
> input, but no actual @InputDirectory. If the files change, nothing changes 
> from Gradle's point of view.
> 
> The validation/rat-sources.gradle and its inner class "RatTask" must at least 
> declare @InputDirectory with a default value of ${project.projectDir}. This 
> would cause any change to retrigger the task.
> 
> To make it more professional, it should declare a FileCollection and apply 
> the patterns, but that's more complicated as this task just wraps the native 
> Ant RAT task.
> 
> I can fix this (must be done for Solr and Lucene, both have the problem).
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Alan Woodward 
>> Sent: Tuesday, May 25, 2021 7:26 PM
>> To: dev@lucene.apache.org
>> Subject: Misconfigured gradle rat inputs?
>> 
>> There’s a subject line I never thought I’d type :)
>> 
>> Firstly: can I say how much I appreciate all the work that’s gone into the 
>> gradle
>> build? I’ve been doing lots of small PRs for the spans-to-queries work and 
>> being
>> able to run checks multiple times in an extremely efficient manner has been a
>> life saver.  Massive thanks to Dawid, and also to Robert for all the work on
>> speeding up tests.
>> 
>> I think may have found a bug in the input configuration for our license 
>> header
>> checks.  Thanks to the new build, I have been running `./gradlew check` 
>> before
>> pushing code, but it has let through files with missing headers a few times,
>> which were subsequently caught by the GitHub action running on the PR.
>> 
>> So I tried the following:
>> - start a new git branch
>> - run ./gradlew rat -> everything should pass
>> - edit one of the files to remove the license header
>> - run ./gradlew rat -> still passes!
>> - run ./gradlew clean
>> - run ./gradlew rat -> now I get an error
>> 
>> This looks to me like the fileset that the rat task is looking at is not set 
>> up
>> correctly, but I don’t know enough gradle to actually work out what is wrong
>> and what the fix should be.
>> 
>> - A
>> -
>> 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

Misconfigured gradle rat inputs?

[Alan Woodward]

There’s a subject line I never thought I’d type :)

Firstly: can I say how much I appreciate all the work that’s gone into the 
gradle build? I’ve been doing lots of small PRs for the spans-to-queries work 
and being able to run checks multiple times in an extremely efficient manner 
has been a life saver.  Massive thanks to Dawid, and also to Robert for all the 
work on speeding up tests.

I think may have found a bug in the input configuration for our license header 
checks.  Thanks to the new build, I have been running `./gradlew check` before 
pushing code, but it has let through files with missing headers a few times, 
which were subsequently caught by the GitHub action running on the PR.

So I tried the following:
- start a new git branch
- run ./gradlew rat -> everything should pass
- edit one of the files to remove the license header
- run ./gradlew rat -> still passes!
- run ./gradlew clean
- run ./gradlew rat -> now I get an error

This looks to me like the fileset that the rat task is looking at is not set up 
correctly, but I don’t know enough gradle to actually work out what is wrong 
and what the fix should be.

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

Re: Lucene 9.0 snapshot names

[Alan Woodward]

> On 25 May 2021, at 11:24, Dawid Weiss  <mailto:dawid.we...@gmail.com>> wrote:
> 
> 
> Ok. In that case we can make it simpler by not adding the signing plugin to 
> that (local) maven publication? Unless it makes sense to have it. Let me 
> know, this is a trivial change.

+1, that would be great.  Thanks Dawid!

On a different note, does gradle use the same configuration for when we do 
actual releases? I’m still confused as to why it wanted my GPG password in 
plaintext in a file somewhere.

> 
> D.
> 
> On Tue, May 25, 2021 at 8:36 AM Uwe Schindler  <mailto:u...@thetaphi.de>> wrote:
> Maven consumers only needs checksums to work correctly. The signatures are 
> optional.
> 
> Uwe
> 
> Am May 25, 2021 6:16:08 AM UTC schrieb Dawid Weiss  <mailto:dawid.we...@gmail.com>>:
> 
> These signatures are what makes a Maven repository a Maven repository though. 
> Even when you "deploy" to a local folder, it preserves the files required for 
> other Maven-toolchain tools. I'm not sure how it behaves without signatures. 
> 
> It is entirely doable to create a non-maven-task based assembly into a binary 
> distribution ZIP/ folder. Then no task exclusions will be required?
> 
> Dawid
> 
> On Mon, May 24, 2021 at 6:56 PM Uwe Schindler  <mailto:u...@thetaphi.de>> wrote:
> Thank for this tipp! Helps for Solr, too. I was giving up because it always 
> wanted to sign, that Jenkins can't easily do.
> 
> Uwe
> 
> Am May 24, 2021 8:03:51 AM UTC schrieb Alan Woodward  <mailto:romseyg...@gmail.com>>:
> Passing -x signJarsPublication skipped the signing step so I’m good to go.  
> Thanks everyone for the help!
> 
>> On 23 May 2021, at 21:11, Dawid Weiss > <mailto:dawid.we...@gmail.com>> wrote:
>> 
>> 
>> Create a temporary pgp key for use with signing and use it to sign your 
>> maven artifacts? I don't know if there is a way to use an agent - perhaps 
>> there is. Hoss did some work with manual artifact signing recently (and this 
>> used the agent). I never had the need for this.
>> 
>> Dawid
>> 
>> On Sat, May 22, 2021 at 4:50 PM Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>> Passing -Dversion.suffix does indeed work, thanks Uwe!  The next Yak to 
>> shave is that gradle is now complaining that it can’t sign the artefacts.  
>> From my reading it seems that I have to set things up in my 
>> gradle.properties file, including my password in plain text.  This seems … 
>> wrong?  I don’t actually need these artefacts signed anyway, so does anyone 
>> with more gradle-fu than me know either a) how to skip the signing step or 
>> b) how to set things up so that they are signed correctly without having my 
>> PGP password sitting in a plain text file.
>> 
>> Thanks!
>> 
>>> On 20 May 2021, at 14:19, Uwe Schindler >> <mailto:u...@thetaphi.de>> wrote:
>>> 
>>> The default suffix in this system prop is "SNAPSHOT" and the timestamp 
>>> comes then from Maven's internal Logic, this cannot be changed.
>>> 
>>> By overriding the suffix explicit (as said before and find by Jenkins) you 
>>> convert it to an official "release" in Maven's sense and it is no longer a 
>>> snapshot. So you are free with versioning.
>>> 
>>> Uwe
>>> 
>>> Am May 20, 2021 1:15:12 PM UTC schrieb Uwe Schindler >> <mailto:u...@thetaphi.de>>:
>>> Jenkins does this already: 
>>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/ 
>>> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/>
>>> 
>>> It uses build number!
>>> 
>>> The system property "version suffix" is responsible and is set by Jenkins. 
>>> See in command line: [Lucene-Artifacts-main] $ 
>>> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Artifacts-main/gradlew 
>>> -Dlucene.javadoc.url=https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc
>>>  
>>> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc> 
>>> -Dversion.suffix=jenkins242 assemble
>>> 
>>> Uwe
>>> 
>>> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov >> <mailto:msoko...@gmail.com>>:
>>> In principal it makes sense, but is there any chance the build artifact 
>>> could vary for the same SHA? We hope not, I think, but stranger things have 
>>> happened. Probably an edge case not worth worrying about though, and 
>>> relying on the build s

Re: Lucene 9.0 snapshot names

[Alan Woodward]

Passing -x signJarsPublication skipped the signing step so I’m good to go.  
Thanks everyone for the help!

> On 23 May 2021, at 21:11, Dawid Weiss  wrote:
> 
> 
> Create a temporary pgp key for use with signing and use it to sign your maven 
> artifacts? I don't know if there is a way to use an agent - perhaps there is. 
> Hoss did some work with manual artifact signing recently (and this used the 
> agent). I never had the need for this.
> 
> Dawid
> 
> On Sat, May 22, 2021 at 4:50 PM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> Passing -Dversion.suffix does indeed work, thanks Uwe!  The next Yak to shave 
> is that gradle is now complaining that it can’t sign the artefacts.  From my 
> reading it seems that I have to set things up in my gradle.properties file, 
> including my password in plain text.  This seems … wrong?  I don’t actually 
> need these artefacts signed anyway, so does anyone with more gradle-fu than 
> me know either a) how to skip the signing step or b) how to set things up so 
> that they are signed correctly without having my PGP password sitting in a 
> plain text file.
> 
> Thanks!
> 
>> On 20 May 2021, at 14:19, Uwe Schindler > <mailto:u...@thetaphi.de>> wrote:
>> 
>> The default suffix in this system prop is "SNAPSHOT" and the timestamp comes 
>> then from Maven's internal Logic, this cannot be changed.
>> 
>> By overriding the suffix explicit (as said before and find by Jenkins) you 
>> convert it to an official "release" in Maven's sense and it is no longer a 
>> snapshot. So you are free with versioning.
>> 
>> Uwe
>> 
>> Am May 20, 2021 1:15:12 PM UTC schrieb Uwe Schindler > <mailto:u...@thetaphi.de>>:
>> Jenkins does this already: 
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/ 
>> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/>
>> 
>> It uses build number!
>> 
>> The system property "version suffix" is responsible and is set by Jenkins. 
>> See in command line: [Lucene-Artifacts-main] $ 
>> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Artifacts-main/gradlew 
>> -Dlucene.javadoc.url=https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc
>>  <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc> 
>> -Dversion.suffix=jenkins242 assemble
>> 
>> Uwe
>> 
>> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov > <mailto:msoko...@gmail.com>>:
>> In principal it makes sense, but is there any chance the build artifact 
>> could vary for the same SHA? We hope not, I think, but stranger things have 
>> happened. Probably an edge case not worth worrying about though, and relying 
>> on the build server's clock doesn't seem great, so +1 from me, although I 
>> don't use these so my interest is mostly theoretical. 
>> 
>> On Thu, May 20, 2021, 8:20 AM Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>> Hi all,
>> 
>> I’m preparing a local lucene 9.0 snapshot build and I notice that the jar 
>> files generated by `./gradlew mavenToLocalFolder` are called something like 
>> `lucene-suggest-9.0.0-20210520.111833-1-javadoc.jar` - in other words, they 
>> are including a timestamp.  For my setup I’d like to replace this with the 
>> git SHA of the commit the snapshot is based on.  So I have two questions:
>> 
>> 1) Is there a simple override or gradle property that I can pass on the 
>> command line that will change the output names of artefacts?
>> 2) I think in general commit SHAs are better than timestamps for snapshot 
>> names - two identical snapshots taken from identical sources at different 
>> times shouldn’t really have different names.  Should we look at changing the 
>> existing snapshot generation code to switch to using SHAs?
>> 
>> - Alan
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
>> 
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> --
>> Uwe Schindler
>> Achterdiek 19, 28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>

Re: Lucene 9.0 snapshot names

[Alan Woodward]

Passing -Dversion.suffix does indeed work, thanks Uwe!  The next Yak to shave 
is that gradle is now complaining that it can’t sign the artefacts.  From my 
reading it seems that I have to set things up in my gradle.properties file, 
including my password in plain text.  This seems … wrong?  I don’t actually 
need these artefacts signed anyway, so does anyone with more gradle-fu than me 
know either a) how to skip the signing step or b) how to set things up so that 
they are signed correctly without having my PGP password sitting in a plain 
text file.

Thanks!

> On 20 May 2021, at 14:19, Uwe Schindler  <mailto:u...@thetaphi.de>> wrote:
> 
> The default suffix in this system prop is "SNAPSHOT" and the timestamp comes 
> then from Maven's internal Logic, this cannot be changed.
> 
> By overriding the suffix explicit (as said before and find by Jenkins) you 
> convert it to an official "release" in Maven's sense and it is no longer a 
> snapshot. So you are free with versioning.
> 
> Uwe
> 
> Am May 20, 2021 1:15:12 PM UTC schrieb Uwe Schindler  <mailto:u...@thetaphi.de>>:
> Jenkins does this already: 
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/ 
> <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/242/>
> 
> It uses build number!
> 
> The system property "version suffix" is responsible and is set by Jenkins. 
> See in command line: [Lucene-Artifacts-main] $ 
> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Artifacts-main/gradlew 
> -Dlucene.javadoc.url=https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc
>  <https://ci-builds.apache.org/job/Lucene/job/Lucene-Artifacts-main/javadoc> 
> -Dversion.suffix=jenkins242 assemble
> 
> Uwe
> 
> Am May 20, 2021 12:25:48 PM UTC schrieb Michael Sokolov  <mailto:msoko...@gmail.com>>:
> In principal it makes sense, but is there any chance the build artifact could 
> vary for the same SHA? We hope not, I think, but stranger things have 
> happened. Probably an edge case not worth worrying about though, and relying 
> on the build server's clock doesn't seem great, so +1 from me, although I 
> don't use these so my interest is mostly theoretical. 
> 
> On Thu, May 20, 2021, 8:20 AM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> Hi all,
> 
> I’m preparing a local lucene 9.0 snapshot build and I notice that the jar 
> files generated by `./gradlew mavenToLocalFolder` are called something like 
> `lucene-suggest-9.0.0-20210520.111833-1-javadoc.jar` - in other words, they 
> are including a timestamp.  For my setup I’d like to replace this with the 
> git SHA of the commit the snapshot is based on.  So I have two questions:
> 
> 1) Is there a simple override or gradle property that I can pass on the 
> command line that will change the output names of artefacts?
> 2) I think in general commit SHAs are better than timestamps for snapshot 
> names - two identical snapshots taken from identical sources at different 
> times shouldn’t really have different names.  Should we look at changing the 
> existing snapshot generation code to switch to using SHAs?
> 
> - Alan
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 
> 
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> --
> Uwe Schindler
> Achterdiek 19, 28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>

Lucene 9.0 snapshot names

[Alan Woodward]

Hi all,

I’m preparing a local lucene 9.0 snapshot build and I notice that the jar files 
generated by `./gradlew mavenToLocalFolder` are called something like 
`lucene-suggest-9.0.0-20210520.111833-1-javadoc.jar` - in other words, they are 
including a timestamp.  For my setup I’d like to replace this with the git SHA 
of the commit the snapshot is based on.  So I have two questions:

1) Is there a simple override or gradle property that I can pass on the command 
line that will change the output names of artefacts?
2) I think in general commit SHAs are better than timestamps for snapshot names 
- two identical snapshots taken from identical sources at different times 
shouldn’t really have different names.  Should we look at changing the existing 
snapshot generation code to switch to using SHAs?

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

Re: Welcome Zach Chen as Lucene committer

[Alan Woodward]

Congratulations and welcome!

> On 19 Apr 2021, at 15:13, Adrien Grand  wrote:
> 
> I'm pleased to announce that Zach Chen has accepted the PMC's invitation to 
> become a committer.
> 
> Zach, the tradition is that new committers introduce themselves with a brief 
> bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien


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

Re: Welcome Peter Gromov as Lucene committer

[Alan Woodward]

Welcome Peter!

> On 6 Apr 2021, at 18:47, Robert Muir  wrote:
> 
> I'm pleased to announce that Peter Gromov has accepted the PMC's invitation 
> to become a committer.
> 
> Peter, the tradition is that new committers introduce themselves with a brief 
> bio.
> 
> Congratulations and welcome!
> 


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

Re: Bugfix release Lucene/Solr 8.8.2

[Alan Woodward]

LUCENE-9744 and LUCENE-9762 are both backported.

> On 30 Mar 2021, at 09:03, Ignacio Vera  <mailto:iver...@gmail.com>> wrote:
> 
> Hi Mike, 
> 
> LUCENE-9870 has been backported, Thanks!
> 
> On Mon, Mar 29, 2021 at 10:32 PM Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> Oh, I see what you meant! I actually just redid the changes from scratch 
> instead of trying to backport the 9.0 changes as a patch, so no worries on 
> that front. Thanks for thinking of me there though!
> 
> I just committed some changes for morelikethis.adoc that I decided I’d like 
> to backport into branch_8_8 since we’re re-publishing…it’s docs-only, though.
> On Mar 29, 2021, 2:25 PM -0500, Mike Drob  <mailto:md...@mdrob.com>>, wrote:
>> Thanks, Cassandra. When I skimmed the initial changeset, I saw that there 
>> were changes to build.gradle - I assumed that there would have to be some 
>> changes to build.xml in the 8x branch, but I didn't investigate further on 
>> how they would differ. Was just trying to be helpful and give you a heads up 
>> about it, but looks like I caused more confusion than help!
>> 
>> On Mon, Mar 29, 2021 at 1:31 PM Cassandra Targett > <mailto:casstarg...@gmail.com>> wrote:
>> I pushed up the URL changes I mentioned.
>> 
>> Not sure what you mean, Mike, by “gradle->ant translation”? The build 
>> process is different in branch_8x but it’s documented in the 
>> how-to-contribute page in the ref guide that talks about contributing and 
>> building, etc.
>> On Mar 29, 2021, 12:55 PM -0500, Mike Drob > <mailto:md...@mdrob.com>>, wrote:
>> 
>> Cassandra - yes, I plan to republish the ref guide, your expertise is 
>> absolutely appreciated. It looks like there will also be some gradle->ant 
>> translation. Was this mostly find-and-replace or was there more order to it?
>> 
>> On Mon, Mar 29, 2021 at 12:32 PM Alan Woodward > <https://mailto:romseyg...@gmail.com/>> wrote:
>> Hi Mike,
>> 
>> I’d like to back port LUCENE-9744 (which fixes an NPE in intervals queries) 
>> and LUCENE-9762 (which fixes a bug in QueryValuesSource).
>> 
>> Thanks, Alan
>> 
>> On 29 Mar 2021, at 09:47, Ignacio Vera > <https://mailto:iver...@gmail.com/>> wrote:
>> 
>> I'd like to backport Lucene-9870 which is a bug in distance queries that 
>> causes no matches along indexed lines and polygon edges. This fix only 
>> touches one class tho so very low risk.
>> 
>> lucene  
>> 
>> On Sat, Mar 27, 2021 at 3:24 PM Mike Drob > <https://mailto:md...@mdrob.com/>> wrote:
>> Ishan,
>> 
>> Thank you for bringing this up. I’m comfortable delaying an extra week to 
>> accommodate the multitude of holidays (Holi, Passover, others) coming up.
>> 
>> I will adjust my schedule to start the vote Tuesday, Apr 6.
>> 
>> Please make sure that all back ports are appropriately marked with 
>> fixVersion in Jira and have corresponding CHANGES entries.
>> 
>> Mike
>> 
>> On Fri, Mar 26, 2021 at 11:11 PM Ishan Chattopadhyaya 
>> https://mailto:ichattopadhy...@gmail.com/>> 
>> wrote:
>> Hi Mike,
>> 
>> I wish to get https://issues.apache.org/jira/browse/SOLR-15288 
>> <https://issues.apache.org/jira/browse/SOLR-15288> in, but will likely be 
>> able to wrap up by 2 April or so (on vacation right now due to the festival 
>> of Holi)
>> 
>> Regards,
>> Ishan
>> 
>> On Sat, 27 Mar, 2021, 7:41 am Mike Drob, > <https://mailto:md...@mdrob.com/>> wrote:
>> I am now preparing for a bugfix release from branch branch_8_8
>> 
>> I plan to have the RC built and vote started on Tuesday, Mar 30. If you have 
>> small, low risk bug fixes to backport before then, please do so using your 
>> best judgement.
>> 
>> Please observe the normal rules for committing to this branch:
>> 
>> * Before committing to the branch, reply to this thread and argue
>>   why the fix needs backporting and how long it will take.
>> * All issues accepted for backporting should be marked with 8.8.2
>>   in JIRA, and issues that should delay the release must be marked as Blocker
>> * All patches that are intended for the branch should first be committed
>>   to the unstable branch, merged into the stable branch, and then into
>>   the current release branch.
>> * Only Jira issues with Fix version 8.8.2 and priority "Blocker" will delay
>>   a release candidate build.
>> 
>> Thanks,
>> Mike
>> 

Re: Bugfix release Lucene/Solr 8.8.2

[Alan Woodward]

Hi Mike,

I’d like to back port LUCENE-9744 (which fixes an NPE in intervals queries) and 
LUCENE-9762 (which fixes a bug in QueryValuesSource).

Thanks, Alan

> On 29 Mar 2021, at 09:47, Ignacio Vera  > wrote:
> 
> I'd like to backport Lucene-9870 which is a bug in distance queries that 
> causes no matches along indexed lines and polygon edges. This fix only 
> touches one class tho so very low risk.
> lucene  
> 
> On Sat, Mar 27, 2021 at 3:24 PM Mike Drob  > wrote:
> Ishan,
> 
> Thank you for bringing this up. I’m comfortable delaying an extra week to 
> accommodate the multitude of holidays (Holi, Passover, others) coming up.
> 
> I will adjust my schedule to start the vote Tuesday, Apr 6.
> 
> Please make sure that all back ports are appropriately marked with fixVersion 
> in Jira and have corresponding CHANGES entries.
> 
> Mike
> 
> On Fri, Mar 26, 2021 at 11:11 PM Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> Hi Mike,
> 
> I wish to get https://issues.apache.org/jira/browse/SOLR-15288 
>  in, but will likely be 
> able to wrap up by 2 April or so (on vacation right now due to the festival 
> of Holi)
> 
> Regards,
> Ishan
> 
> On Sat, 27 Mar, 2021, 7:41 am Mike Drob,  > wrote:
> I am now preparing for a bugfix release from branch branch_8_8
> 
> I plan to have the RC built and vote started on Tuesday, Mar 30. If you have 
> small, low risk bug fixes to backport before then, please do so using your 
> best judgement.
> 
> Please observe the normal rules for committing to this branch:
> 
> * Before committing to the branch, reply to this thread and argue
>   why the fix needs backporting and how long it will take.
> * All issues accepted for backporting should be marked with 8.8.2
>   in JIRA, and issues that should delay the release must be marked as Blocker
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Only Jira issues with Fix version 8.8.2 and priority "Blocker" will delay
>   a release candidate build.
> 
> Thanks,
> Mike

Re: Welcome Houston Putman to the PMC

[Alan Woodward]

Welcome Houston!

> On 1 Dec 2020, at 21:19, Mike Drob  wrote:
> 
> I am pleased to announce that Houston Putman has accepted the PMC's 
> invitation to join.
> 
> Congratulations and welcome, Houston!
> 
> -
> 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: Question about behaviour of IntervalIterator

[Alan Woodward]

Some of the minimum-interval algorithms will call nextInterval() or start() 
even after the interval has been exhausted, so we need to handle those 
situations properly.  Improved java doc would definitely be helpful though, and 
maybe we should update checkIntervals() in TestIntervals to test what happens 
when calling nextInterval() after it has returned NO_MORE_INTERVALS.  Do you 
want to open an issue?

- Alan

> On 19 Nov 2020, at 08:17, Haoyu Zhai  wrote:
> 
> Hi,
> I'm trying to play around with my own IntervalSource and found out that 
> "nextInterval" method of IntervalIterator will be called sometimes even after 
> "nextDoc"/"docID"/"advance" method returns NO_MORE_DOCS.
> After I dug a bit more I found that FilteringIntervalIterator.reset is 
> calling an inner iterator's "nextInterval" regardless of what the result of 
> "nextDoc", and also most (if not all) existing IntervalIterator's 
> implementation do considered the case where "nextInterval" is called after 
> "nextDoc" returns NO_MORE_DOCS.
> I'm a bit confused here since I thought in most places lucene assumes 
> undefined behavior after NO_MORE_DOCS are returned for those method should be 
> called only after "advance", but for "nextInterval" seems its not the case. 
> Should we change the current behavior of "nextInterval" implementations or 
> add some caution comment to javadoc?
> 
> Thanks
> Patrick Zhai


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

Re: Welcome Julie Tibshirani as Lucene/Solr committer

[Alan Woodward]

Congratulations and welcome Julie!

> On 18 Nov 2020, at 15:06, Michael Sokolov  wrote:
> 
> I'm pleased to announce that Julie Tibshirani has accepted the PMC's
> invitation to become a committer.
> 
> Julie, the tradition is that new committers introduce themselves with
> a brief bio.
> 
> I think we may still be sorting out the details of your Apache account
> (julie@ may have been taken?), but as soon as that has been sorted out
> and karma has been granted, you can use your new powers to add
> yourself to the committers section of the Who We Are page on the
> website: 
> 
> Congratulations and welcome!
> 
> Mike Sokolov
> 
> -
> 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: Fuzzy-phrase query with "holes" using intervals?

[Alan Woodward]

I think you need a sort of ‘ordered atLeast’ here.  Currently atLeast() is a 
mixture of a disjunction and an unordered interval, it should be possible to 
add something that adds additional constraints to the sets that it finds.  I 
think you’d need to write some code though, I can’t see a way of doing it with 
the current group of interval operators.

> On 17 Sep 2020, at 14:20, Dawid Weiss  wrote:
> 
> Hmm... Is there any way to express a query for a phrase-like sequence of 
> tokens:
> 
> a b c d
> 
> but with potential "holes" (one or more terms missing):
> 
> - b c d
> a - c d
> a b - d
> ...
> 
> I've experimented with ordered(term("a"), term(b), ...), gaps and
> atLeast but I can't get it to work. I could expand terms into several
> queries manually but the number of potential subsets is quite large,
> hence the question. Thanks for tips.
> 
> Dawid
> 
> -
> 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: Avoiding false-positives in multivalued field search with intervals?

[Alan Woodward]

I’ve solved this sort of thing in the past by indexing boundary tokens, and 
wrapping the queries with the equivalent of Intervals.notContaining(query, 
boundary-query); you could also put a very large position increment gap and use 
a width filter, but that’s a bit more error prone if you could conceivably have 
lots of text in the individual field entries.

> On 10 Sep 2020, at 10:38, Dawid Weiss  wrote:
> 
> Hi Alan,
> 
> You're the expert here so I thought I'd ask before I jump in deep. Do
> you think it's feasible to solve the following multivalued-field
> problem:
> 
> doc: field=["foo", "bar"]
> query: field:(foo AND bar)
> 
> I'd like the above to return zero hits (no single value contains both
> foo and bar), but since multi-valued fields are logically indexed as a
> single field, it returns doc. I recognize this as a well known problem
> but subdocuments are not fun to deal with so I'd like to avoid them at
> all costs.
> 
> Would it be possible to solve the above with intervals? Say, something
> like this:
> 
> Intervals.containing(valuePositionRanges(), query).
> 
> I assume the containment relationship would get rid of false-positives
> crossing value boundary here. The problem is in how to construct those
> value position ranges... Store them at index-construction time
> somehow? Compute them on the fly for anything that has a chance to
> match query? Your thoughts would be very appreciated.
> 
> Dawid
> 
> -
> 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: 8.6 release

[Alan Woodward]

We’ve found a nasty bug with ordered intervals: 
https://issues.apache.org/jira/browse/LUCENE-9418 


I think I have the fix already and plan to merge it in before the branch is cut.

> On 27 Jun 2020, at 03:59, Tomás Fernández Löbbe  > wrote:
> 
> I tagged SOLR-14590 for 8.6, The PR is ready for review and I plan to merge 
> it soon 
> 
> On Fri, Jun 26, 2020 at 12:54 PM Andrzej Białecki  > wrote:
> Jan,
> 
> I just removed SOLR-14182 from 8.6, this needs proper back-compat shims and 
> testing, and I don’t have enough time to get it done properly for 8.6.
> 
>> On 26 Jun 2020, at 13:37, Jan Høydahl > > wrote:
>> 
>> Unresolved Solr issues tagged with 8.6:
>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20resolution%20%3D%20Unresolved%20AND%20fixVersion%20%3D%208.6
>>  
>> 
>>  
>> 
>> SOLR-14593   Package store API to disable file upload over HTTP  
>> Blocker 
>> SOLR-14580   CloudSolrClient cannot be initialized using 'zkHosts' builder   
>> Blocker 
>> SOLR-14516   NPE during Realtime GET 
>> Major   
>> SOLR-14502   increase bin/solr's post kill sleep 
>> Minor   
>> SOLR-14398   package store PUT should be idempotent  
>> Trivial 
>> SOLR-14311   Shared schema should not have access to core level classes  
>> Major   
>> SOLR-14182   Move metric reporters config from solr.xml to ZK cluster 
>> properties Major   
>> SOLR-14066   Deprecate DIH   
>> Blocker 
>> SOLR-14022   Deprecate CDCR from Solr in 8.x 
>> Blocker 
>> 
>> Plus two private JIRA issues.
>> 
>> Jan
>> 
>>> 26. jun. 2020 kl. 12:06 skrev Bruno Roustant >> >:
>>> 
>>> So the plan is to cut the release branch on next Tuesday June 30th. If you 
>>> anticipate a problem with the date, please reply.
>>> 
>>> Is there any JIRA issue that must be committed before the release is made 
>>> and that has not already the appropriate "Fix Version"?
>>> 
>>> Currently there 3 unresolved issues flagged as Fix Version = 8.6:
>>> Add tests for corruptions caused by byte flips LUCENE-9356 
>>> 
>>> Fix linefiledocs compression or replace in tests LUCENE-9191
>>>  Can we merge small 
>>> segments during refresh, for faster searching? LUCENE-8962 
>>> 
>>> 
>>> 
>>> Le mer. 24 juin 2020 à 21:05, David Smiley >> > a écrit :
>>> Thanks starting this discussion, Cassandra.
>>> 
>>> I reviewed the issues I was involved with and I don't quite see something 
>>> worth noting.
>>> 
>>> I plan to add a note about a change in defaults within UnifiedHighlighter 
>>> that could be a significant perf regression.  This wasn't introduced in 8.6 
>>> but introduced in 8.5 and it's significant enough to bring attention to.  I 
>>> could add it in 8.5's section but then add a short pointer to it in 8.6.
>>> 
>>> ~ David
>>> 
>>> 
>>> On Wed, Jun 24, 2020 at 2:52 PM Cassandra Targett >> > wrote:
>>> I started looking at the Ref Guide for 8.6 to get it ready, and notice 
>>> there are no Upgrade Notes in `solr-upgrade-notes.adoc` for 8.6. Is it 
>>> really true that none are needed at all?
>>> 
>>> I’ll add what I usually do about new features/changes that maybe wouldn’t 
>>> normally make the old Upgrade Notes section, I just find it surprising that 
>>> there weren’t any devs who thought any of the 100 or so Solr changes 
>>> warrant any user caveats.
>>> On Jun 17, 2020, 12:27 PM -0500, Tomás Fernández Löbbe 
>>> mailto:tomasflo...@gmail.com>>, wrote:
 +1. Thanks Bruno
 
 On Wed, Jun 17, 2020 at 6:22 AM Mike Drob >>> > wrote:
 +1
 
 The release wizard python script should be sufficient for everything. If 
 you run into any issues with it, let me know, I used it for 8.5.2 and 
 think I understand it pretty well. 
 
 On Tue, Jun 16, 2020 at 8:31 AM Bruno Roustant >>> > wrote:
 Hi all,
 
 It’s been a while since we released Lucene/Solr 8.5.
 I’d like to volunteer to be a release manager for an 8.6 release. If 
 there's agreement, then I plan to cut the release branch two weeks today, 
 on June 30th, and then to build the first RC two days later.
 
 This will be my first time as release manager so I'll probably need some 
 guidance. Currently I have two resource links on this subject:
 

Re: Welcome Ilan Ginzburg as Lucene/Solr committer

[Alan Woodward]

Congratulations and Welcome, Ilan!

> On 22 Jun 2020, at 14:45, Ilan Ginzburg  > wrote:
> 
> Thank you, merci, תודה for the trust and the welcome, Noble and everybody!
> 
> I’m based in France near Grenoble, a flat city high tech hub surrounded by 
> mountains.
> 
> For the past 7 years I’ve been working on Search at Salesforce. Currently 
> focusing on SolrCloud scaling.
> I also work on making Solr nodes stateless, separating compute from storage 
> to better fit Public Cloud environments (see 
> Activate '18 , Activate '19 
> , SOLR-13101 
>  WIP).
> 
> Past employers include EMC/Documentum, HP Labs Palo Alto, Intel. Earlier 
> still I created the Apple 2 game Saracen (old timers here might remember?).
> 
> Other activities include a lot of paragliding, cycling, hiking, drumming 
> (here  during COVID) and a few stints working 
> as a photographer.
> 
> I hold a MA in business administration and a PhD in computer science 
> (parallel computing).
> 
> I’m extremely happy to join the Lucene/Solr community, the future looks 
> exciting!
> 
> Ilan
> 
> On Mon 22 Jun 2020 at 15:22, Joel Bernstein  > wrote:
> Welcome Ilan!
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ 
> 
> 
> On Mon, Jun 22, 2020 at 9:11 AM Michael McCandless  > wrote:
> Welcome Ilan!
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com 
> 
> On Sun, Jun 21, 2020 at 5:44 AM Noble Paul  > wrote:
> Hi all,
> 
> Please join me in welcoming Ilan Ginzburg as the latest Lucene/Solr committer.
> Ilan, it's tradition for you to introduce yourself with a brief bio.
> 
> Congratulations and Welcome!
> Noble

Re: [VOTE] Lucene logo contest

[Alan Woodward]

PMC vote for option A

> On 16 Jun 2020, at 12:34, Ishan Chattopadhyaya  > wrote:
> 
> I vote C, current logo.
> 
> On Tue, 16 Jun, 2020, 4:46 pm Shawn Heisey,  > wrote:
> On 6/15/2020 4:08 PM, Ryan Ernst wrote:
> > Dear Lucene and Solr developers!
> > 
> > In February a contest was started to design a new logo for Lucene [1]. 
> > That contest concluded, and I am now (admittedly a little late!) calling 
> > a vote.
> > 
> > The entries are labeled as follows:
> > 
> > A. Submitted by Dustin Haver [2]
> 
> PMC vote for option A -- extremely simple.  I think all the variations 
> are pretty nice looking.
> 
> Thanks,
> Shawn
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: Welcome Mayya Sharipova as Lucene/Solr committer

[Alan Woodward]

Congratulations and welcome Mayya!

> On 8 Jun 2020, at 17:58, jim ferenczi  > wrote:
> 
> Hi all,
> 
> Please join me in welcoming Mayya Sharipova as the latest Lucene/Solr 
> committer.
> Mayya, it's tradition for you to introduce yourself with a brief bio.
> 
> Congratulations and Welcome!
> 
> Jim

Re: [VOTE] Solr to become a top-level Apache project (TLP)

[Alan Woodward]

+1 (binding)

Alan Woodward

> On 12 May 2020, at 12:06, Jan Høydahl  wrote:
> 
> +1 (binding)
> 
> Jan Høydahl
> 
>> 12. mai 2020 kl. 09:36 skrev Dawid Weiss :
>> 
>> Dear Lucene and Solr developers!
>> 
>> According to an earlier [DISCUSS] thread on the dev list [2], I am
>> calling for a vote on the proposal to make Solr a top-level Apache
>> project (TLP) and separate Lucene and Solr development into two
>> independent entities.
>> 
>> To quickly recap the reasons and consequences of such a move: it seems
>> like the reasons for the initial merge of Lucene and Solr, around 10
>> years ago, have been achieved. Both projects are in good shape and
>> exhibit signs of independence already (mailing lists, committers,
>> patch flow). There are many technical considerations that would make
>> development much easier if we move Solr out into its own TLP.
>> 
>> We discussed this issue [2] and both PMC members and committers had a
>> chance to review all the pros and cons and express their views. The
>> discussion showed that there are clearly different opinions on the
>> matter - some people are in favor, some are neutral, others are
>> against or not seeing the point of additional labor. Realistically, I
>> don't think reaching 100% level consensus is going to be possible --
>> we are a diverse bunch with different opinions and personalities. I
>> firmly believe this is the right direction hence the decision to put
>> it under the voting process. Should something take a wrong turn in the
>> future (as some folks worry it may), all blame is on me.
>> 
>> Therefore, the proposal is to separate Solr from under Lucene TLP, and
>> make it a TLP on its own. The initial structure of the new PMC,
>> committer base, git repositories and other managerial aspects can be
>> worked out during the process if the decision passes.
>> 
>> Please indicate one of the following (see [1] for guidelines):
>> 
>> [ ] +1 - yes, I vote for the proposal
>> [ ] -1 - no, I vote against the proposal
>> 
>> Please note that anyone in the Lucene+Solr community is invited to
>> express their opinion, though only Lucene+Solr committers cast binding
>> votes (indicate non-binding votes in your reply, please).
>> 
>> The vote will be active for a week to give everyone a chance to read
>> and cast a vote.
>> 
>> Dawid
>> 
>> [1] https://www.apache.org/foundation/voting.html
>> [2] 
>> https://lists.apache.org/thread.html/rfae2440264f6f874e91545b2030c98e7b7e3854ddf090f7747d338df%40%3Cdev.lucene.apache.org%3E
>> 
>> -
>> 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: [DISCUSS] Lucene-Solr split (Solr promoted to TLP)

[Alan Woodward]

One advantage I find with the way Elasticsearch and Lucene interact is that ES 
doesn’t depend on the master branch.  We upgrade our master branch frequently 
to keep up to date with the latest release branch, and that lets us find 
regressions or API problems pretty quickly, but it also insulates us from 
having to make big changes immediately.  I find this really useful for things 
like deprecations.  Let’s say we deprecate a particular API in the release 
branch, and remove it entirely in master.  Currently, that means Solr needs to 
immediately switch over to the new API in its master branch.  But the whole 
point of doing deprecations first is that it gives users time to find issues 
with the replacements - if we find that the replacement API doesn’t quite fit 
in ES, we have time to work out either how to change our code, or to improve 
the new API, but because the deprecated version is still there we’re not 
blocked from upgrading and getting other improvements.  Solr, meanwhile, may 
end up with a hacky workaround because that’s what got tests passing for the 
Lucene developer; or worse, we end up just copying the deprecated API wholesale 
into Solr and abandoning it there - witness TrieField or UninvertingReader.

> On 11 May 2020, at 19:05, Atri Sharma  wrote:
> 
> My two cents:
> 
> As a Lucene heavy developer, I have several found maintaining Solr
> dependencies while making large changes a bit cumbersome. I believe
> Lucene and Solr should exist in a symbiotic relationship but not
> tightly coupled with each other.
> 
> 
> On Mon, May 11, 2020 at 7:22 PM Erik Hatcher  wrote:
>> 
>> Without reading much or replying to any specific points made on this thread, 
>> here's my raw thoughts on this age-old topic (finally  coming out of my 
>> cocoon after taking things in for a bit)
>> 
>> Solr is a search -server- with distributed capabilities, that leverages the 
>> magic of Lucene underneath.  Solr depends on Lucene, is a consumer of it.  
>> Lucene is a tight search -library- with little to no external dependencies.  
>> Their purposes and end-users are different.
>> 
>> I was never really for the grand unification of Lucene and Solr back in the 
>> day because:
>> 
>> - Solr's developer experience would be greatly streamlined, faster, cleaner, 
>> leaner, and focused
>> - Having Lucene change when Solr doesni't (yet) adapt to those changes leads 
>> to confusion and inconsistency, loose wires hanging out of the wall 
>> unconnected or duct taped together
>> - It simply makes sense to keep Lucene versioned and tightly controlled for 
>> upgrades, various testing configurations varying Lucene versions, within Solr
>> - Solr could have a very concerted upgrade effort for Lucene capability 
>> jumps, with a focused upgrade effort at the changed/improved/added touch 
>> points just like other dependencies within Solr (like Tika and Jetty)
>> 
>> Those points all kinda say the same thing Solr depends on "lucene.jar" 
>> and I'm in the camp that thinks Solr and Lucene development, communities, 
>> and end-users/consumers would all greatly benefit from a fancy new TLP and 
>> focused community for solr.apache.org and a tight(er) relationship with the 
>> Lucene community as an involved and vested consumer.
>> 
>> Erik
>> 
> 
> 
> -- 
> Regards,
> 
> Atri
> Apache Concerted
> 
> -
> 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: [DISCUSS] 8.5.2 Release?

[Alan Woodward]

+1, thanks for volunteering Mike

> On 7 May 2020, at 19:03, Anshum Gupta  > wrote:
> 
> Thanks for doing this, Mike. 
> +1 to the 8.5.2 release. 
> 
> On Thu, May 7, 2020 at 10:13 AM Mike Drob  > wrote:
> Devs,
> 
> I know that we had 8.5.1 only a few weeks ago, but with the fix for 
> LUCENE-9350 I think we should consider another bug-fix. I know that without 
> it I will be explicitly recommending several users to stay off of 8.5.x on 
> their upgrade plans. There are some pretty scary looking charts on SOLR-14428 
> that describe the impact of the bug in more detail.
> 
> I'd be happy to volunteer as RM for this, would probably be looking at trying 
> to get it a vote started sometime next week.
> 
> Thanks,
> Mike
> 
> 
> https://issues.apache.org/jira/browse/SOLR-14428 
> 
> https://issues.apache.org/jira/browse/LUCENE-9350 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Anshum Gupta

Occasional compilation failures from gradle build

[Alan Woodward]

Hi all,

In about 50% of my gradle precommit runs, I get a Solr compilation error that 
looks like this:

/Users/romseygeek/projects/lucene-solr/solr/core/src/test/org/apache/solr/cloud/hdfs/HdfsTestUtil.java:44:
 error: BlockPoolSlice is not public in 
org.apache.hadoop.hdfs.server.datanode.fsdataset.impl; cannot be accessed from 
outside package
import org.apache.hadoop.hdfs.server.datanode.fsdataset.impl.BlockPoolSlice;

From what I can tell, this class is designed to override classes from Hadoop to 
fix certain bugs, but it seems that gradle is sometimes putting the original 
Hadoop class files first in the class path, so the overridden class is not 
picked up.  

Is anyone else seeing this?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Require consistency between different data-structures sharing the same field name as of 9.0?

[Alan Woodward]

One way of doing this might be to add an additional field type that adds both 
point and docvalues, and then have factory methods for queries and sorts on the 
field type.  So for example a LongPointAndValue field would automatically index 
its value into both BKD and NumericDocValues, and then 
LongPointAndValue#newRangeQuery() would build the relevant 
IndexOrDocValuesQuery, and LongPointAndValue#newSortField() would return a sort 
field that can use the shortcuts.

> On 20 Apr 2020, at 14:10, Adrien Grand  > wrote:
> 
> Hello,
> 
> Lucene currently doesn't require consistency across data-structures. For 
> instance it is possible to have different values in points and doc values 
> under the same field name. Until now, we worked around it either by making 
> features use a single data-structure, e.g. facets only use doc values, or by 
> pushing the responsibility of having consistent data across data-structures 
> to the user, e.g. IndexOrDocValuesQuery requires that the point query and the 
> doc-value query match the same documents and it's the responsibility of the 
> user to ensure this.
> 
> I'm unhappy that it makes Lucene very hard to use. Creating an efficient 
> range query should be a one-liner, but due to this limitation, users have to 
> first learn about LongPointQuery#newRangeQuery, 
> NumericDocValuesField#newSlowRangeQuery and then combine them with 
> IndexOrDocValuesQuery or maybe even 
> IndexSortSortedNumericDocValuesRangeQuery. If Lucene had a requirement that 
> if a field both has points and numeric doc values then both data-structurs 
> contain the same content, then we could automatically use the 
> IndexOrDocValuesQuery optimization in LongPoint#newRangeQuery when noticing 
> that the field also has doc values of type NUMERIC or SORTED_NUMERIC.
> 
> This question is being raised again as we are working on dynamically pruning 
> uncompetitive hits when sorting by field by leveraging the points index.[1] 
> This can produce very significant speedups but again requires that the same 
> data be indexed in points and doc values.
> 
> [1] https://github.com/apache/lucene-solr/pull/1351 
> 
> 
> We had discussions about adding a notion of schema of Lucene in the past, see 
> e.g. [2]. This seems desirable to me but also a high hanging fruit and 
> possibly controversial, so my short term proposal would instead be to:
>  - Require documents to be consistent in the data-structures that they use: 
> you can't have one document using only points on a document and another 
> document using only doc values on another document. Of course it would still 
> be possible to index documents that have neither points nor doc values 
> indexed even if previous documents had either enabled in order to handle 
> documents with missing values properly.
>  - Don't hesitate to rely on consistency across fields when implementing new 
> functionality, ie. LongPoint#newRangeQuery would check whether the FieldInfo 
> has numeric doc values, and if so would automatically enable the 
> IndexOrDocValuesQuery and IndexSortSortedNumericDocValuesRangeQuery 
> optimizations.
> 
> [2] https://issues.apache.org/jira/browse/LUCENE-6005 
> 
> 
> Checking that documents have the same values sounds desirable to me but also 
> challenging due to how we sometimes encode data on top of the Lucene APIs, 
> e.g. longs become byte[] in the points index, geo points become a single long 
> in doc values, and we have a few use-cases when we encode muliple values into 
> a single BinaryDocValueField in Elasticsearch to work around the absence of 
> multi-value binary doc values support. I think it'd be acceptable to not 
> validate values but still expect consistency in our search APIs?
> 
> What do you think?
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.5.1 RC1

[Alan Woodward]

+1

SUCCESS! [1:18:54.574272]

> On 8 Apr 2020, at 21:21, Nhat Nguyen  > wrote:
> 
> +1
> 
> SUCCESS! [0:52:20.920081]
> 
> 
> On Wed, Apr 8, 2020 at 6:31 AM Ignacio Vera  > wrote:
> 
> Please vote for release candidate 1 for Lucene/Solr 8.5.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>  
> 
> 
> 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.5.1-RC1-revedb9fc409398f2c3446883f9f80595c884d245d0
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2020-04-15 11:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [1:02:16.691004]
> 

Re: Welcome Eric Pugh as a Lucene/Solr committer

[Alan Woodward]

Welcome Eric!

> On 6 Apr 2020, at 13:21, Jan Høydahl  wrote:
> 
> Hi all,
> 
> Please join me in welcoming Eric Pugh as the latest Lucene/Solr committer!
> 
> Eric has been part of the Solr community for over a decade, as a code 
> contributor, book author, company founder, blogger and mailing list 
> contributor! We look forward to his future contributions!
> 
> Congratulations and welcome! It is a tradition to introduce yourself with a 
> brief bio, Eric.
> 
> Jan Høydahl
> -
> 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

[ANNOUNCE] Apache Solr 8.5.0 released

[Alan Woodward]

## 24 March 2020, Apache Solr™ 8.5.0 available

The Lucene PMC is pleased to announce the release of Apache Solr 8.5.0.

Solr is the popular, blazing fast, open source NoSQL search platform from the 
Apache Lucene project. Its major features include powerful full-text search, 
hit highlighting, faceted search, dynamic clustering, database integration, 
rich document handling, and geospatial search. Solr is highly scalable, 
providing fault tolerant distributed search and indexing, and powers the search 
and navigation features of many of the world's largest internet sites.

Solr 8.5.0 is available for immediate download at:

  

### Solr 8.5.0 Release Highlights:

 * A new queries property of JSON Request API let to declare queries in Query 
DSL format and refer to them by their names.
 * A new command line tool bin/postlogs allows you to index Solr logs into a 
Solr collection. This is helpful for log analysis and troubleshooting. 
Documentation is not yet integrated into the Solr Reference Guide, but is 
available in a branch via GitHub: 
https://github.com/apache/lucene-solr/blob/visual-guide/solr/solr-ref-guide/src/logs.adoc.
 * A new stream decorator delete() is available to help solve some issues with 
traditional delete-by-query, which can be expensive in large indexes.
 * Solr now has the ability to run with a Java Security Manager enabled.

Please read CHANGES.txt for a full list of changes:

  

Solr 8.5.0 also includes improvements and bugfixes in the corresponding Apache 
Lucene release:

  


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

[ANNOUNCE] Apache Lucene 8.5.0 released

[Alan Woodward]

## 24 March 2020, Apache Lucene 8.5.0 available

The Lucene PMC is pleased to announce the release of Apache Lucene 8.5.0.

Apache Lucene is a high-performance, full-featured text search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires full-text search, especially cross-platform.

This release contains numerous bug fixes, optimizations, and improvements, some 
of which are highlighted below. The release is available for immediate download 
at:

 

### Lucene 8.5.0 Release Highlights:

* XYPointField allows you to index points in flat X,Y space and efficiently 
find documents that fall within a bounding box, distance or arbitrary polygon
* New query builders on LatLonShape allow you to efficiently find documents 
with a specific relation to a point or polygon
* You can now store up to 16 data dimensions in a Point field
* KoreanTokenizer supports custom dictionaries
* Binary doc values are now compressed, and term dictionaries have improved 
compression
* Index flushes are up to 20% faster if all docvalues updates are updating a 
single field to the same value
* The index of stored fields and term vectors is now stored off-heap
* Query parsers based on QueryBuilder can boost particular terms or synonyms by 
setting BoostAttribute values on a token stream
* Intervals queries correctly handle repeated subterms in ordered and unordered 
sources

Please read CHANGES.txt for a full list of new features and changes:

 


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

Re: 8.5 release

[Alan Woodward]

Hi all,

Just to say that the release is still happening, it’s just taking a bit longer 
than usual to get things sorted due to some external circumstances…

The release is now on the apache mirrors and maven central (we need to update 
the poll_mirrors script to correctly handle https, as lots of the mirrors no 
longer accept http).  I’m trying to update the website with the new java docs, 
but it looks as though this has all been changed since the last release, and 
the instructions on our release website no longer apply.  In particular, the 
svn repository where the java docs used to sit now has a single empty file 
called MOVED_TO_GIT - if anybody knows more about this, please chime in!

- A

> On 19 Mar 2020, at 15:06, Alan Woodward  wrote:
> 
> I’ll check on the Lucene notes.  Thanks Cassandra!
> 
>> On 19 Mar 2020, at 14:06, Cassandra Targett > <mailto:casstarg...@gmail.com>> wrote:
>> 
>> I’ll look to add the release instructions soon. There is a page in the Ref 
>> Guide that describes how to do it (it’s basically the same as javadocs, just 
>> a different ant/gradle target).
>> 
>> I also created a new top-level page in Solr’s Confluence for Release Notes: 
>> https://cwiki.apache.org/confluence/display/SOLR/Release+Notes 
>> <https://cwiki.apache.org/confluence/display/SOLR/Release+Notes>. I only 
>> moved 8.x and a couple 7.x notes there for now (it’s a bit tedious to move 
>> them, but anyone would be welcome to keep going) so we can use that spot to 
>> put them from now on. I didn’t check, though, if Lucene’s Confluence has the 
>> same problem of notes being buried? Sorry to half-complete the task, I was 
>> looking for Solr's notes and got annoyed I can never find them quickly.
>> 
>> Cassandra
>> On Mar 17, 2020, 5:50 AM -0500, Alan Woodward > <mailto:romseyg...@gmail.com>>, wrote:
>>> If you add the release instructions to the ReleaseTodo page on cwiki then 
>>> the RM should be able to follow them.  I can look into adding them to the 
>>> release wizard as well.
>>> 
>>>> On 16 Mar 2020, at 15:15, Cassandra Targett >>> <mailto:casstarg...@gmail.com>> wrote:
>>>> 
>>>> What do we need to do to get pushing the Ref Guide up as part of the RM 
>>>> process? It’s super simple now, but I’m not sure what needs to change to 
>>>> make it happen regularly as part of release.
>>>> 
>>>> Cassandra
>>>> On Mar 16, 2020, 3:48 AM -0500, Alan Woodward >>> <mailto:romseyg...@gmail.com>>, wrote:
>>>>> Let’s keep both pages as Draft for now - one advantage of Cwiki over moin 
>>>>> is that we can delay publishing our release notes until the release has 
>>>>> actually happened.
>>>>> 
>>>>>> On 16 Mar 2020, at 08:20, Mikhail Khludnev >>>>> <mailto:m...@apache.org>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Alan, I've added a point. Should I click [Publish]?
>>>>>> 
>>>>>> On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward >>>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>>> That’s the one, thank you Jan!  I’ve cloned it and made minimal changes 
>>>>>> to update it to 8.5, it still needs the release highlights adding in 
>>>>>> though.  Draft page is available here:
>>>>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
>>>>>>  
>>>>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180>
>>>>>> 
>>>>>> We should definitely make a top-level page for these, they currently sit 
>>>>>> under ‘Old Wiki’ which doesn’t seem right at all.
>>>>>> 
>>>>>>> On 13 Mar 2020, at 11:20, Jan Høydahl >>>>>> <mailto:jan@cominvent.com>> wrote:
>>>>>>> 
>>>>>>> Perhaps this is the one you are looking for? 
>>>>>>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
>>>>>>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84>
>>>>>>> 
>>>>>>> We should probably make a top-level page «Release Notes» under which we 
>>>>>>> can attach future release notes.
>>>>>>> 
>>>>>>> Jan
>>>>>>>

Re: 8.5 release

[Alan Woodward]

I’ll check on the Lucene notes.  Thanks Cassandra!

> On 19 Mar 2020, at 14:06, Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> 
> I’ll look to add the release instructions soon. There is a page in the Ref 
> Guide that describes how to do it (it’s basically the same as javadocs, just 
> a different ant/gradle target).
> 
> I also created a new top-level page in Solr’s Confluence for Release Notes: 
> https://cwiki.apache.org/confluence/display/SOLR/Release+Notes 
> <https://cwiki.apache.org/confluence/display/SOLR/Release+Notes>. I only 
> moved 8.x and a couple 7.x notes there for now (it’s a bit tedious to move 
> them, but anyone would be welcome to keep going) so we can use that spot to 
> put them from now on. I didn’t check, though, if Lucene’s Confluence has the 
> same problem of notes being buried? Sorry to half-complete the task, I was 
> looking for Solr's notes and got annoyed I can never find them quickly.
> 
> Cassandra
> On Mar 17, 2020, 5:50 AM -0500, Alan Woodward  <mailto:romseyg...@gmail.com>>, wrote:
>> If you add the release instructions to the ReleaseTodo page on cwiki then 
>> the RM should be able to follow them.  I can look into adding them to the 
>> release wizard as well.
>> 
>>> On 16 Mar 2020, at 15:15, Cassandra Targett >> <mailto:casstarg...@gmail.com>> wrote:
>>> 
>>> What do we need to do to get pushing the Ref Guide up as part of the RM 
>>> process? It’s super simple now, but I’m not sure what needs to change to 
>>> make it happen regularly as part of release.
>>> 
>>> Cassandra
>>> On Mar 16, 2020, 3:48 AM -0500, Alan Woodward >> <mailto:romseyg...@gmail.com>>, wrote:
>>>> Let’s keep both pages as Draft for now - one advantage of Cwiki over moin 
>>>> is that we can delay publishing our release notes until the release has 
>>>> actually happened.
>>>> 
>>>>> On 16 Mar 2020, at 08:20, Mikhail Khludnev >>>> <mailto:m...@apache.org>> wrote:
>>>>> 
>>>>> 
>>>>> Alan, I've added a point. Should I click [Publish]?
>>>>> 
>>>>> On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward >>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>> That’s the one, thank you Jan!  I’ve cloned it and made minimal changes 
>>>>> to update it to 8.5, it still needs the release highlights adding in 
>>>>> though.  Draft page is available here:
>>>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
>>>>>  
>>>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180>
>>>>> 
>>>>> We should definitely make a top-level page for these, they currently sit 
>>>>> under ‘Old Wiki’ which doesn’t seem right at all.
>>>>> 
>>>>>> On 13 Mar 2020, at 11:20, Jan Høydahl >>>>> <mailto:jan@cominvent.com>> wrote:
>>>>>> 
>>>>>> Perhaps this is the one you are looking for? 
>>>>>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
>>>>>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84>
>>>>>> 
>>>>>> We should probably make a top-level page «Release Notes» under which we 
>>>>>> can attach future release notes.
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 12. mar. 2020 kl. 17:24 skrev Alan Woodward >>>>>> <mailto:romseyg...@gmail.com>>:
>>>>>>> 
>>>>>>> While I wait for the smoke tester to finish, I’ve been working on 
>>>>>>> release notes.  The ReleaseTodo still refers to the old wiki, and 
>>>>>>> release notes are on CWiki now, so I’m flying slightly blind.  Looking 
>>>>>>> at what was done for the previous release, I’ve created a draft note 
>>>>>>> for lucene which can be inspected and edited here:
>>>>>>> 
>>>>>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>>>>>>  
>>>>>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=15840

Re: Welcome Alessandro Benedetti as a Lucene/Solr committer

[Alan Woodward]

Congratulations and welcome, Alessandro!  More committers for the London 
meet-up, whenever they start again :)

> On 18 Mar 2020, at 13:00, David Smiley  > wrote:
> 
> Hi all,
> 
> Please join me in welcoming Alessandro Benedetti as the latest Lucene/Solr 
> committer!
> 
> Alessandro has been contributing to Lucene and Solr in areas such as More 
> Like This, Synonym boosting, and Suggesters, and other areas for years.  
> Furthermore he's been a help to many users on the solr-user mailing list and 
> has helped others through his blog posts and presentations about search.  We 
> look forward to his future contributions.
> 
> Congratulations and welcome!  It is a tradition to introduce yourself with a 
> brief bio, Alessandro.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 

[RESULT][VOTE] Release Lucene/Solr 8.5.0 RC1

[Alan Woodward]

It’s been >72 hours since the vote was initiated and the result is:

+1  10 (8 binding)
 0  0
-1  0

This vote has PASSED
-
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.5.0 RC1

[Alan Woodward]

the Solr Ref Guide DRAFT up this morning (thought I did it on 
>>>>>>>> Friday, sorry): https://lucene.apache.org/solr/guide/8_5/ 
>>>>>>>> <https://lucene.apache.org/solr/guide/8_5/>.
>>>>>>>> 
>>>>>>>> Cassandra
>>>>>>>> On Mar 15, 2020, 6:06 PM -0500, Uwe Schindler >>>>>>> <mailto:u...@thetaphi.de>>, wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I instructed Policeman Jenkins to automatically test the release for 
>>>>>>>> me, the result (Java 8 / Java 9 combined Smoketesting):
>>>>>>>> 
>>>>>>>> SUCCESS! [1:24:47.422173]
>>>>>>>> (see 
>>>>>>>> https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/30/console 
>>>>>>>> <https://jenkins.thetaphi.de/job/Lucene-Solr-Release-Tester/30/console>)
>>>>>>>> 
>>>>>>>> I also downloaded the artifacts and tested manually:
>>>>>>>> - Solr starts and stops perfectly on Windows with whitespace in path 
>>>>>>>> name: Java 8, Java 11 and Java 14 (coming out soon)
>>>>>>>> - Javadocs of Lucene look fine
>>>>>>>> - JAR files look good
>>>>>>>> - All links to repos in pom.xml and ant use HTTPS
>>>>>>>> 
>>>>>>>> So I am fine with releasing this.
>>>>>>>> +1 to RELEASE!
>>>>>>>> 
>>>>>>>> Uwe
>>>>>>>> 
>>>>>>>> -
>>>>>>>> Uwe Schindler
>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>>>>>>> eMail: u...@thetaphi.de
>>>>>>>> 
>>>>>>>> -Original Message-
>>>>>>>> From: Alan Woodward 
>>>>>>>> Sent: Friday, March 13, 2020 3:27 PM
>>>>>>>> To: dev@lucene.apache.org
>>>>>>>> Subject: [VOTE] Release Lucene/Solr 8.5.0 RC1
>>>>>>>> 
>>>>>>>> Please vote for release candidate 1 for Lucene/Solr 8.5.0
>>>>>>>> 
>>>>>>>> The artifacts can be downloaded from:
>>>>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.5.0-RC1-
>>>>>>>> rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
>>>>>>>> 
>>>>>>>> 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.5.0-RC1-
>>>>>>>> rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42
>>>>>>>> 
>>>>>>>> The vote will be open for three working days i.e. until next Tuesday, 
>>>>>>>> 2020-03-
>>>>>>>> 18 14:00 UTC.
>>>>>>>> 
>>>>>>>> [ ] +1 approve
>>>>>>>> [ ] +0 no opinion
>>>>>>>> [ ] -1 disapprove (and reason why)
>>>>>>>> 
>>>>>>>> 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 
>>>>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>>>>> <mailto:dev-h...@lucene.apache.org>
>>>>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> <mailto:dev-unsubscr...@lucene.apache.org>
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> <mailto:dev-h...@lucene.apache.org>
>> 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> <mailto:dev-unsubscr...@lucene.apache.org>
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> <mailto:dev-h...@lucene.apache.org>
> 

Re: 8.5 release

[Alan Woodward]

If you add the release instructions to the ReleaseTodo page on cwiki then the 
RM should be able to follow them.  I can look into adding them to the release 
wizard as well.

> On 16 Mar 2020, at 15:15, Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> 
> What do we need to do to get pushing the Ref Guide up as part of the RM 
> process? It’s super simple now, but I’m not sure what needs to change to make 
> it happen regularly as part of release.
> 
> Cassandra
> On Mar 16, 2020, 3:48 AM -0500, Alan Woodward  <mailto:romseyg...@gmail.com>>, wrote:
>> Let’s keep both pages as Draft for now - one advantage of Cwiki over moin is 
>> that we can delay publishing our release notes until the release has 
>> actually happened.
>> 
>>> On 16 Mar 2020, at 08:20, Mikhail Khludnev >> <mailto:m...@apache.org>> wrote:
>>> 
>>> 
>>> Alan, I've added a point. Should I click [Publish]?
>>> 
>>> On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward >> <mailto:romseyg...@gmail.com>> wrote:
>>> That’s the one, thank you Jan!  I’ve cloned it and made minimal changes to 
>>> update it to 8.5, it still needs the release highlights adding in though.  
>>> Draft page is available here:
>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
>>>  
>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180>
>>> 
>>> We should definitely make a top-level page for these, they currently sit 
>>> under ‘Old Wiki’ which doesn’t seem right at all.
>>> 
>>>> On 13 Mar 2020, at 11:20, Jan Høydahl >>> <mailto:jan@cominvent.com>> wrote:
>>>> 
>>>> Perhaps this is the one you are looking for? 
>>>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
>>>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84>
>>>> 
>>>> We should probably make a top-level page «Release Notes» under which we 
>>>> can attach future release notes.
>>>> 
>>>> Jan
>>>> 
>>>>> 12. mar. 2020 kl. 17:24 skrev Alan Woodward >>>> <mailto:romseyg...@gmail.com>>:
>>>>> 
>>>>> While I wait for the smoke tester to finish, I’ve been working on release 
>>>>> notes.  The ReleaseTodo still refers to the old wiki, and release notes 
>>>>> are on CWiki now, so I’m flying slightly blind.  Looking at what was done 
>>>>> for the previous release, I’ve created a draft note for lucene which can 
>>>>> be inspected and edited here:
>>>>> 
>>>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>>>>  
>>>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>
>>>>> 
>>>>> For Solr, the 8.4 release note on CWiki points to a section on 
>>>>> https://lucene.apache.org/solr/news.html 
>>>>> <https://lucene.apache.org/solr/news.html>  but it’s not entirely clear 
>>>>> where this section has come from or where it should be drafted.  Can 
>>>>> anybody enlighten me?
>>>>> 
>>>>>> On 11 Mar 2020, at 09:20, Alan Woodward >>>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>>> 
>>>>>> Sure, go ahead
>>>>>> 
>>>>>>> On 10 Mar 2020, at 19:22, David Smiley >>>>>> <mailto:david.w.smi...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>>>>>> improvement on the release branch irrespective of whenever you 
>>>>>>> precisely do the RC?
>>>>>>> 
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley 
>>>>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>>>>> 
>>>>>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>>>>> <mailto:joels...@gmail.com>> wrote:
>>>>>>> I just updated solr/CHANGES.txt as I mis

Re: 8.5 release

[Alan Woodward]

Let’s keep both pages as Draft for now - one advantage of Cwiki over moin is 
that we can delay publishing our release notes until the release has actually 
happened.

> On 16 Mar 2020, at 08:20, Mikhail Khludnev  <mailto:m...@apache.org>> wrote:
> 
> 
> Alan, I've added a point. Should I click [Publish]?
> 
> On Fri, Mar 13, 2020 at 5:31 PM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> That’s the one, thank you Jan!  I’ve cloned it and made minimal changes to 
> update it to 8.5, it still needs the release highlights adding in though.  
> Draft page is available here:
> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
>  
> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180>
> 
> We should definitely make a top-level page for these, they currently sit 
> under ‘Old Wiki’ which doesn’t seem right at all.
> 
>> On 13 Mar 2020, at 11:20, Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> 
>> Perhaps this is the one you are looking for? 
>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84>
>> 
>> We should probably make a top-level page «Release Notes» under which we can 
>> attach future release notes.
>> 
>> Jan
>> 
>>> 12. mar. 2020 kl. 17:24 skrev Alan Woodward >> <mailto:romseyg...@gmail.com>>:
>>> 
>>> While I wait for the smoke tester to finish, I’ve been working on release 
>>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>>> the previous release, I’ve created a draft note for lucene which can be 
>>> inspected and edited here:
>>> 
>>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>>  
>>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>
>>> 
>>> For Solr, the 8.4 release note on CWiki points to a section on 
>>> https://lucene.apache.org/solr/news.html 
>>> <https://lucene.apache.org/solr/news.html>  but it’s not entirely clear 
>>> where this section has come from or where it should be drafted.  Can 
>>> anybody enlighten me?
>>> 
>>>> On 11 Mar 2020, at 09:20, Alan Woodward >>> <mailto:romseyg...@gmail.com>> wrote:
>>>> 
>>>> Sure, go ahead
>>>> 
>>>>> On 10 Mar 2020, at 19:22, David Smiley >>>> <mailto:david.w.smi...@gmail.com>> wrote:
>>>>> 
>>>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>>>> improvement on the release branch irrespective of whenever you precisely 
>>>>> do the RC?
>>>>> 
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley 
>>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>>> <mailto:joels...@gmail.com>> wrote:
>>>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>>>> created the RC then it will be there in case of a respin.
>>>>> 
>>>>> 
>>>>> 
>>>>> Joel Bernstein
>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>> 
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>>> <mailto:iver...@gmail.com>> wrote:
>>>>> done. Thank you!
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>> Go ahead, I’ll start the release build once it’s in.
>>>>> 
>>>>>> On 10 Mar 2020, at 07:26, Ignacio Vera >>>>> <mailto:iver...@gmail.com>> wrote:
>>>>>> 
>>>>>> Hi Alanm
>>>>>> 
>>>>>> Is it  possible to backport 
>>>>>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>>>>> <https://issues.apache.org/jira/browse/LUCENE-9263> fo

[VOTE] Release Lucene/Solr 8.5.0 RC1

[Alan Woodward]

Please vote for release candidate 1 for Lucene/Solr 8.5.0

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

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.5.0-RC1-rev7ac489bf7b97b61749b19fa2ee0dc46e74b8dc42

The vote will be open for three working days i.e. until next Tuesday, 
2020-03-18 14:00 UTC.

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

Here is my +1
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: 8.5 release

[Alan Woodward]

That’s the one, thank you Jan!  I’ve cloned it and made minimal changes to 
update it to 8.5, it still needs the release highlights adding in though.  
Draft page is available here:
https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180
 
<https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641910=8a43c9fb-6845-413a-b6cd-876a6647bb32=shareui=1584107316180>

We should definitely make a top-level page for these, they currently sit under 
‘Old Wiki’ which doesn’t seem right at all.

> On 13 Mar 2020, at 11:20, Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> 
> Perhaps this is the one you are looking for? 
> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84 
> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote84>
> 
> We should probably make a top-level page «Release Notes» under which we can 
> attach future release notes.
> 
> Jan
> 
>> 12. mar. 2020 kl. 17:24 skrev Alan Woodward > <mailto:romseyg...@gmail.com>>:
>> 
>> While I wait for the smoke tester to finish, I’ve been working on release 
>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>> the previous release, I’ve created a draft note for lucene which can be 
>> inspected and edited here:
>> 
>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>  
>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>
>> 
>> For Solr, the 8.4 release note on CWiki points to a section on 
>> https://lucene.apache.org/solr/news.html 
>> <https://lucene.apache.org/solr/news.html>  but it’s not entirely clear 
>> where this section has come from or where it should be drafted.  Can anybody 
>> enlighten me?
>> 
>>> On 11 Mar 2020, at 09:20, Alan Woodward >> <mailto:romseyg...@gmail.com>> wrote:
>>> 
>>> Sure, go ahead
>>> 
>>>> On 10 Mar 2020, at 19:22, David Smiley >>> <mailto:david.w.smi...@gmail.com>> wrote:
>>>> 
>>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>>> improvement on the release branch irrespective of whenever you precisely 
>>>> do the RC?
>>>> 
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley 
>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>> 
>>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>> <mailto:joels...@gmail.com>> wrote:
>>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>>> created the RC then it will be there in case of a respin.
>>>> 
>>>> 
>>>> 
>>>> Joel Bernstein
>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>> 
>>>> 
>>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>> <mailto:iver...@gmail.com>> wrote:
>>>> done. Thank you!
>>>> 
>>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>> <mailto:romseyg...@gmail.com>> wrote:
>>>> Go ahead, I’ll start the release build once it’s in.
>>>> 
>>>>> On 10 Mar 2020, at 07:26, Ignacio Vera >>>> <mailto:iver...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Alanm
>>>>> 
>>>>> Is it  possible to backport 
>>>>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>>>> <https://issues.apache.org/jira/browse/LUCENE-9263> for the 8.5 release, 
>>>>> I push it tester day and CI is happy.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >>>> <mailto:joels...@gmail.com>> wrote:
>>>>> 
>>>>> Finished the backport for 
>>>>> https://issues.apache.org/jira/browse/SOLR-14073 
>>>>> <https://issues.apache.org/jira/browse/SOLR-14073>.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> 
>>>>> Joel Bernstein
>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>> 
>>>>> 
>>>>>

Re: 8.5 release

[Alan Woodward]

Hi Andrzej, sorry to miss this - I’ve just started a vote on RC1 but if that 
doesn’t pass then we can get this bug fix in.

> On 12 Mar 2020, at 17:18, Andrzej Białecki  wrote:
> 
> Hi Alan,
> 
> Is there still time to merge a fix for SOLR-13264? It’s a bug that makes it 
> impossible to customise this trigger, you can only config a trigger with its 
> default operations.
> 
>> On 12 Mar 2020, at 17:24, Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>> 
>> While I wait for the smoke tester to finish, I’ve been working on release 
>> notes.  The ReleaseTodo still refers to the old wiki, and release notes are 
>> on CWiki now, so I’m flying slightly blind.  Looking at what was done for 
>> the previous release, I’ve created a draft note for lucene which can be 
>> inspected and edited here:
>> 
>> https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
>>  
>> <https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>
>> 
>> For Solr, the 8.4 release note on CWiki points to a section on 
>> https://lucene.apache.org/solr/news.html 
>> <https://lucene.apache.org/solr/news.html>  but it’s not entirely clear 
>> where this section has come from or where it should be drafted.  Can anybody 
>> enlighten me?
>> 
>>> On 11 Mar 2020, at 09:20, Alan Woodward >> <mailto:romseyg...@gmail.com>> wrote:
>>> 
>>> Sure, go ahead
>>> 
>>>> On 10 Mar 2020, at 19:22, David Smiley >>> <mailto:david.w.smi...@gmail.com>> wrote:
>>>> 
>>>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>>>> improvement on the release branch irrespective of whenever you precisely 
>>>> do the RC?
>>>> 
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley 
>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>> 
>>>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein >>> <mailto:joels...@gmail.com>> wrote:
>>>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>>>> created the RC then it will be there in case of a respin.
>>>> 
>>>> 
>>>> 
>>>> Joel Bernstein
>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>> 
>>>> 
>>>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera >>> <mailto:iver...@gmail.com>> wrote:
>>>> done. Thank you!
>>>> 
>>>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward >>> <mailto:romseyg...@gmail.com>> wrote:
>>>> Go ahead, I’ll start the release build once it’s in.
>>>> 
>>>>> On 10 Mar 2020, at 07:26, Ignacio Vera >>>> <mailto:iver...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Alanm
>>>>> 
>>>>> Is it  possible to backport 
>>>>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>>>> <https://issues.apache.org/jira/browse/LUCENE-9263> for the 8.5 release, 
>>>>> I push it tester day and CI is happy.
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >>>> <mailto:joels...@gmail.com>> wrote:
>>>>> 
>>>>> Finished the backport for 
>>>>> https://issues.apache.org/jira/browse/SOLR-14073 
>>>>> <https://issues.apache.org/jira/browse/SOLR-14073>.
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>> 
>>>>> Joel Bernstein
>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>> 
>>>>> 
>>>>> On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein >>>> <mailto:joels...@gmail.com>> wrote:
>>>>> Ok, I'll do the backport today. Thanks!
>>>>> 
>>>>> Joel Bernstein
>>>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>>>> 
>>>>> 
>>>>> On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward >>>> <mailto:romseyg...@gmail.com>> wrote:
>>>>> Thanks Uwe!
>>>>> 
>>>>>> On 7 Mar 2020, at 10:06, Uwe Schindler >>>&g

Re: 8.5 release

[Alan Woodward]

While I wait for the smoke tester to finish, I’ve been working on release 
notes.  The ReleaseTodo still refers to the old wiki, and release notes are on 
CWiki now, so I’m flying slightly blind.  Looking at what was done for the 
previous release, I’ve created a draft note for lucene which can be inspected 
and edited here:

https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586
 
<https://cwiki.apache.org/confluence/pages/resumedraft.action?draftId=148641343=d4d3acb9-0dd6-4d40-903c-b16f2bb68415=shareui=1584025014586>

For Solr, the 8.4 release note on CWiki points to a section on 
https://lucene.apache.org/solr/news.html 
<https://lucene.apache.org/solr/news.html>  but it’s not entirely clear where 
this section has come from or where it should be drafted.  Can anybody 
enlighten me?

> On 11 Mar 2020, at 09:20, Alan Woodward  wrote:
> 
> Sure, go ahead
> 
>> On 10 Mar 2020, at 19:22, David Smiley > <mailto:david.w.smi...@gmail.com>> wrote:
>> 
>> Can I assume it's no big deal to post a solr-ref-guide documentation 
>> improvement on the release branch irrespective of whenever you precisely do 
>> the RC?
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley 
>> <http://www.linkedin.com/in/davidwsmiley>
>> 
>> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein > <mailto:joels...@gmail.com>> wrote:
>> I just updated solr/CHANGES.txt as I missed something. If you've already 
>> created the RC then it will be there in case of a respin.
>> 
>> 
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>> 
>> 
>> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera > <mailto:iver...@gmail.com>> wrote:
>> done. Thank you!
>> 
>> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>> Go ahead, I’ll start the release build once it’s in.
>> 
>>> On 10 Mar 2020, at 07:26, Ignacio Vera >> <mailto:iver...@gmail.com>> wrote:
>>> 
>>> Hi Alanm
>>> 
>>> Is it  possible to backport 
>>> https://issues.apache.org/jira/browse/LUCENE-9263 
>>> <https://issues.apache.org/jira/browse/LUCENE-9263> for the 8.5 release, I 
>>> push it tester day and CI is happy.
>>> 
>>> Thanks,
>>> 
>>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein >> <mailto:joels...@gmail.com>> wrote:
>>> 
>>> Finished the backport for https://issues.apache.org/jira/browse/SOLR-14073 
>>> <https://issues.apache.org/jira/browse/SOLR-14073>.
>>> 
>>> Thanks!
>>> 
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>> 
>>> 
>>> On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein >> <mailto:joels...@gmail.com>> wrote:
>>> Ok, I'll do the backport today. Thanks!
>>> 
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>>> 
>>> 
>>> On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward >> <mailto:romseyg...@gmail.com>> wrote:
>>> Thanks Uwe!
>>> 
>>>> On 7 Mar 2020, at 10:06, Uwe Schindler >>> <mailto:u...@thetaphi.de>> wrote:
>>>> 
>>>> Hi,
>>>>  
>>>> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch 
>>>> is in the loop on ASF Jenkins and Policeman Jenkins.
>>>>  
>>>> Uwe
>>>>  
>>>> -
>>>> Uwe Schindler
>>>> Achterdiek 19, D-28357 Bremen
>>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>>>  
>>>> From: Alan Woodward mailto:romseyg...@gmail.com>> 
>>>> Sent: Wednesday, March 4, 2020 5:35 PM
>>>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>>>> Subject: Re: 8.5 release
>>>>  
>>>> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to 
>>>> the apache repository.  We’re now at feature freeze, so only bug fixes 
>>>> should be pushed to the branch.
>>>>  
>>>> I can see from 
>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20f

Re: 8.5 release

[Alan Woodward]

Sure, go ahead

> On 10 Mar 2020, at 19:22, David Smiley  <mailto:david.w.smi...@gmail.com>> wrote:
> 
> Can I assume it's no big deal to post a solr-ref-guide documentation 
> improvement on the release branch irrespective of whenever you precisely do 
> the RC?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> <http://www.linkedin.com/in/davidwsmiley>
> 
> On Tue, Mar 10, 2020 at 9:15 AM Joel Bernstein  <mailto:joels...@gmail.com>> wrote:
> I just updated solr/CHANGES.txt as I missed something. If you've already 
> created the RC then it will be there in case of a respin.
> 
> 
> 
> Joel Bernstein
> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
> 
> 
> On Tue, Mar 10, 2020 at 5:45 AM Ignacio Vera  <mailto:iver...@gmail.com>> wrote:
> done. Thank you!
> 
> On Tue, Mar 10, 2020 at 10:43 AM Alan Woodward  <mailto:romseyg...@gmail.com>> wrote:
> Go ahead, I’ll start the release build once it’s in.
> 
>> On 10 Mar 2020, at 07:26, Ignacio Vera > <mailto:iver...@gmail.com>> wrote:
>> 
>> Hi Alanm
>> 
>> Is it  possible to backport 
>> https://issues.apache.org/jira/browse/LUCENE-9263 
>> <https://issues.apache.org/jira/browse/LUCENE-9263> for the 8.5 release, I 
>> push it tester day and CI is happy.
>> 
>> Thanks,
>> 
>> On Tue, Mar 10, 2020 at 2:35 AM Joel Bernstein > <mailto:joels...@gmail.com>> wrote:
>> 
>> Finished the backport for https://issues.apache.org/jira/browse/SOLR-14073 
>> <https://issues.apache.org/jira/browse/SOLR-14073>.
>> 
>> Thanks!
>> 
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>> 
>> 
>> On Mon, Mar 9, 2020 at 8:44 AM Joel Bernstein > <mailto:joels...@gmail.com>> wrote:
>> Ok, I'll do the backport today. Thanks!
>> 
>> Joel Bernstein
>> http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/>
>> 
>> 
>> On Mon, Mar 9, 2020 at 6:21 AM Alan Woodward > <mailto:romseyg...@gmail.com>> wrote:
>> Thanks Uwe!
>> 
>>> On 7 Mar 2020, at 10:06, Uwe Schindler >> <mailto:u...@thetaphi.de>> wrote:
>>> 
>>> Hi,
>>>  
>>> FYI, I cleaned, renamed, and changed the Jenkins Jobs, so the 8.5 branch is 
>>> in the loop on ASF Jenkins and Policeman Jenkins.
>>>  
>>> Uwe
>>>  
>>> -
>>> Uwe Schindler
>>> Achterdiek 19, D-28357 Bremen
>>> https://www.thetaphi.de <https://www.thetaphi.de/>
>>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>>  
>>> From: Alan Woodward mailto:romseyg...@gmail.com>> 
>>> Sent: Wednesday, March 4, 2020 5:35 PM
>>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>>> Subject: Re: 8.5 release
>>>  
>>> I’ve created a branch for the 8.5 release (`branch_8_5`) and pushed it to 
>>> the apache repository.  We’re now at feature freeze, so only bug fixes 
>>> should be pushed to the branch.
>>>  
>>> I can see from 
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20status%20in%20(Open%2C%20Reopened)%20AND%20priority%20%3D%20Blocker%20AND%20fixVersion%20%3D%208.5%20ORDER%20BY%20priority%20DESC
>>>  
>>> <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR,%20LUCENE)%20AND%20status%20in%20(Open,%20Reopened)%20AND%20priority%20=%20Blocker%20AND%20fixVersion%20=%208.5%20ORDER%20BY%20priority%20DESC>
>>>  that we have 4 tickets marked as Blockers for this release.  I plan to 
>>> build a first release candidate next Monday, which gives us a few days to 
>>> resolve these.  If that’s not going to be long enough, please let me know.
>>>  
>>> Uwe, Steve, can one of you start the Jenkins tasks for the new branch?
>>>  
>>> Thanks, Alan
>>> 
>>> 
>>>> On 3 Mar 2020, at 14:50, Alan Woodward >>> <mailto:romseyg...@gmail.com>> wrote:
>>>>  
>>>> PSA: I’ve had to generate a new GPG key for this release, and it takes a 
>>>> while for it to get mirrored to the lucene KEYS file.  I’ll hold off 
>>>> cutting the branch until everything is ready, so it will probably now be 
>>>> tomorrow UK time before I start the release proper.
>>>> 
>>>> 
>>>>> On 25 Feb 2020, at 07:49, Noble Paul >>>> <mailto:nob