AB, I’ve deleted the duplicate JIRA’s (first time I’ve ever done that) and I’m looking at SOLR-18407 with Matthew Biscocho. We have a candidate PR for it.
As far as SOLR-16560, it was opened in 2022 against 8.8, and then was updated in October 2025 to 10.0…. Which makes me feel like it’s not Critical level…. > On Sep 10, 2026, at 8:17 AM, Andrzej Białecki <[email protected]> wrote: > > Hi, > > As of today, there are still many open Bug tickets affecting 10.0, which > presumably should be fixed in 10.1 - or at least they should be evaluated and > either downgraded or deliberately scheduled for a later release: > * 23 Major > * 6 Critical > * 4 Blocker > > Blockers: > > * SOLR-18298: ZkController.onReconnect Is Triggered Excessively (PR) > * SOLR-18301: Overseer Election May Not Converge After ZK Disconnect (PR) > * SOLR-18324: V2 (JAX-RS) requests can throw a cascading NPE / RTimer > assertion failure when a `SolrQueryRequest` isn't attached to the request > context (PR) > * SOLR-18278: SOLR JETTY dependency decoupling didn't work properly > > All are currently Unassigned in Jira but three of them have PRs. SOLR-18278 > needs to be verified because the description is very sparse. > > Critical: > > * SOLR-18407: Solr 10 emits duplicate JVM metrics from both > runtime-telemetry-java8 and runtime-telemetry-java17 scopes on Java 17 > * SOLR-18273: Solr 10.0.0 treats short ZooKeeper leader failover as > session-expiration recovery and removes/re-registers live_nodes > * SOLR-18276: Solr 10.0.0 treats short ZooKeeper leader failover as > session-expiration recovery and removes/re-registers live_nodes > * SOLR-18275: Solr 10.0.0 treats short ZooKeeper leader failover as > session-expiration recovery and removes/re-registers live_nodes > * SOLR-18274: Solr 10.0.0 treats short ZooKeeper leader failover as > session-expiration recovery and removes/re-registers live_nodes > * SOLR-16560: Pull replication appears to consume excessive CPU as it does > not use Segment Reader pooling > > SOLR-18276, SOLR-18275 and SOLR-18274 are duplicates of SOLR-18273 and can be > closed. > > SOLR-18407, 18273, 16560 are all Unassigned, with no PRs. > > > Any input on this list would be appreciated. Please also take a look at the > Major tickets, perhaps some of them should be re-evaluated for 10.1, either > down- or up-graded. > > Andrzej > > > > > On 8 Sep 2026, at 17:00, Andrzej Białecki <[email protected]> wrote: > > > > Fine with me, there are still several tickets in-flight that IMHO should be > > included in 10.1, so it will take another week or two anyway. > > > > Andrzej > > > >> On 8 Sep 2026, at 12:34, Jan Høydahl <[email protected]> wrote: > >> > >> The no overlap releases has been a self imposed limitation to avoid > >> confusion, and I guess it is cleaner to have 9.11 changelog in the 10.1 > >> release. During RCs there may also surface need for bugfixes that will > >> trickle from main, and that could then potentially require re-spin of both > >> releases. > >> > >> So if we are to keep with tradition we do 9.x first and then 10.x > >> immediately after. But technically we could have both in-flight... > >> > >> Jan > >> > >>> 7. sep. 2026 kl. 16:30 skrev David Smiley <[email protected]>: > >>> > >>> I'm not sure what release overlap concerns exist but I thought there was a > >>> limitation on concurrent releases. Maybe Jan knows. > >>> > >>> RE 10.1: There's https://issues.apache.org/jira/browse/SOLR-18130 > >>> <https://issues.apache.org/jira/browse/SOLR-18130> on 10.x > >>> (not 10.0), which opened up a security concern. It's not released, so no > >>> reason for me to be too secretative. I've had the concern on my mental > >>> backlog for months with code done for it for months likewise but > >>> frustratingly it's somewhat blocked by other WIP for a vulnerability that > >>> I > >>> don't want to interfere with (i.e. don't want to make backporting harder). > >>> > >>> On Thu, Sep 3, 2026 at 5:03 AM Andrzej Białecki <[email protected]> wrote: > >>> > >>>> Hi all, > >>>> > >>>> A lot of good work already went into branch_10x - dependency updates and > >>>> important bug fixes. There are also some outstanding bugs that I know > >>>> about > >>>> (SOLR-18414, SOLR-18408 and related CrossDC bugs) that either cripple or > >>>> completely break certain use cases in 10.0.0. > >>>> > >>>> Solr 10.0.0 has been released exactly 6 months ago. I think it’s time for > >>>> 10.1. If the community thinks so too, I volunteer to be the release > >>>> manager. Also, please let me know of any issues that may hold up this > >>>> release. > >>>> > >>>> Andrzej > >>>> --------------------------------------------------------------------- > >>>> To unsubscribe, e-mail: [email protected] > >>>> For additional commands, e-mail: [email protected] > >>>> > >>>> > >> > >> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: [email protected] > >> For additional commands, e-mail: [email protected] > >> > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and may have been automatically archived by Mimecast, a leader in email security and cyber resilience. Mimecast integrates email defenses with brand protection, security awareness training, web security, compliance and other essential capabilities. Mimecast helps protect large and small organizations from malicious activity, human error and technology failure; and to lead the movement toward building a more resilient world. To find out more, visit our website.
