Re: [PR] Use group-varint encoding for the tail of postings [lucene]
easyice commented on PR #12782: URL: https://github.com/apache/lucene/pull/12782#issuecomment-1958968291 > @easyice Hi， I have doubt that the encoding data result using group-varint encoding is different from the old way, so is this way compatible with the old index format data? This change was released at lucene 9.9.0, which uses a new version of posting format `Lucene99PostingsFormat`, if you read a old index format, it will use the matching posting format class to decode the index. so it will compatible with the old index. Have you got specific errors? could you give some detailed message? Thanks! See https://lucene.apache.org/core/9_9_0/changes/Changes.html#v9.9.0.optimizations -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] LUCENE-8739: Add ZSTD support. [lucene]
believezzd commented on PR #174: URL: https://github.com/apache/lucene/pull/174#issuecomment-1959010131 @jpountz ## Description * There are two place code that i can't understand in this commit, could you please give me help. ## First one * To ZstdStoredFieldsFormat#ZstdDecompressor.decompress(124) * why it has to skip blocks. As I know, in the compress, the compressed sub_block appends to output one by one. it it just decompress from offset to offset+length. Just As DeflateDecompressor.decompress ## Second one * To ZstdStoredFieldsFormat#ZstdDecompressor.decompress(145) * why it reset bytes.offset and bytes.length to other value in the end. As I can see, in the end, bytes.offset should be zero and bytes.length should be originalLength. Same as DeflateDecompressor.decompress in the end. Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Use group-varint encoding for the tail of postings [lucene]
wjp719 commented on PR #12782: URL: https://github.com/apache/lucene/pull/12782#issuecomment-1959222579 > Have you got specific errors? could you give some detailed message? Thanks! I have no errors,I didn't realize the new format was used, Thanks. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] FieldInfosFormat translation should be independent of VectorSimilartyFunction enum [lucene]
benwtrent commented on code in PR #13119:
URL: https://github.com/apache/lucene/pull/13119#discussion_r1499170841
##
lucene/core/src/java/org/apache/lucene/codecs/lucene99/Lucene99HnswVectorsReader.java:
##
@@ -171,15 +172,25 @@ private void validateFieldEntry(FieldInfo info,
FieldEntry fieldEntry) {
}
}
+ // List of vector similarity functions. This list is defined here, in order
+ // to avoid an undesirable dependency on the declaration and order of values
+ // in VectorSimilarityFunction. The list values and order have been chosen to
+ // match that of VectorSimilarityFunction in, at least, Lucene 9.10. Values
+ // should only be appended to the end of the list.
+ public static final List SIMILARITY_FUNCTIONS =
Review Comment:
Since (for some unknown reason to me), we already write out the values to
the codec files & we don't want to break the current codec, this is fine with
me.
I think if/when we create a new HNSW/vector codecs in the future, we should
consider not writing the danged similarity functions in two places.
##
lucene/core/src/java/org/apache/lucene/codecs/lucene99/Lucene99HnswVectorsReader.java:
##
@@ -171,15 +172,25 @@ private void validateFieldEntry(FieldInfo info,
FieldEntry fieldEntry) {
}
}
+ // List of vector similarity functions. This list is defined here, in order
+ // to avoid an undesirable dependency on the declaration and order of values
+ // in VectorSimilarityFunction. The list values and order have been chosen to
+ // match that of VectorSimilarityFunction in, at least, Lucene 9.10. Values
+ // should only be appended to the end of the list.
+ public static final List SIMILARITY_FUNCTIONS =
Review Comment:
Could you add/complete your comment indicating that the values here need to
be in order and the SAME order as the field info ones for bwc?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add new parallel merge task executor for parallel actions within a single merge action [lucene]
benwtrent commented on code in PR #13124:
URL: https://github.com/apache/lucene/pull/13124#discussion_r1499311351
##
lucene/core/src/java/org/apache/lucene/codecs/lucene99/Lucene99HnswVectorsFormat.java:
##
@@ -152,7 +153,25 @@ public Lucene99HnswVectorsFormat() {
* @param beamWidth the size of the queue maintained during graph
construction.
*/
public Lucene99HnswVectorsFormat(int maxConn, int beamWidth) {
-this(maxConn, beamWidth, DEFAULT_NUM_MERGE_WORKER, null);
Review Comment:
I am not sure we want such configuration at all in a default codec. I would
rather the concurrency is all controlled upstream.
My thought is that if we had all this part of the MergeState before, we
wouldn't have updated the codec definition at all.
In the future, as more things use parallelism maybe then we should consider
adding this setting back (or a completely new setting).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add new parallel merge task executor for parallel actions within a single merge action [lucene]
benwtrent commented on PR #13124: URL: https://github.com/apache/lucene/pull/13124#issuecomment-1959551147 > So I think it is still better to have two separate thread pools for inter-segment merge and inner segment merge, but I wonder whether we can have a ThreadPoolManager which configures both inter and inner pool. And CMS and HNSW merge (and any future merges) will source from this manager? Maybe? But this doesn't seem to simplify anything for users. They will still need two things to configure (number of merges that can happen at a time, number of threads available to all those merges to take action). There is always the issue of best using resources and the potential of over-allocating the CPU cores. I don't think any finagling we do will ultimately change that. Selfishly, I really don't want to mess with the CMS code at all. Even if we switch it to use an executor of some sort, the complexities of I/O throttling & executable queuing would still all exist. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Re-use information from graph traversal during exact search [lucene]
kaivalnp commented on PR #12820: URL: https://github.com/apache/lucene/pull/12820#issuecomment-1959568841 Thanks for checking @benwtrent! We primarily improve cases of using a high topK + a selective filter (good rate of fallback, large number of duplicate computations). I notice \~5% gains in those cases from your numbers, which may not be high enough for the extra memory consumption I'll wait for a couple of days in case someone feels this is still worth pursuing, or else I'll close this PR.. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add new parallel merge task executor for parallel actions within a single merge action [lucene]
jpountz commented on PR #13124: URL: https://github.com/apache/lucene/pull/13124#issuecomment-1959736838 > So, we would have to update the MergeScheduler to have some methods to return the executor for us to use and pass to MergeState (which is only created via the SegmentMerger object). This means that the scheduler for individual merges and the parallelism available to those individual merges are independent. I agree with passing some executor from the scheduler to the `MergeState`, but I'm not sure I agree that this implies that inter-merge and intra-merge parallelism would be independent. For instance the merge scheduler could return a custom `Executor` that dynamically decides to run a new task in the current thread or to fork to a separate thread depending on how many threads are currently busy across all merges vs. the current value of `ConcurrentMergeScheduler.maxThreadCount`? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add new parallel merge task executor for parallel actions within a single merge action [lucene]
benwtrent commented on PR #13124: URL: https://github.com/apache/lucene/pull/13124#issuecomment-1959856815 > For instance the merge scheduler could return a custom Executor that dynamically decides to run a new task in the current thread or to fork to a separate thread depending on how many threads are currently busy across all merges vs. the current value of ConcurrentMergeScheduler.maxThreadCount? This makes me think that instead of it being a separate executor it should return a dynamic value for `numParallelMergeWorkers` or if `numParallelMergeWorkers==1` return `null` so that there is no parallelism. This would require some sort of "planning" on the merge scheduler (knowing how many are queued and how many `numParallelMergeWorkers` it provided to each executing merge action). I guess we could rely on an executor's `getActiveCount()` but that seems trappy. This all implies that the configuration will actually `maxParallelMergeWorkers` and the MergeScheduler is free to provide any number of workers up to that limit. The tricky part to me is determining 'how busy' the current merges are. The MergeScheduler could pass `numParallelMergeWorkers` to the `SegmentMerger`, but it goes completely unused. Maybe this is OK and we just assume it will be used. Another confusion is determining the total number of threads allowed for merging (inter/intra). We could default this to `maxParallelMergeWorkers * maxThreadCount`. In this instance `maxParallelMergeWorkers == 1` would behave as the current working. `maxParallelMergeWorkers == 2` would mean that we potentially use twice as many resources and the user should adjust `maxThreadCount` accordingly. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] FieldInfosFormat translation should be independent of VectorSimilartyFunction enum [lucene]
ChrisHegarty commented on PR #13119: URL: https://github.com/apache/lucene/pull/13119#issuecomment-1959890082 Thanks for the reviews. All comments have been addressed. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] FieldInfosFormat translation should be independent of VectorSimilartyFunction enum [lucene]
ChrisHegarty merged PR #13119: URL: https://github.com/apache/lucene/pull/13119 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary [lucene]
azagniotov commented on PR #12517: URL: https://github.com/apache/lucene/pull/12517#issuecomment-1960013241 @uschindler yes: I have rebased from the latest `main` branch and ran the `./gradlew clean regenerate`. The following is the (partial) output: ``` ... ... > Task :lucene:analysis:nori:compileMecabKo Download https://bitbucket.org/eunjeon/mecab-ko-dic/downloads/mecab-ko-dic-2.1.1-20180720.tar.gz > Task :lucene:analysis:kuromoji:compileMecab Download https://jaist.dl.sourceforge.net/project/mecab/mecab-ipadic/2.7.0-20070801/mecab-ipadic-2.7.0-20070801.tar.gz Automaton regenerated from dictionary: mecab-ipadic-2.7.0-20070801 > Task :lucene:analysis:nori:compileMecabKo Automaton regenerated from dictionary: mecab-ko-dic-2.1.1-20180720 BUILD SUCCESSFUL in 39s 127 actionable tasks: 121 executed, 6 up-to-date ``` I also confirmed that the dictionary files `*.dat` were regenerated under the `lucene/analysis/kuromoji/src/resources/org/apache/lucene/analysis/ja` based on the modified date of the files. @mocobeta What do you think with regards to next steps with this PR? Is there anything I can add? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary [lucene]
azagniotov commented on PR #12517: URL: https://github.com/apache/lucene/pull/12517#issuecomment-1960013536 @uschindler yes: I have rebased from the latest `main` branch and ran the `./gradlew clean regenerate`. The following is the (partial) output: ``` ... ... > Task :lucene:analysis:nori:compileMecabKo Download https://bitbucket.org/eunjeon/mecab-ko-dic/downloads/mecab-ko-dic-2.1.1-20180720.tar.gz > Task :lucene:analysis:kuromoji:compileMecab Download https://jaist.dl.sourceforge.net/project/mecab/mecab-ipadic/2.7.0-20070801/mecab-ipadic-2.7.0-20070801.tar.gz Automaton regenerated from dictionary: mecab-ipadic-2.7.0-20070801 > Task :lucene:analysis:nori:compileMecabKo Automaton regenerated from dictionary: mecab-ko-dic-2.1.1-20180720 BUILD SUCCESSFUL in 39s 127 actionable tasks: 121 executed, 6 up-to-date ``` I also confirmed that the dictionary files `*.dat` were regenerated under the `lucene/analysis/kuromoji/src/resources/org/apache/lucene/analysis/ja` based on the modified date of the files. @mocobeta What do you think with regards to next steps with this PR? Is there anything I can add? -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Bump release to Java 21 [lucene]
ChrisHegarty commented on PR #12753: URL: https://github.com/apache/lucene/pull/12753#issuecomment-1960191939 This is ready to merge, right? @rmuir @uschindler @mikemccand -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
[PR] Adding benwtrent (me) to committers & PMC [lucene-site]
benwtrent opened a new pull request, #76: URL: https://github.com/apache/lucene-site/pull/76 (no comment) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Adding benwtrent (me) to committers & PMC [lucene-site]
benwtrent merged PR #76: URL: https://github.com/apache/lucene-site/pull/76 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Add new parallel merge task executor for parallel actions within a single merge action [lucene]
benwtrent commented on code in PR #13124:
URL: https://github.com/apache/lucene/pull/13124#discussion_r1499916055
##
lucene/core/src/java/org/apache/lucene/codecs/lucene99/Lucene99HnswVectorsFormat.java:
##
@@ -152,7 +153,25 @@ public Lucene99HnswVectorsFormat() {
* @param beamWidth the size of the queue maintained during graph
construction.
*/
public Lucene99HnswVectorsFormat(int maxConn, int beamWidth) {
-this(maxConn, beamWidth, DEFAULT_NUM_MERGE_WORKER, null);
Review Comment:
@zhaih I see what you are saying about the weighing of different codecs.
Where certain codecs could merged in parallel using a different number of
threads. My concern is how this would ever be effectively communicate to the
merge scheduler.
While it isn't a 1-1 relationship, adding more threads here in HNSW will
increase I/O. I assume that for other codecs that could use parallelism,
additional I/O will also be a concern.
The scheduler needs to know how to throttle I/O if this gets too large so
that merges and indexing can be smoothed out correct?
This indicates to me the scheduler should be in charge of handing out
threads to do work.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Bump release to Java 21 [lucene]
rmuir commented on PR #12753: URL: https://github.com/apache/lucene/pull/12753#issuecomment-1960300191 @ChrisHegarty @uschindler @mikemccand i think we still need to address these python scripts, sorry I haven't gotten to it! been busy unfortunately: > still need to update releaseWizard.py and smokeTestRelease.py, but i think that's really all thats left. just didnt feel like wrestling any python right now. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Bump release to Java 21 [lucene]
rmuir commented on PR #12753: URL: https://github.com/apache/lucene/pull/12753#issuecomment-1960301699 I mean, they could be a followup ticket. But it is nice to keep the `main` branch releasable. Until we fix those python scripts, we can't release because they want to use java 17 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary [lucene]
mocobeta commented on PR #12517: URL: https://github.com/apache/lucene/pull/12517#issuecomment-1960500994 @azagniotov Sorry, I've not been available for a while. Let me take a look; I will try to find time next week... -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] LUCENE-4056: Japanese Tokenizer (Kuromoji) cannot build UniDic dictionary [lucene]
azagniotov commented on PR #12517: URL: https://github.com/apache/lucene/pull/12517#issuecomment-1960506371 Thank you, @mocobeta 🙇🏼 -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Make Lucene90 postings format to write FST off heap [lucene]
github-actions[bot] commented on PR #12985: URL: https://github.com/apache/lucene/pull/12985#issuecomment-1960551613 This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you for your contribution! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Make FSTPostingFormat to build FST off-heap [lucene]
github-actions[bot] commented on PR #12980: URL: https://github.com/apache/lucene/pull/12980#issuecomment-1960551634 This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you for your contribution! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
Re: [PR] Throw CorruptSegmentInfoException on encountering missing segment info (_N.si) file in CheckIndex [lucene]
github-actions[bot] commented on PR #12872: URL: https://github.com/apache/lucene/pull/12872#issuecomment-1960551768 This PR has not had activity in the past 2 weeks, labeling it as stale. If the PR is waiting for review, notify the d...@lucene.apache.org list. Thank you for your contribution! -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org
