Re: [PR] Add docs detailing our ASF Jenkins usage [solr]
gerlowskija commented on PR #2767: URL: https://github.com/apache/solr/pull/2767#issuecomment-2436146523 > I'm almost surprised this went here instead of Confluence as it's easier to edit/collaborate on a wiki instead of in code and do PR process. I think that was probably true once, but it's at least arguably different now that Confluence account creation is semi-locked down as a defense against spam. Committers all tend to have Confluence access already, but for non-committers I think there's a good case that GH collaboration has less friction. I've helped a handful of folks get Confluence access this year (for updating SIPs, organizing "Community Meetups", etc.), and it's been a minor pain 🙁 But Eric's already highlighted my main reason for going the "dev-docs" route - for better or worse, Confluence doesn't seem like it gets much attention any more. Personally I'm OK with this - our user-facing documentation lives "in-repo" just fine, benefits from PR review, version control, etc. Why would developer-facing docs be any different? (This is probably worth a discussion on dev@, if anyone feels like injecting life back into use of cwiki as a documentation store.) -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Add docs detailing our ASF Jenkins usage [solr]
gerlowskija merged PR #2767: URL: https://github.com/apache/solr/pull/2767 -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-17161) Separate out a solrj-jetty artifact (10.0)
[
https://issues.apache.org/jira/browse/SOLR-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892565#comment-17892565
]
Jason Gerlowski edited comment on SOLR-17161 at 10/24/24 5:04 PM:
--
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and _only_ HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have: is there
any difference in the perf characteristics of the two underlying HttpClients?
what sort of hooks does each offer into the request/response or client
lifecycle? do the clients differ in how much they let users customize threading
or connection-pooling behavior? is there a popularity gap, or are folks already
pretty familiar with one HttpClient in particular? any logging or tracing
differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
was (Author: gerlowskija):
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and only HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have: is there
any difference in the perf characteristics of the two underlying HttpClients?
what sort of hooks does each offer into the request/response or client
lifecycle? do the clients differ in how much they let users customize threading
or connection-pooling behavior? is there a popularity gap, or are folks already
pretty familiar with one HttpClient in particular? any logging or tracing
differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
> Separate out a solrj-jetty artifact (10.0)
> --
>
> Key: SOLR-17161
> URL: https://issues.apache.org/jira/browse/SOLR-17161
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
>Reporter: Jan Høydahl
>Priority: Blocker
> Fix For: main (10.0)
>
>
> Given we have a native JDK based client in SOLR-599, we can separate out all
> {{Http2SolrClient}} and freiends with their jetty-client dependencies into a
> separate artifact {{{}solrj-jetty{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-16116: Use apache curator to manage the Solr Zookeeper interactions [solr]
dsmiley commented on code in PR #760:
URL: https://github.com/apache/solr/pull/760#discussion_r1815068705
##
gradle/testing/randomization/policies/solr-tests.policy:
##
@@ -50,6 +50,7 @@ grant {
permission java.net.SocketPermission "127.0.0.1:4", "connect,resolve";
permission java.net.SocketPermission "127.0.0.1:6", "connect,resolve";
permission java.net.SocketPermission "127.0.0.1:8", "connect,resolve";
+ permission java.net.SocketPermission "--", "connect,resolve";
Review Comment:
What's this? A comment could be useful.
##
solr/CHANGES.txt:
##
@@ -23,6 +23,8 @@ Improvements
* SOLR-17077: When a shard rejoins leader election, leave previous election
only once to save unneeded calls to Zookeeper. (Pierre Salagnac)
+* SOLR-16116: Apache Curator is now used to manage all Solr Zookeeper
interactions. (Houston Putman, Kevin Risden, Mike Drob, David Smiley)
Review Comment:
I think my role was minor.
BTW this PR adds a dependency to Curator from solrj-zookeeper. We should
highlight solrj dependencies with more publicity than Solr server.
--
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...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Add docs detailing our ASF Jenkins usage [solr]
gerlowskija commented on PR #2767: URL: https://github.com/apache/solr/pull/2767#issuecomment-2436148109 Thanks all for the review - merged! -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-16116: Use apache curator to manage the Solr Zookeeper interactions [solr]
dsmiley commented on code in PR #760:
URL: https://github.com/apache/solr/pull/760#discussion_r1815061933
##
solr/solrj-zookeeper/build.gradle:
##
@@ -32,6 +32,13 @@ dependencies {
implementation project(':solr:solrj')
+api('org.apache.curator:curator-client', {
Review Comment:
Let me put it like this -- what if you set it to "implementation". What bad
things will happen?
--
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...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Comment Edited] (SOLR-17161) Separate out a solrj-jetty artifact (10.0)
[
https://issues.apache.org/jira/browse/SOLR-17161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892565#comment-17892565
]
Jason Gerlowski edited comment on SOLR-17161 at 10/24/24 5:05 PM:
--
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and _only_ HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have:
* is there any difference in the perf characteristics of the two underlying
HttpClients?
* what sort of hooks does each offer into the request/response or client
lifecycle?
* do the clients differ in how much they let users customize threading or
connection-pooling behavior?
* is there a popularity gap, or are folks already pretty familiar with one
HttpClient in particular?
* any logging or tracing differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
was (Author: gerlowskija):
I guess I have a potential concern about moving the Jetty based clients into
their own artifact. Sorry to bring it to the table so late. (To be clear -
it's a "concern" and "request for info", and not a veto or anything like that.)
In short: it goes without saying how important defaults are in software, and
making the JDK-based client the only client available in 'solrj-core' will make
it the "effective default" for a lot of folks. Most users will start by just
grabbing 'solrj-core', and then their IDE's autocomplete will suggest
HttpJdkSolrClient (and _only_ HttpJdkSolrClient). That's a big deal! And I
worry about making that sort of change without a discussion about whether it's
our best option, holistically.
The JDK-based client is a clear winner on some concerns, e.g. dependency
footprint. But that's not the only concern users are likely to have: is there
any difference in the perf characteristics of the two underlying HttpClients?
what sort of hooks does each offer into the request/response or client
lifecycle? do the clients differ in how much they let users customize threading
or connection-pooling behavior? is there a popularity gap, or are folks already
pretty familiar with one HttpClient in particular? any logging or tracing
differences?
Has this sort of holistic discussion happened somewhere that I just missed? If
not, maybe we could have that here?
> Separate out a solrj-jetty artifact (10.0)
> --
>
> Key: SOLR-17161
> URL: https://issues.apache.org/jira/browse/SOLR-17161
> Project: Solr
> Issue Type: Sub-task
> Components: clients - java
>Reporter: Jan Høydahl
>Priority: Blocker
> Fix For: main (10.0)
>
>
> Given we have a native JDK based client in SOLR-599, we can separate out all
> {{Http2SolrClient}} and freiends with their jetty-client dependencies into a
> separate artifact {{{}solrj-jetty{}}}.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] [branch_9x] Backport Switched from HTTP1 to HTTP2 in SolrClientCloudManager [solr]
iamsanjay merged PR #2791: URL: https://github.com/apache/solr/pull/2791 -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Cleanup JDK version related logic in scripts [solr]
malliaridis commented on code in PR #2792:
URL: https://github.com/apache/solr/pull/2792#discussion_r1815543421
##
solr/bin/solr:
##
@@ -1054,31 +1054,13 @@ fi
# Establish default GC logging opts if no env var set (otherwise init to
sensible default)
if [ -z "${GC_LOG_OPTS}" ]; then
- if [[ "$JAVA_VER_NUM" -lt "9" ]] ; then
-GC_LOG_OPTS=('-verbose:gc' '-XX:+PrintHeapAtGC' '-XX:+PrintGCDetails' \
- '-XX:+PrintGCDateStamps' '-XX:+PrintGCTimeStamps'
'-XX:+PrintTenuringDistribution' \
- '-XX:+PrintGCApplicationStoppedTime')
- else
-GC_LOG_OPTS=('-Xlog:gc*')
- fi
-else
- # TODO: Should probably not overload GC_LOG_OPTS as both string and array,
but leaving it be for now
- # shellcheck disable=SC2128
- GC_LOG_OPTS=($GC_LOG_OPTS)
+ GC_LOG_OPTS=('-Xlog:gc*')
fi
# if verbose gc logging enabled, setup the location of the log file and
rotation
if [ "${#GC_LOG_OPTS[@]}" -gt 0 ]; then
- if [[ "$JAVA_VER_NUM" -lt "9" ]] || [ "$JAVA_VENDOR" == "OpenJ9" ]; then
-gc_log_flag="-Xloggc"
-if [ "$JAVA_VENDOR" == "OpenJ9" ]; then
- gc_log_flag="-Xverbosegclog"
-fi
-if [ -z ${JAVA8_GC_LOG_FILE_OPTS+x} ]; then
Review Comment:
From my understanding that is right. The reason I removed this check is
because we do not support Java 8, and as the environment variable indicates,
this is only relevant for users running SOlr with Java 8 and setting this value.
I couldn't find any references in the documentation, so since it is not
documented, I assume that this value is always not set for any Solr version 10+
that only supports Java 21+, and the condition is therefore always `true`.
If a condition is here relevant, we should definitely use a suitable name
other than `JAVA8_*` and reintroduce the check.
--
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...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[jira] [Commented] (SOLR-16450) Proper handling on watcher registration failure in `ZkStateReader#waitForState
[ https://issues.apache.org/jira/browse/SOLR-16450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17892591#comment-17892591 ] Gus Heck commented on SOLR-16450: - This is labeled a blocker, and there's no fix version, and it seems to have commits after the re-open. Is this complete? what version is it fixed in? > Proper handling on watcher registration failure in `ZkStateReader#waitForState > -- > > Key: SOLR-16450 > URL: https://issues.apache.org/jira/browse/SOLR-16450 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Reporter: Hitesh Khamesra >Assignee: Noble Paul >Priority: Blocker > Time Spent: 0.5h > Remaining Estimate: 0h > > following > [https://github.com/apache/solr/blob/19f109842fb34069346a9efb21cf01b6706830a8/solr/solrj-zookeeper/src/java/org/apache/solr/common/cloud/ZkStateReader.java#L1948] > > should handle watcher registration failure case properly. -- This message was sent by Atlassian Jira (v8.20.10#820010) - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17477: Support custom aggregates in plugin code [solr]
mkhludnev commented on PR #2742: URL: https://github.com/apache/solr/pull/2742#issuecomment-2435694762 oh gosh.. I figure it out how to update PR as a maintainer. The problem was I did it by https auth from Idea, but it seems it requested token only for my account and can't push into someone else's even if `Maintainers are allowed to edit this pull request.` is turn on. Old good ssh did a thing. -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] Replace CloudLegacySolrClient with CloudHttp2SolrClient in SolrClientCloudManager [solr]
iamsanjay merged PR #2751: URL: https://github.com/apache/solr/pull/2751 -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17494: Remove language specific writer types [solr]
gerlowskija commented on PR #2758: URL: https://github.com/apache/solr/pull/2758#issuecomment-2435146190 Woohoo, thanks @epugh ! -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17477: Support custom aggregates in plugin code [solr]
timatbw commented on code in PR #2742:
URL: https://github.com/apache/solr/pull/2742#discussion_r1815497148
##
solr/core/src/java/org/apache/solr/search/facet/FacetParser.java:
##
@@ -138,21 +139,30 @@ public Object parseFacetOrStat(String key, Object o)
throws SyntaxError {
return parseFacetOrStat(key, type, args);
}
+ public interface ParseHandler {
+Object doParse(FacetParser parent, String key, Object args) throws
SyntaxError;
+ }
+
+ private static final Map REGISTERED_TYPES = new
ConcurrentHashMap<>();
+
+ static {
+ParseHandler fieldParser = (p, k, a) -> new FacetFieldParser(p,
k).parse(a);
+REGISTERED_TYPES.put("field", fieldParser);
+REGISTERED_TYPES.put("terms", fieldParser);
+REGISTERED_TYPES.put("query", (p, k, a) -> new FacetQueryParser(p,
k).parse(a));
+REGISTERED_TYPES.put("range", (p, k, a) -> new FacetRangeParser(p,
k).parse(a));
+REGISTERED_TYPES.put("heatmap", (p, k, a) -> new FacetHeatmap.Parser(p,
k).parse(a));
+REGISTERED_TYPES.put("func", (p, k, a) -> p.parseStat(k, a));
+ }
+
+ public static void registerParseHandler(String type, ParseHandler
parseHandler) {
Review Comment:
Yes all good points, I'm going to change this to remove the statics and make
it per-core which probably fits better with how it's hooked in too
--
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...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
Re: [PR] SOLR-17477: Support custom aggregates in plugin code [solr]
timatbw commented on code in PR #2742:
URL: https://github.com/apache/solr/pull/2742#discussion_r1815500548
##
solr/core/src/java/org/apache/solr/search/facet/FacetParser.java:
##
@@ -138,21 +139,30 @@ public Object parseFacetOrStat(String key, Object o)
throws SyntaxError {
return parseFacetOrStat(key, type, args);
}
+ public interface ParseHandler {
+Object doParse(FacetParser parent, String key, Object args) throws
SyntaxError;
Review Comment:
This is already how it is, the calling code allows the parser to return
either a FacetRequest or a AggValueSource hence that Object type was needed
here too. It's not ideal, and perhaps in practice most people will want to
produce a AggValueSource only. Creating new subclasses of FacetRequest outside
the package is harder, and I've not yet looked at how feasible it is to do that
from a plugin (it's not the focus of this issue). But it would be interesting
if eventually you can define custom types of faceting too.
--
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...@solr.apache.org
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
-
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
[PR] Cleanup JDK version related logic in scripts [solr]
malliaridis opened a new pull request, #2792: URL: https://github.com/apache/solr/pull/2792 # Description With the min JDK 21 requirement some code snippets in `bin/solr.cmd` and `bin/solr` can be cleaned up. # Solution Cleanup obsolete code in `bin/solr.cmd` and `bin/solr`. **To the reviewers**: Please review carefully the GC-related changes, as I am not sure what is supported and what not in the newer versions. I tried to remove only obsolete cases, but I am not sure how to test the configurations. # Tests No tests modified. Some of the tests currently fail when running `./gradlew check` (currently inspecting). # Checklist Please review the following and check all that apply: - [X] I have reviewed the guidelines for [How to Contribute](https://github.com/apache/solr/blob/main/CONTRIBUTING.md) and my code conforms to the standards described there to the best of my ability. - [ ] I have created a Jira issue and added the issue ID to my pull request title. - [X] I have given Solr maintainers [access](https://help.github.com/en/articles/allowing-changes-to-a-pull-request-branch-created-from-a-fork) to contribute to my PR branch. (optional but recommended, not available for branches on forks living under an organisation) - [X] I have developed this patch against the `main` branch. - [ ] I have run `./gradlew check`. - [ ] I have added tests for my changes. - [ ] I have added documentation for the [Reference Guide](https://github.com/apache/solr/tree/main/solr/solr-ref-guide) -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] [branch_9x] Backport Switched from HTTP1 to HTTP2 in SolrClientCloudManager [solr]
iamsanjay opened a new pull request, #2791: URL: https://github.com/apache/solr/pull/2791 [SOLR-16503](https://issues.apache.org/jira/browse/SOLR-16503) -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
[PR] Update org.apache.zookeeper:* to v3.9.3 [solr]
solrbot opened a new pull request, #2793: URL: https://github.com/apache/solr/pull/2793 This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [org.apache.zookeeper:zookeeper-jute](http://zookeeper.apache.org) ([source](https://gitbox.apache.org/repos/asf/zookeeper.git), [changelog](https://zookeeper.apache.org/releases.html)) | dependencies | patch | `3.9.2` -> `3.9.3` | | [org.apache.zookeeper:zookeeper](http://zookeeper.apache.org) ([source](https://gitbox.apache.org/repos/asf/zookeeper.git), [changelog](https://zookeeper.apache.org/releases.html)) | dependencies | patch | `3.9.2` -> `3.9.3` | --- ### Configuration 📅 **Schedule**: Branch creation - "* * * * *" (UTC), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about these updates again. --- - [ ] If you want to rebase/retry this PR, check this box --- This PR has been generated by [Renovate Bot](https://redirect.github.com/solrbot/renovate-github-action) -- 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...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org - To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
