sure, thanks Jim! Tommaso
Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi <[email protected]> ha scritto: > > Go ahead Tommaso the branch is not created yet. > The plan is to create the branches (7.7 and 8.0) tomorrow or wednesday and > to announce the feature freeze the same day. > For blocker issues that are still open this leaves another week to work on a > patch and we can update the status at the end of the week in order to decide > if we can start the first build candidate > early next week. Would that work for you ? > > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <[email protected]> a > écrit : >> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time. >> >> Regards, >> Tommaso >> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand >> <[email protected]> ha scritto: >> > >> > Hi Noble, >> > >> > No it hasn't created yet. >> > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <[email protected]> wrote: >> > > >> > > Is the branch already cut for 8.0? which is it? >> > > >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <[email protected]> >> > > wrote: >> > > > >> > > > I finally have a patch up for >> > > > https://issues.apache.org/jira/browse/SOLR-12768 (already marked as >> > > > 8.0 blocker) that I feel pretty good about. This provides a key part >> > > > of the nested document support. >> > > > I will work on some documentation for it this week -- SOLR-13129 >> > > > >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <[email protected]> >> > > > wrote: >> > > >> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it >> > > >> gets fixed in 8.0.1 that's ok too, given this is an ooold bug. >> > > >> I think we should simply remove the buffering feature in the UI and >> > > >> replace it with an error message popup or something. >> > > >> I'll try to take a look next week. >> > > >> >> > > >> -- >> > > >> Jan Høydahl, search solution architect >> > > >> Cominvent AS - www.cominvent.com >> > > >> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe >> > > >> <[email protected]>: >> > > >> >> > > >> I think the UI is an important Solr feature. As long as there is a >> > > >> reasonable time horizon for the issue being resolved I'm +1 on making >> > > >> it a blocker. I'm not familiar enough with the UI code to help either >> > > >> unfortunately. >> > > >> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <[email protected]> wrote: >> > > >>> >> > > >>> It looks like someone tried to make it a blocker once before... And >> > > >>> it's actually a duplicate of an earlier issue >> > > >>> (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a >> > > >>> question of whether or not overall quality has a bearing on the >> > > >>> decision to release. As it turns out the screen shot I posted to the >> > > >>> issue is less than half of the shards that eventually got created >> > > >>> since there was an outstanding queue of requests still processing at >> > > >>> the time. I'm now having to delete 50 or so cores, which luckily are >> > > >>> small 100 Mb initial testing cores, not the 20GB cores we'll be >> > > >>> testing on in the near future. It more or less makes it impossible >> > > >>> to recommend the use of the admin UI for anything other than read >> > > >>> only observation of the cluster. Now imagine someone leaves a >> > > >>> browser window open and forgets about it rather than browsing away >> > > >>> or closing the window, not knowing that it's silently pumping out >> > > >>> requests after showing an error... would completely hose a node, and >> > > >>> until they tracked down the source of the requests, (hope he didn't >> > > >>> go home) it would be impossible to resolve... >> > > >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <[email protected]> >> > > >>> wrote: >> > > >>>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not >> > > >>>> call it a blocker and delay the release for it since this isn't a >> > > >>>> new >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but >> > > >>>> maybe this is something that could get fixed before we build a RC? >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <[email protected]> wrote: >> > > >>>> > >> > > >>>> > I'd like to suggest that >> > > >>>> > https://issues.apache.org/jira/browse/SOLR-10211 be promoted to >> > > >>>> > block 8.0. I just got burned by it a second time. >> > > >>>> > >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <[email protected]> >> > > >>>> > wrote: >> > > >>>> >> >> > > >>>> >> Cool, >> > > >>>> >> >> > > >>>> >> I am working on giving my best release time guess as possible on >> > > >>>> >> the FOSDEM conference! >> > > >>>> >> >> > > >>>> >> Uwe >> > > >>>> >> >> > > >>>> >> ----- >> > > >>>> >> Uwe Schindler >> > > >>>> >> Achterdiek 19, D-28357 Bremen >> > > >>>> >> http://www.thetaphi.de >> > > >>>> >> eMail: [email protected] >> > > >>>> >> >> > > >>>> >> > -----Original Message----- >> > > >>>> >> > From: Adrien Grand <[email protected]> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM >> > > >>>> >> > To: Lucene Dev <[email protected]> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0 >> > > >>>> >> > >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of >> > > >>>> >> > February 4th. >> > > >>>> >> > >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi >> > > >>>> >> > <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > > >> > > >>>> >> > > Hi, >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing >> > > >>>> >> > > 8.0. The branch is >> > > >>>> >> > already created so we can start the process anytime now. >> > > >>>> >> > Unless there are >> > > >>>> >> > objections I'd like to start the feature freeze next week in >> > > >>>> >> > order to build the >> > > >>>> >> > first candidate the week after. >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both >> > > >>>> >> > > with Alan so >> > > >>>> >> > the question now is whether we are ok to start the release >> > > >>>> >> > process or if there >> > > >>>> >> > are any blockers left ;). >> > > >>>> >> > > >> > > >>>> >> > > >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward >> > > >>>> >> > > <[email protected]> >> > > >>>> >> > a écrit : >> > > >>>> >> > >> >> > > >>>> >> > >> I’ve started to work through the various deprecations on >> > > >>>> >> > >> the new master >> > > >>>> >> > branch. There are a lot of them, and I’m going to need some >> > > >>>> >> > assistance for >> > > >>>> >> > several of them, as it’s not entirely clear what to do. >> > > >>>> >> > >> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene >> > > >>>> >> > >> and one for Solr, >> > > >>>> >> > with lists of the deprecations that need to be removed in each >> > > >>>> >> > one. I’ll create >> > > >>>> >> > a shared branch on gitbox to work against, and push the >> > > >>>> >> > changes I’ve already >> > > >>>> >> > done there. We can then create individual JIRA issues for any >> > > >>>> >> > changes that >> > > >>>> >> > are more involved than just deleting code. >> > > >>>> >> > >> >> > > >>>> >> > >> All assistance gratefully received, particularly for the >> > > >>>> >> > >> Solr deprecations >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with. >> > > >>>> >> > >> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward >> > > >>>> >> > >> <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same >> > > >>>> >> > >> time as 8.0, to >> > > >>>> >> > handle any last-minute deprecations etc. So let’s keep those >> > > >>>> >> > jobs enabled >> > > >>>> >> > for now. >> > > >>>> >> > >> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <[email protected]> >> > > >>>> >> > >> wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> Hi, >> > > >>>> >> > >> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I >> > > >>>> >> > >> have some time >> > > >>>> >> > later today. >> > > >>>> >> > >> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop >> > > >>>> >> > >> using it >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for >> > > >>>> >> > bugfixes), or >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter >> > > >>>> >> > case I would keep >> > > >>>> >> > the jenkins jobs enabled for a while. >> > > >>>> >> > >> >> > > >>>> >> > >> Uwe >> > > >>>> >> > >> >> > > >>>> >> > >> ----- >> > > >>>> >> > >> Uwe Schindler >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen >> > > >>>> >> > >> http://www.thetaphi.de >> > > >>>> >> > >> eMail: [email protected] >> > > >>>> >> > >> >> > > >>>> >> > >> From: Alan Woodward <[email protected]> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM >> > > >>>> >> > >> To: [email protected] >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0 >> > > >>>> >> > >> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a >> > > >>>> >> > >> branch for 8x >> > > >>>> >> > from master, and am in the process of updating the master >> > > >>>> >> > branch to version >> > > >>>> >> > 9. New commits that should be included in the 8.0 release >> > > >>>> >> > should also be >> > > >>>> >> > back-ported to branch_8x from master. >> > > >>>> >> > >> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there >> > > >>>> >> > >> are still some >> > > >>>> >> > things being worked on for 8.0; however, it should let us >> > > >>>> >> > clean up master by >> > > >>>> >> > removing as much deprecated code as possible, and give us an >> > > >>>> >> > idea of any >> > > >>>> >> > replacement work that needs to be done. >> > > >>>> >> > >> >> > > >>>> >> > >> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley >> > > >>>> >> > >> <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> January. >> > > >>>> >> > >> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G >> > > >>>> >> > >> <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is >> > > >>>> >> > >> an enhancement >> > > >>>> >> > on nested-documents we are waiting to get our hands on. >> > > >>>> >> > >> Any idea when Solr 8 would be out ? >> > > >>>> >> > >> >> > > >>>> >> > >> Thx >> > > >>>> >> > >> SG >> > > >>>> >> > >> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter: project in >> > > >>>> >> > >> (SOLR, LUCENE) AND >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master >> > > >>>> >> > (8.0)" >> > > >>>> >> > >> click here: >> > > >>>> >> > >> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2 >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20 >> > > >>>> >> > >> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues >> > > >>>> >> > >> not yet >> > > >>>> >> > assigned. >> > > >>>> >> > >> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand >> > > >>>> >> > >> <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> >> > > >>>> >> > >> +1 >> > > >>>> >> > >> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> > >> > > >>>> >> > >> > Hi all, >> > > >>>> >> > >> > >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should >> > > >>>> >> > >> > think about >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0. I’ll >> > > >>>> >> > volunteer to create the >> > > >>>> >> > branch this week - say Wednesday? Then we should have some >> > > >>>> >> > time to >> > > >>>> >> > clean up the master branch and uncover anything that still >> > > >>>> >> > needs to be done >> > > >>>> >> > on 8.0 before we start the release process next year. >> > > >>>> >> > >> > >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett >> > > >>>> >> > >> > <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> > >> > > >>>> >> > >> > I'm a bit delayed, but +1 on the 7.6 and 8.0 plan from me >> > > >>>> >> > >> > too. >> > > >>>> >> > >> > >> > > >>>> >> > >> > On Fri, Oct 19, 2018 at 7:18 AM Erick Erickson >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >> > > >>>> >> > >> >> +1, this gives us all a chance to prioritize getting the >> > > >>>> >> > >> >> blockers out >> > > >>>> >> > >> >> of the way in a careful manner. >> > > >>>> >> > >> >> On Fri, Oct 19, 2018 at 7:56 AM jim ferenczi >> > > >>>> >> > >> >> <[email protected]> >> > > >>>> >> > wrote: >> > > >>>> >> > >> >> > >> > > >>>> >> > >> >> > +1 too. With this new perspective we could create the >> > > >>>> >> > >> >> > branch just >> > > >>>> >> > after the 7.6 release and target the 8.0 release for January >> > > >>>> >> > 2019 which gives >> > > >>>> >> > almost 3 month to finish the blockers ? >> > > >>>> >> > >> >> > >> > > >>>> >> > >> >> > Le jeu. 18 oct. 2018 à 23:56, David Smiley >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>> >> > > >>>> >> > >> >> >>> If we're planning to postpone cutting an 8.0 branch >> > > >>>> >> > >> >> >>> until a few >> > > >>>> >> > weeks from now then I'd like to propose (and volunteer to RM) >> > > >>>> >> > a 7.6 release >> > > >>>> >> > targeted for late November or early December (following the >> > > >>>> >> > typical 2 month >> > > >>>> >> > release pattern). It feels like this might give a little >> > > >>>> >> > breathing room for >> > > >>>> >> > finishing up 8.0 blockers? And looking at the change log there >> > > >>>> >> > appear to be a >> > > >>>> >> > healthy list of features, bug fixes, and improvements to both >> > > >>>> >> > Solr and Lucene >> > > >>>> >> > that warrant a 7.6 release? Personally I wouldn't mind >> > > >>>> >> > releasing the >> > > >>>> >> > LatLonShape encoding changes in LUCENE-8521 and selective >> > > >>>> >> > indexing work >> > > >>>> >> > done in LUCENE-8496. Any objections or thoughts? >> > > >>>> >> > >> >> >>> >> > > >>>> >> > >> >> >>> - Nick >> > > >>>> >> > >> >> >>> >> > > >>>> >> > >> >> >>> >> > > >>>> >> > >> >> >>> On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>> >> > > >>>> >> > >> >> >>>> Thanks Cassandra and Jim, >> > > >>>> >> > >> >> >>>> >> > > >>>> >> > >> >> >>>> I created a blocker issue for Solr 8.0 SOLR-12883, >> > > >>>> >> > >> >> >>>> currently in >> > > >>>> >> > jira/http2 branch there are a draft-unmature implementation of >> > > >>>> >> > SPNEGO >> > > >>>> >> > authentication which enough to makes the test pass, this >> > > >>>> >> > implementation will >> > > >>>> >> > be removed when SOLR-12883 gets resolved . Therefore I don't >> > > >>>> >> > see any >> > > >>>> >> > problem on merging jira/http2 to master branch in the next >> > > >>>> >> > week. >> > > >>>> >> > >> >> >>>> >> > > >>>> >> > >> >> >>>> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>> >> > > >>>> >> > >> >> >>>>> > But if you're working with a different >> > > >>>> >> > >> >> >>>>> > assumption - that just the >> > > >>>> >> > existence of the branch does not stop Dat from still merging >> > > >>>> >> > his work and the >> > > >>>> >> > work being included in 8.0 - then I agree, waiting for him to >> > > >>>> >> > merge doesn't >> > > >>>> >> > need to stop the creation of the branch. >> > > >>>> >> > >> >> >>>>> >> > > >>>> >> > >> >> >>>>> Yes that's my reasoning. This issue is a blocker >> > > >>>> >> > >> >> >>>>> so we won't >> > > >>>> >> > release without it but we can work on the branch in the >> > > >>>> >> > meantime and let >> > > >>>> >> > other people work on new features that are not targeted to 8. >> > > >>>> >> > >> >> >>>>> >> > > >>>> >> > >> >> >>>>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>> >> > > >>>> >> > >> >> >>>>>> OK - I was making an assumption that the timeline >> > > >>>> >> > >> >> >>>>>> for the first >> > > >>>> >> > 8.0 RC would be ASAP after the branch is created. >> > > >>>> >> > >> >> >>>>>> >> > > >>>> >> > >> >> >>>>>> It's a common perception that making a branch >> > > >>>> >> > >> >> >>>>>> freezes adding >> > > >>>> >> > new features to the release, perhaps in an unofficial way >> > > >>>> >> > (more of a courtesy >> > > >>>> >> > rather than a rule). But if you're working with a different >> > > >>>> >> > assumption - that >> > > >>>> >> > just the existence of the branch does not stop Dat from still >> > > >>>> >> > merging his work >> > > >>>> >> > and the work being included in 8.0 - then I agree, waiting for >> > > >>>> >> > him to merge >> > > >>>> >> > doesn't need to stop the creation of the branch. >> > > >>>> >> > >> >> >>>>>> >> > > >>>> >> > >> >> >>>>>> If, however, once the branch is there people >> > > >>>> >> > >> >> >>>>>> object to Dat >> > > >>>> >> > merging his work because it's "too late", then the branch >> > > >>>> >> > shouldn't be >> > > >>>> >> > created yet because we want to really try to clear that >> > > >>>> >> > blocker for 8.0. >> > > >>>> >> > >> >> >>>>>> >> > > >>>> >> > >> >> >>>>>> Cassandra >> > > >>>> >> > >> >> >>>>>> >> > > >>>> >> > >> >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>> >> > > >>>> >> > >> >> >>>>>>> Ok thanks for answering. >> > > >>>> >> > >> >> >>>>>>> >> > > >>>> >> > >> >> >>>>>>> > - I think Solr needs a couple more weeks since >> > > >>>> >> > >> >> >>>>>>> > the work Dat >> > > >>>> >> > is doing isn't quite done yet. >> > > >>>> >> > >> >> >>>>>>> >> > > >>>> >> > >> >> >>>>>>> We can wait a few more weeks to create the >> > > >>>> >> > >> >> >>>>>>> branch but I >> > > >>>> >> > don't think that one action (creating the branch) prevents the >> > > >>>> >> > other (the >> > > >>>> >> > work Dat is doing). >> > > >>>> >> > >> >> >>>>>>> HTTP/2 is one of the blocker for the release but >> > > >>>> >> > >> >> >>>>>>> it can be done >> > > >>>> >> > in master and backported to the appropriate branch as any >> > > >>>> >> > other feature ? >> > > >>>> >> > We just need an issue with the blocker label to ensure that >> > > >>>> >> > >> >> >>>>>>> we don't miss it ;). Creating the branch early >> > > >>>> >> > >> >> >>>>>>> would also help >> > > >>>> >> > in case you don't want to release all the work at once in >> > > >>>> >> > 8.0.0. >> > > >>>> >> > >> >> >>>>>>> Next week was just a proposal, what I meant was >> > > >>>> >> > >> >> >>>>>>> soon >> > > >>>> >> > because we target a release in a few months. >> > > >>>> >> > >> >> >>>>>>> >> > > >>>> >> > >> >> >>>>>>> >> > > >>>> >> > >> >> >>>>>>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> IMO next week is a bit too soon for the branch >> > > >>>> >> > >> >> >>>>>>>> - I think Solr >> > > >>>> >> > needs a couple more weeks since the work Dat is doing isn't >> > > >>>> >> > quite done yet. >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> Solr needs the HTTP/2 work Dat has been doing, >> > > >>>> >> > >> >> >>>>>>>> and he told >> > > >>>> >> > me yesterday he feels it is nearly ready to be merged into >> > > >>>> >> > master. However, >> > > >>>> >> > it does require a new release of Jetty to Solr is able to >> > > >>>> >> > retain Kerberos >> > > >>>> >> > authentication support (Dat has been working with that team to >> > > >>>> >> > help test the >> > > >>>> >> > changes Jetty needs to support Kerberos with HTTP/2). They >> > > >>>> >> > should get that >> > > >>>> >> > release out soon, but we are dependent on them a little bit. >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> He can hopefully reply with more details on his >> > > >>>> >> > >> >> >>>>>>>> status and >> > > >>>> >> > what else needs to be done. >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> Once Dat merges his work, IMO we should leave >> > > >>>> >> > >> >> >>>>>>>> it in master >> > > >>>> >> > for a little bit. While he has been beasting and testing with >> > > >>>> >> > Jenkins as he goes >> > > >>>> >> > along, I think it would be good to have all the regular master >> > > >>>> >> > builds work on >> > > >>>> >> > it for a little bit also. >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> Of the other blockers, the only other large-ish >> > > >>>> >> > >> >> >>>>>>>> one is to fully >> > > >>>> >> > remove Trie* fields, which some of us also discussed yesterday >> > > >>>> >> > and it >> > > >>>> >> > seemed we concluded that Solr isn't really ready to do that. >> > > >>>> >> > The performance >> > > >>>> >> > issues with single value lookups are a major obstacle. It >> > > >>>> >> > would be nice if >> > > >>>> >> > someone with a bit more experience with that could comment in >> > > >>>> >> > the issue >> > > >>>> >> > (SOLR-12632) and/or unmark it as a blocker. >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> Cassandra >> > > >>>> >> > >> >> >>>>>>>> >> > > >>>> >> > >> >> >>>>>>>> On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > >> >> >>>>>>>>> I find 9 open blockers for 8.0: >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND >> > > >>>> >> > %20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > >> >> >>>>>>>>> As David mentioned, many of the SOlr >> > > >>>> >> > >> >> >>>>>>>>> committers are at >> > > >>>> >> > Activate, which >> > > >>>> >> > >> >> >>>>>>>>> ends Thursday so feedback (and work) may be a >> > > >>>> >> > >> >> >>>>>>>>> bit >> > > >>>> >> > delayed. >> > > >>>> >> > >> >> >>>>>>>>> On Wed, Oct 17, 2018 at 8:11 AM David Smiley >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > Hi, >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > Thanks for volunteering to do the 8.0 >> > > >>>> >> > >> >> >>>>>>>>> > release Jim! >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > Many of us are at the Activate Conference in >> > > >>>> >> > >> >> >>>>>>>>> > Montreal. >> > > >>>> >> > We had a committers meeting where we discussed some of the >> > > >>>> >> > blockers. I >> > > >>>> >> > think only a couple items were raised. I'll leave Dat to >> > > >>>> >> > discuss the one on >> > > >>>> >> > HTTP2. On the Solr nested docs front, I articulated one and >> > > >>>> >> > we mostly came >> > > >>>> >> > to a decision on how to do it. It's not "hard" just a matter >> > > >>>> >> > of how to hook in >> > > >>>> >> > some functionality so that it's user-friendly. I'll file an >> > > >>>> >> > issue for this. >> > > >>>> >> > Inexplicably I'm sheepish about marking issues "blocker" but I >> > > >>>> >> > shouldn't be. >> > > >>>> >> > I'll file that issue and look at another issue or two that >> > > >>>> >> > ought to be blockers. >> > > >>>> >> > Nothing is "hard" or tons of work that is in my sphere of work. >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > On the Lucene side, I will commit >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-7875 RE >> > > >>>> >> > MultiFields either >> > > >>>> >> > late tonight or tomorrow when I have time. It's ready to be >> > > >>>> >> > committed; just >> > > >>>> >> > sitting there. It's a minor thing but important to make this >> > > >>>> >> > change now >> > > >>>> >> > before 8.0. >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > I personally plan to spend more time on the >> > > >>>> >> > >> >> >>>>>>>>> > upcoming >> > > >>>> >> > weeks on a few of these 8.0 things. >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > ~ David >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> > On Wed, Oct 17, 2018 at 4:21 AM jim ferenczi >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >> Hi, >> > > >>>> >> > >> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 >> > > >>>> >> > >> >> >>>>>>>>> >> release: >> > > >>>> >> > >> >> >>>>>>>>> >> https://issues.apache.org/jira/browse/LUCENE- >> > > >>>> >> > 7075?jql=(project%3D%22Lucene%20- >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20 >> > > >>>> >> > >> >> >>>>>>>>> >> We're planning to work on these issues in >> > > >>>> >> > >> >> >>>>>>>>> >> the coming >> > > >>>> >> > days, are there any other blockers (not in the list) on Solr >> > > >>>> >> > side. >> > > >>>> >> > >> >> >>>>>>>>> >> Now that Lucene 7.5 is released I'd like to >> > > >>>> >> > >> >> >>>>>>>>> >> create a >> > > >>>> >> > Lucene 8 branch soon (next week for instance ? ). There are >> > > >>>> >> > some work to do >> > > >>>> >> > to make sure that all tests pass, add the new version... >> > > >>>> >> > >> >> >>>>>>>>> >> I can take care of it if there are no >> > > >>>> >> > >> >> >>>>>>>>> >> objections. Creating >> > > >>>> >> > the branch in advance would help to stabilize this version >> > > >>>> >> > (people can >> > > >>>> >> > continue to work on new features that are not targeted for >> > > >>>> >> > 8.0) and >> > > >>>> >> > >> >> >>>>>>>>> >> we can discuss the best date for the >> > > >>>> >> > >> >> >>>>>>>>> >> release when all >> > > >>>> >> > blockers are resolved. What do you think ? >> > > >>>> >> > >> >> >>>>>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >> Le mar. 18 sept. 2018 à 11:32, Adrien Grand >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>> Đạt, is >> > > >>>> >> > >> >> >>>>>>>>> >>> https://issues.apache.org/jira/browse/SOLR- >> > > >>>> >> > 12639 the right issue for HTTP/2 support? Should we make it a >> > > >>>> >> > blocker for >> > > >>>> >> > 8.0? >> > > >>>> >> > >> >> >>>>>>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>> Le lun. 3 sept. 2018 à 23:37, Adrien Grand >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> For the record here is the JIRA query for >> > > >>>> >> > >> >> >>>>>>>>> >>>> blockers that >> > > >>>> >> > Erick referred to: https://issues.apache.org/jira/browse/SOLR- >> > > >>>> >> > 12720?jql=(project%3D%22Lucene%20- >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20 >> > > >>>> >> > >> >> >>>>>>>>> >>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>> Ok thanks Đạt and Erick. I'll follow the >> > > >>>> >> > >> >> >>>>>>>>> >>>>> blockers on >> > > >>>> >> > Jira. Đạt do you have an issue opened for the HTTP/2 support ? >> > > >>>> >> > >> >> >>>>>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>> Le ven. 31 août 2018 à 16:40, Erick >> > > >>>> >> > >> >> >>>>>>>>> >>>>> Erickson >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> There's also the issue of what to do as >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> far as >> > > >>>> >> > removing Trie* support. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> I think there's a blocker JIRA. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> project = SOLR AND priority = Blocker >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> AND >> > > >>>> >> > resolution = Unresolved >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> Shows 6 blockers >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> On Fri, Aug 31, 2018 at 4:12 AM Đạt Cao >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> Mạnh >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > Hi Jim, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > I really want to introduce the >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > support of HTTP/2 >> > > >>>> >> > into Solr 8.0 (currently cooked in jira/http2 branch). The >> > > >>>> >> > changes of that >> > > >>>> >> > branch are less than Star Burst effort and closer to be merged >> > > >>>> >> > into master >> > > >>>> >> > branch. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > Thanks! >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > On Fri, Aug 31, 2018 at 3:55 PM jim >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> > ferenczi >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> Hi all, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> I'd like to get some feedback >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> regarding the >> > > >>>> >> > upcoming Lucene/Solr 8 release. There are still some cleanups >> > > >>>> >> > and docs to >> > > >>>> >> > add on the Lucene side but it seems that all blockers are >> > > >>>> >> > resolved. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> From a Solr perspective are there >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> any important >> > > >>>> >> > changes that need to be done or are we still good with the >> > > >>>> >> > October target for >> > > >>>> >> > the release ? Adrien mentioned the Star Burst effort some time >> > > >>>> >> > ago, is it >> > > >>>> >> > something that is planned for 8 ? >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> Cheers, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> Jim >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> Le mer. 1 août 2018 à 19:02, David >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> Smiley >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> Yes, that new BKD/Points based code >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> is >> > > >>>> >> > definitely something we want in 8 or 7.5 -- it's a big deal. >> > > >>>> >> > I think it would also >> > > >>>> >> > be awesome if we had highlighter that could use the >> > > >>>> >> > Weight.matches() API -- >> > > >>>> >> > again for either 7.5 or 8. I'm working on this on the >> > > >>>> >> > UnifiedHighlighter front >> > > >>>> >> > and Alan from other aspects. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> ~ David >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> On Wed, Aug 1, 2018 at 12:51 PM >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> Adrien Grand >> > > >>>> >> > <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> I was hoping that we would release >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> some bits >> > > >>>> >> > of this new support for geo shapes in 7.5 already. We are >> > > >>>> >> > already very close >> > > >>>> >> > to being able to index points, lines and polygons and query >> > > >>>> >> > for intersection >> > > >>>> >> > with an envelope. It would be nice to add support for other >> > > >>>> >> > relations (eg. >> > > >>>> >> > disjoint) and queries (eg. polygon) but the current work looks >> > > >>>> >> > already useful >> > > >>>> >> > to me. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> Le mer. 1 août 2018 à 17:00, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>> Robert Muir >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> My only other suggestion is we >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> may want to >> > > >>>> >> > get Nick's shape stuff into >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> the sandbox module at least for >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> 8.0 so that it >> > > >>>> >> > can be tested out. I >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> think it looks like that wouldn't >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> delay any >> > > >>>> >> > October target though? >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> On Wed, Aug 1, 2018 at 9:51 AM, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> Adrien >> > > >>>> >> > Grand <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > I'd like to revive this thread >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > now that these >> > > >>>> >> > new optimizations for >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > collection of top docs are more >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > usable and >> > > >>>> >> > enabled by default in >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > IndexSearcher >> > > >>>> >> > (https://issues.apache.org/jira/browse/LUCENE-8060). Any >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > feedback about starting to work >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > towards >> > > >>>> >> > releasing 8.0 and targeting October >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > 2018? >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > Le jeu. 21 juin 2018 à 09:31, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > Adrien Grand >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Hi Robert, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> I agree we need to make it >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> more usable >> > > >>>> >> > before 8.0. I would also like to >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> improve ReqOptSumScorer >> > > >>>> >> > (https://issues.apache.org/jira/browse/LUCENE-8204) >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> to leverage impacts so that >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> queries that >> > > >>>> >> > incorporate queries on feature >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> fields >> > > >>>> >> > (https://issues.apache.org/jira/browse/LUCENE-8197) in an >> > > >>>> >> > optional >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Robert Muir >> > > >>>> >> > <[email protected]> a écrit : >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> How can the end user actually >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> use the >> > > >>>> >> > biggest new feature: impacts and >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> BMW? As far as I can tell, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> the issue to >> > > >>>> >> > actually implement the >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> necessary API changes >> > > >>>> >> > (IndexSearcher/TopDocs/etc) is still open and >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> unresolved, although there >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> are some >> > > >>>> >> > interesting ideas on it. This >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> seems like a really big >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> missing piece, >> > > >>>> >> > without a proper API, the stuff >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> is not really usable. I also >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> can't imagine a >> > > >>>> >> > situation where the API >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> could be introduced in a >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> followup minor >> > > >>>> >> > release because it would be >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> too invasive. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> On Mon, Jun 18, 2018 at 1:19 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> PM, Adrien >> > > >>>> >> > Grand <[email protected]> wrote: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > Hi all, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > I would like to start >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > discussing releasing >> > > >>>> >> > Lucene/Solr 8.0. Lucene 8 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > already >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > has some good changes around >> > > >>>> >> > scoring, notably cleanups to >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > similarities[1][2][3], >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > indexing of >> > > >>>> >> > impacts[4], and an implementation of >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > Block-Max WAND[5] which, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > once >> > > >>>> >> > combined, allow to run queries faster >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > when >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > total hit counts are not >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > requested. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [1] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8116 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [2] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8020 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [3] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8007 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [4] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-4198 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [5] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8135 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > In terms of bug fixes, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > there is also a >> > > >>>> >> > bad relevancy bug[6] which is >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > only in >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > 8.0 because it required a >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > breaking >> > > >>>> >> > change[7] to be implemented. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [6] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8031 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [7] >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8134 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > As usual, doing a new major >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > release >> > > >>>> >> > will also help age out old codecs, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > which >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > in-turn make maintenance >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > easier: 8.0 >> > > >>>> >> > will no longer need to care about >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > the >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > fact that some codecs were >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > initially >> > > >>>> >> > implemented with a random-access >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > API >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > for doc values, that >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > pre-7.0 indices >> > > >>>> >> > encoded norms differently, or that >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > pre-6.2 indices could not >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > record an >> > > >>>> >> > index sort. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > I also expect that we will >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > come up with >> > > >>>> >> > ideas of things to do for 8.0 >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > as we >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > feel that the next major is >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > getting >> > > >>>> >> > closer. In terms of planning, I was >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > thinking that we could >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > target something >> > > >>>> >> > like october 2018, which would >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > be >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > 12-13 months after 7.0 and >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > 3-4 months >> > > >>>> >> > from now. >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > From a Solr perspective, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > the main >> > > >>>> >> > change I'm aware of that would be >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > worth >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > releasing a new major is >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > the Star Burst >> > > >>>> >> > effort. Is it something we want >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > to >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > get in for 8.0? >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > Adrien >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> ------------------------------------------------------ >> > > >>>> >> > --------------- >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> To unsubscribe, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> > >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> ----------------------------------------------------------- >> > > >>>> >> > ---------- >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> -- >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> Consultant, >> > > >>>> >> > Developer, Author, Speaker >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> LinkedIn: >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>> http://linkedin.com/in/davidwsmiley >> > > >>>> >> > | Book: http://www.solrenterprisesearchserver.com >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> -------------------------------------------------------------------- >> > > >>>> >> > - >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >> > > >>>> >> > >> >> >>>>>>>>> > -- >> > > >>>> >> > >> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, >> > > >>>> >> > >> >> >>>>>>>>> > Developer, >> > > >>>> >> > Author, Speaker >> > > >>>> >> > >> >> >>>>>>>>> > LinkedIn: >> > > >>>> >> > >> >> >>>>>>>>> > http://linkedin.com/in/davidwsmiley | Book: >> > > >>>> >> > http://www.solrenterprisesearchserver.com >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > >> >> >>>>>>>>> --------------------------------------------------------------------- >> > > >>>> >> > >> >> >>>>>>>>> To unsubscribe, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev- >> > > >>>> >> > [email protected] >> > > >>>> >> > >> >> >>>>>>>>> >> > > >>>> >> > >> >> >>> -- >> > > >>>> >> > >> >> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP >> > > >>>> >> > >> >> >>> Geospatial Software Guy | Elasticsearch >> > > >>>> >> > >> >> >>> Apache Lucene Committer >> > > >>>> >> > >> >> >>> [email protected] >> > > >>>> >> > >> >> >> >> > > >>>> >> > >> >> >> -- >> > > >>>> >> > >> >> >> Lucene/Solr Search Committer, Consultant, Developer, >> > > >>>> >> > >> >> >> Author, >> > > >>>> >> > Speaker >> > > >>>> >> > >> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > > >>>> >> > http://www.solrenterprisesearchserver.com >> > > >>>> >> > >> >> >> > > >>>> >> > >> >> --------------------------------------------------------------------- >> > > >>>> >> > >> >> 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] >> > > >>>> >> > >> >> > > >>>> >> > >> -- >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, >> > > >>>> >> > >> Speaker >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > > >>>> >> > http://www.solrenterprisesearchserver.com >> > > >>>> >> > >> >> > > >>>> >> > >> -- >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, >> > > >>>> >> > >> Speaker >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > > >>>> >> > http://www.solrenterprisesearchserver.com >> > > >>>> >> > >> >> > > >>>> >> > >> >> > > >>>> >> > >> >> > > >>>> >> > >> > > >>>> >> > >> > > >>>> >> > -- >> > > >>>> >> > Adrien >> > > >>>> >> > >> > > >>>> >> > --------------------------------------------------------------------- >> > > >>>> >> > 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] >> > > >>>> >> >> > > >>>> > >> > > >>>> > >> > > >>>> > -- >> > > >>>> > http://www.the111shift.com >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> -- >> > > >>>> Adrien >> > > >>>> >> > > >>>> --------------------------------------------------------------------- >> > > >>>> To unsubscribe, e-mail: [email protected] >> > > >>>> For additional commands, e-mail: [email protected] >> > > >>>> >> > > >>> >> > > >>> >> > > >>> -- >> > > >>> http://www.the111shift.com >> > > >> >> > > >> >> > > > -- >> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker >> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> > > > http://www.solrenterprisesearchserver.com >> > > >> > > >> > > >> > > -- >> > > ----------------------------------------------------- >> > > Noble Paul >> > > >> > > >> > > --------------------------------------------------------------------- >> > > 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] >> > >> >> >> --------------------------------------------------------------------- >> 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]
