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 <gus.h...@gmail.com> 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 <jpou...@gmail.com> 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 <gus.h...@gmail.com> 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 <u...@thetaphi.de> 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: u...@thetaphi.de >> >> >> >> > -----Original Message----- >> >> > From: Adrien Grand <jpou...@gmail.com> >> >> > Sent: Thursday, January 24, 2019 5:33 PM >> >> > To: Lucene Dev <dev@lucene.apache.org> >> >> > 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 <jim.feren...@gmail.com >> > >> >> > 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 <romseyg...@gmail.com >> > >> >> > 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 <romseyg...@gmail.com> >> >> > 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 <u...@thetaphi.de> 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: u...@thetaphi.de >> >> > >> >> >> > >> From: Alan Woodward <romseyg...@gmail.com> >> >> > >> Sent: Monday, January 7, 2019 11:30 AM >> >> > >> To: dev@lucene.apache.org >> >> > >> 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 <david.w.smi...@gmail.com> >> >> > wrote: >> >> > >> >> >> > >> January. >> >> > >> >> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.em...@gmail.com> >> >> > 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 >> >> > <david.w.smi...@gmail.com> 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 <jpou...@gmail.com> >> >> > wrote: >> >> > >> >> >> > >> +1 >> >> > >> >> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward >> >> > <romseyg...@gmail.com> 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 < >> casstarg...@gmail.com> >> >> > 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 >> >> > <erickerick...@gmail.com> 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 < >> jim.feren...@gmail.com> >> >> > 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 >> >> > <david.w.smi...@gmail.com> a écrit : >> >> > >> >> >> >> >> > >> >> >> +1 to a 7.6 —lots of stuff in there >> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize >> >> > <nkn...@gmail.com> 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 >> >> > <caomanhdat...@gmail.com> 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 >> >> > <jim.feren...@gmail.com> 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 >> >> > <casstarg...@gmail.com> 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 >> >> > <jim.feren...@gmail.com> 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 >> >> > <casstarg...@gmail.com> 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 >> >> > <erickerick...@gmail.com> 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 >> >> > <david.w.smi...@gmail.com> 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 >> >> > <jim.feren...@gmail.com> 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 >> >> > <jpou...@gmail.com> 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 >> >> > <jpou...@gmail.com> 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 >> >> > <jim.feren...@gmail.com> 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 >> >> > <erickerick...@gmail.com> 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 >> >> > <caomanhdat...@gmail.com> 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 >> >> > <jim.feren...@gmail.com> 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 >> >> > <david.w.smi...@gmail.com> 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 >> >> > <jpou...@gmail.com> 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 >> >> > <rcm...@gmail.com> 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 <jpou...@gmail.com> 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 >> >> > <jpou...@gmail.com> 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 >> >> > <rcm...@gmail.com> 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 <jpou...@gmail.com> 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- >> >> > unsubscr...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: >> dev- >> >> > h...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> >> >> > >> >> >>>>>>>>> >>>>>> >>>>> > >> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> ----------------------------------------------------------- >> >> > ---------- >> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev- >> >> > unsubscr...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev- >> >> > h...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> >> > >> >> >>>>>>>>> >>>>>> >>> -- >> >> > >> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, >> >> > Developer, Author, Speaker >> >> > >> >> >>>>>>>>> >>>>>> >>> LinkedIn: >> http://linkedin.com/in/davidwsmiley >> >> > | Book: http://www.solrenterprisesearchserver.com >> >> > >> >> >>>>>>>>> >>>>>> >> >> > >> >> >>>>>>>>> >>>>>> >> -------------------------------------------------------------------- >> >> > - >> >> > >> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev- >> >> > unsubscr...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev- >> >> > h...@lucene.apache.org >> >> > >> >> >>>>>>>>> >>>>>> >> >> > >> >> >>>>>>>>> > -- >> >> > >> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, >> Developer, >> >> > Author, Speaker >> >> > >> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | >> Book: >> >> > http://www.solrenterprisesearchserver.com >> >> > >> >> >>>>>>>>> >> >> > >> >> >>>>>>>>> >> --------------------------------------------------------------------- >> >> > >> >> >>>>>>>>> To unsubscribe, e-mail: dev- >> >> > unsubscr...@lucene.apache.org >> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev- >> >> > h...@lucene.apache.org >> >> > >> >> >>>>>>>>> >> >> > >> >> >>> -- >> >> > >> >> >>> >> >> > >> >> >>> Nicholas Knize, Ph.D., GISP >> >> > >> >> >>> Geospatial Software Guy | Elasticsearch >> >> > >> >> >>> Apache Lucene Committer >> >> > >> >> >>> nkn...@apache.org >> >> > >> >> >> >> >> > >> >> >> -- >> >> > >> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, >> >> > Speaker >> >> > >> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: >> >> > http://www.solrenterprisesearchserver.com >> >> > >> >> >> >> > >> >> >> --------------------------------------------------------------------- >> >> > >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> > >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > >> >> >> >> > >> > >> >> > >> >> >> > >> >> >> > >> -- >> >> > >> Adrien >> >> > >> >> >> > >> >> --------------------------------------------------------------------- >> >> > >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> > >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > >> >> >> > >> -- >> >> > >> 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: dev-unsubscr...@lucene.apache.org >> >> > For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> >> >> >> --------------------------------------------------------------------- >> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> >> > >> > >> > -- >> > http://www.the111shift.com >> >> >> >> -- >> Adrien >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > > -- > http://www.the111shift.com >
