Thanks Adrien; I plan to tackle LUCENE-9905.
I don't have ideas about how to move forward on LUCENE-9583; I spent
significant amount of time trying various permutations on that API,
and what we have was the best compromise I could find at the time, so
I'm not sure I agree it's a Blocker, yet I'm open to improvements.
Maybe Julie will propose something?
There is also a vector-related renaming issue Tomoko had opened, which
I thought was marked Blocker, but I guess no longer is. Previously I
had hoped to get some strong consensus, but that proved challenging.
Given that, I'm OK leaving things as-is, marking these apis
@experimental and potentially revisiting naming issues later, eg once
we have a second vector ANN implementation.
On Wed, Apr 14, 2021 at 11:07 AM Adrien Grand <jpountz@gmail.com> wrote:
>
> Hi Mike,
>
> Here's what I know about the remaining blockers:
>
> LUCENE-9908 - Move VectorValues#search to VectorReader and LeafReader
> This was discussed on the mailing list and it looks like there was agreement on making that change. If someone has cycles and can take it, please go ahead, otherwise I'll try to allocate some time to it. I'm expecting this change to be rather straightforward.
>
> LUCENE-9905 - Revise approach to specifying NN algorithm
> This is a change to how we've been thinking about configuring the ANN algorithm. I don't know if someone plans to work on it.
>
> LUCENE-9583 - How should we expose VectorValues.RandomAccess
> We'd like to get rid of this sub interface, but I'm not the best person to comment on how much work this needs. Maybe Mike S or Julie can give more info.
>
> LUCENE-9334 - Require consistency between data-structures on a per-field basis
> Mayya has been working on this one and it's very close.
>
> LUCENE-9047 - Directory APIs should be little endian
> Ignacio and Julie have been working on this one and it is close as well.
>
>
> On Tue, Apr 13, 2021 at 10:59 PM Mike Drob <mdrob@mdrob.com> wrote:
>>
>> Michael, did you get a chance to mark the issues you were thinking of as blockers?
>>
>> Adrien, I see that the remaining open blockers look mostly like your open issues. Two of them have recent activity, but LUCENE-9047 would need to be brought back to the lucene repo. Is this an accurate view of the state of things?
>>
>> Now that I'm done with 8.8.2, I would love to see how we can continue to make headway on 9.0!
>>
>>
>>
>> On Mon, Mar 29, 2021 at 3:25 PM Michael Sokolov <msokolov@gmail.com> wrote:
>>>
>>> There has been some discussion around a few code visibility and naming
>>> issues related to "VectorFormat" as it is called today. I'd like to
>>> get that sorted out before 9.0 - I'll hunt up the ticket(s) and mark
>>> as blockers
>>>
>>> On Sun, Mar 28, 2021 at 11:02 AM Adrien Grand <jpountz@gmail.com> wrote:
>>> >
>>> > Hello Jan,
>>> >
>>> > The list of blockers should be mostly up-to-date: https://issues.apache.org/jira/browse/LUCENE-9661?jql=project%3D%22Lucene%20-%20Core%22%20and%20priority%3DBlocker%20and%20fixVersion%3D%22main%20(9.0)%22.
>>> >
>>> > On Sat, Mar 27, 2021 at 7:21 PM Jan Høydahl <jan.asf@cominvent.com> wrote:
>>> >>
>>> >> Hi,
>>> >>
>>> >> Where are we at with the Lucene 9.0 release planning?
>>> >>
>>> >> The git split is largely done. Not sure about the build.
>>> >> Let's update the umbrella issue https://issues.apache.org/jira/browse/LUCENE-9375 for known remaining cleanup tasks.
>>> >> The one on that list is releaseWizard, but as Adrien says there are also other scripts that need updating.
>>> >>
>>> >> Jan
>>> >>
>>> >> 13. jan. 2021 kl. 15:10 skrev Adrien Grand <jpountz@gmail.com>:
>>> >>
>>> >> +1 to start planning 9.0.
>>> >>
>>> >> Since you mentioned the Gradle build, I believe that we still need to migrate some of the release tooling from Ant to Gradle, e.g. dev-tools/scripts/addBackcompatIndexes.py. These scripts are not easy to test without actually doing a release so the 9.0 RM might have some debugging to do.
>>> >>
>>> >>
>>> >> On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov <msokolov@gmail.com> wrote:
>>> >>>
>>> >>> Hi everyone, as we head into a new year full of optimism, is it time
>>> >>> to start discussing the next major release? We released 8.0 on Jun 18,
>>> >>> 2019, over 18 months ago. Since then we've switched to a gradle-based
>>> >>> build. We have added vector-valued fields and an HNSW neighbor search
>>> >>> algorithm for them. At the same time Solr has been getting a major
>>> >>> overhaul which should justify a release, I think? IIRC there was talk
>>> >>> of making 9.0 be the first release of Solr as its own TLP. Is it time
>>> >>> to start planning for that now?
>>> >>>
>>> >>> -Mike
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> Adrien
>>> >>
>>> >>
>>> >
>>> >
>>> > --
>>> > Adrien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>
>
> --
> Adrien
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org