Hi,
I've noticed a really odd thing in main branch
https://issues.apache.org/jira/browse/SOLR-18442
haven't checked it on 10_x

On Fri, Sep 11, 2026 at 8:46 PM Eric Pugh <[email protected]>
wrote:

> 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.
>


-- 
Sincerely yours
Mikhail Khludnev

Reply via email to