I agree that we can remove the blocker status from LUCENE-9583 and take advantage of the fact that these new APIs are experimental to improve things later.
For the renaming issue, maybe we could just make vectors plural for now for consistency and revisit other options later. On Wed, Apr 14, 2021 at 8:21 PM Michael Sokolov <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]>: > >>> >> > >>> >> +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 <[email protected]> > 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: [email protected] > >>> >>> For additional commands, e-mail: [email protected] > >>> >>> > >>> >> > >>> >> > >>> >> -- > >>> >> Adrien > >>> >> > >>> >> > >>> > > >>> > > >>> > -- > >>> > Adrien > >>> > >>> --------------------------------------------------------------------- > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > > > > > > -- > > Adrien > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > -- Adrien
