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]
