On 2026/10/13 15:31:57 Anshum Gupta wrote:
> +1 to Hoss’s idea of moving this to the sandbox.
>
>
> Anshum Gupta
>
> On Tue, Oct 13, 2026 at 00:13 Jan Høydahl <[email protected]> wrote:
>
> > +1 to move to sandbox. Tiny feature should not hold us hostage
> >
> > Jan
> >
> > > 12. okt. 2026 kl. 23:12 skrev Chris Hostetter <[email protected]
> > >:
> > >
> > >
> > > The bugs found with solr/modules/cuvs in the Solr 10.1.0 RCs -- due to
> > the
> > > module depending on a thrid-party dependency that is tightly couple with
> > > the Lucene version, but released by a completely different organization
> > --
> > > is really just a new variation on the fundemental the concerns I raise
> > > when cuvs was first added to Solr...
> > >
> > > https://issues.apache.org/jira/browse/SOLR-17892
> > >
> > > I get that cuvs is a valuable feature to have, for some people, on some
> > > hardware, but I really don't think it makes sense for it to be part of
> > the
> > > official Solr release -- not when it's depenencies are so tightly
> > > intertwined (but loosly coupled) to the specific Lucene version at a
> > very
> > > low level.
> > >
> > > As Rahul indicates -- we are now facing the exact choice I warmed about
> > a
> > > year ago...
> > >
> > >>> In the future we (Solr) may get stuck between a rock and a hard place
> > >>> when attempting a Lucene upgrades ... we will be forced to choose:
> > >>>
> > >>> - Let the Lucene upgrade be blocked indefinitely until a
> > >>> third-party project ( cuvs-lucene ) gets around to a
> > >>> compatible release.
> > >>> - Stop supporting modules/cuvs in what may be a MINOR Solr
> > >>> release, potentially screwing our users who have built indexes
> > >>> using that module
> > >
> > >
> > > I really think we need to move cuvs to either the solr-sandbox, or some
> > > new purpose specific 'solr-cuvs' git repo, where it can be released on
> > > it's own timeframe, dependent on when/how/if the upstream third-party
> > > project (cuvs-lucene) has compatible releases for the Lucene version we
> > > are using.
> > >
> > >
> > > People who use Solr and do *not* use modules/cuvs should not have to
> > > suffer delays in getting iportant bug fixes in Solr code -- or getting a
> > > Solr release with a Lucene version that's already outdated -- just
> > because
> > > we don't want to release a Solr version with a "broken" modules/cuvs.
> > >
> > >
> > > -Hoss
> > > http://www.lucidworks.com/
> > >
> > >
> > >
> > >
> > > On Sun, 11 Oct 2026, Rahul Goswami wrote:
> > >
> > > : Date: Sun, 11 Oct 2026 17:08:02 -0400
> > > : From: Rahul Goswami <[email protected]>
> > > : Reply-To: [email protected]
> > > : To: [email protected]
> > > : Subject: Re: [VOTE] Release Solr 10.1.0 RC2
> > > :
> > > : Tried the RC. The cuvs module seems to be broken. Indexing fails on a
> > GPU
> > > : enabled machine due to API incompatibility between cuvs-lucene and
> > Lucene
> > > : 10.4.
> > > : Currently no available compatible cuvs-lucene version exists for Lucene
> > > : 10.4 and is expected to be available by December this year.
> > > :
> > > : If there is agreement, I could spend the effort on rolling Solr back to
> > > : Lucene 10.3.2 where I have validated cuvs to work (which was also the
> > > : Lucene version we were on prior to 10.4).
> > > :
> > > : Thoughts?
> > > :
> > > : 2026-10-10 20:57:58.804 WARN (qtp166454155-71) []
> > o.e.j.e.s.ServletChannel
> > > : /solr/vectors/update
> > > : *java.lang.NoSuchMethodError: 'int[]
> > > :
> > org.apache.lucene.util.hnsw.HnswGraph$NodesIterator.getSortedNodes(org.apache.lucene.util.hnsw.HnswGraph$NodesIterator)'*
> > > : at
> > > :
> > com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeGraph(Lucene99AcceleratedHNSWVectorsWriter.java:444)
> > > : at
> > > :
> > com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeFieldInternal(Lucene99AcceleratedHNSWVectorsWriter.java:230)
> > > : at
> > > :
> > com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.writeField(Lucene99AcceleratedHNSWVectorsWriter.java:502)
> > > : at
> > > :
> > com.nvidia.cuvs.lucene.Lucene99AcceleratedHNSWVectorsWriter.flush(Lucene99AcceleratedHNSWVectorsWriter.java:494)
> > > : at
> > > :
> > org.apache.lucene.codecs.perfield.PerFieldKnnVectorsFormat$FieldsWriter.flush(PerFieldKnnVectorsFormat.java:120)
> > > : at
> > > :
> > org.apache.lucene.index.VectorValuesConsumer.flush(VectorValuesConsumer.java:76)
> > > : at org.apache.lucene.index.IndexingChain.flush(IndexingChain.java:305)
> > > : at
> > > :
> > org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:456)
> > > : at
> > org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:502)
> > > : at
> > > :
> > org.apache.lucene.index.DocumentsWriter.maybeFlush(DocumentsWriter.java:456)
> > > : at
> > > :
> > org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:649)
> > > : at
> > > :
> > org.apache.lucene.index.IndexWriter.prepareCommitInternal(IndexWriter.java:3712)
> > > : at
> > org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:4160)
> > > : at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:4122)
> > > : at
> > > :
> > org.apache.solr.update.DirectUpdateHandler2.commit(DirectUpdateHandler2.java:872)
> > > : at
> > > :
> > org.apache.solr.update.processor.RunUpdateProcessorFactory$RunUpdateProcessor.processCommit(RunUpdateProcessorFactory.java:100)
> > > : at
> > > :
> > org.apache.solr.update.processor.UpdateRequestProcessor.processCommit(UpdateRequestProcessor.java:66)
> > > : at
> > > :
> > org.apache.solr.update.processor.DistributedUpdateProcessor.doLocalCommit(DistributedUpdateProcessor
> > > :
> > > : - Rahul
> > > :
> > > : On Sat, Oct 10, 2026 at 5:57 PM Jan Høydahl <[email protected]> wrote:
> > > :
> > > : > The changelog lists "Dependency Upgrades (61 changes)"
> > > : > I thought we were to hand edit and de-duplicate that list.
> > > : >
> > > : > PS: Jetty 12.1.14 hits branch_10x soon, hope it can make it if
> > there's a
> > > : > respin.
> > > : >
> > > : > Jan
> > > : >
> > > : > > 10. okt. 2026 kl. 15:48 skrev Andrzej Białecki <[email protected]>:
> > > : > >
> > > : > > Please vote for release candidate 2 for Solr 10.1.0
> > > : > >
> > > : > > The artifacts can be downloaded from:
> > > : > >
> > > : >
> > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1
> > > : > >
> > > : > > You can run the smoke tester directly with this command:
> > > : > >
> > > : > > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > > : > >
> > > : >
> > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1
> > > : > >
> > > : > > You can build a release-candidate of the official docker images
> > (full &
> > > : > slim) using the following command:
> > > : > >
> > > : > > SOLR_DOWNLOAD_SERVER=
> > > : >
> > https://dist.apache.org/repos/dist/dev/solr/solr-10.1.0-RC2-rev-dfda5e1d4821958e60d13aa5ce3a0d4992319ed1/solr
> > > : > && \
> > > : > > docker build
> > > : > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-full \
> > > : > > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > > : > > -t solr-rc:10.1.0-2 && \
> > > : > > docker build
> > > : > $SOLR_DOWNLOAD_SERVER/10.1.0/docker/Dockerfile.official-slim \
> > > : > > --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> > > : > > -t solr-rc:10.1.0-2-slim
> > > : > >
> > > : > > The vote will be open for 72 hours (not including the Sunday and
> > > : > Columbus Day), i.e. until 2026-10-15 15:00 UTC.
> > > : > >
> > > : > > [ ] +1 approve
> > > : > > [ ] +0 no opinion
> > > : > > [ ] -1 disapprove (and reason why)
> > > : > >
> > > : > > Here is my +1
> > > : > > ----
> > > : > >
> > > : > > Cheers,
> > > : > > 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]
> >
> >
>
What about highlighting to that community that we need a 10.4 release ASAP, and
seeing if that changes their timeline. Judinging from the github issue, they
are filling in a number of missing verion releases, which of couse makes it
more work then just cutting a 10.4 release. If they committed to releasing a
10.4 in the next week, would that change things for us?
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
