Re: Lucene/Solr 8.0

t;>>>> Since we want to release 7.7 first I created the Jenkins job for this >>>>>> version only and will build the first candidate for this version later >>>>>> this week if there are no objection. >>>>>> I'll restore the version b

Re: Lucene/Solr 8.0

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 luckil

Re: Lucene/Solr 8.0

; >>>> >>>> Thanks, >>>> Jim >>>> >>>> >>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili >>>> a écrit : >>>> >>>> >>>> sure, thanks Jim! >>>> >>>> Tomm

Re: Lucene/Solr 8.0

; Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand >> > ha scritto: >> > >> > >> > Hi Noble, >> > >> > No it hasn't created yet. >> > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul wrote: >> > >> > >&

Re: Lucene/Solr 8.0

gt; > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe < > tomasflo...@gmail.com>: > > > > 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

Re: Lucene/Solr 8.0

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 t

Re: Lucene/Solr 8.0

;>>>>>> 7.7. I'll now create the Jenkins tasks for these >>>>>>>> >>>>>>>>>>>> versions, Uwe can you also add them to the Policeman's >>>>>>>> >>>>>>>>>>>> Jenkins job ? >>>>>>&g

Re: Lucene/Solr 8.0

ker once >>>>>>>>>>>>>>>>>>>> before... And it's actually a duplicate of an earlier >>>>>>>>>>>>>>>>>>>> issue (https://issues.apache.org/jira/browse/SOLR-9818). I >>>>>>>>>>>>>

Re: Lucene/Solr 8.0

gt;>>> >>> >> > > > I will work on some documentation for it this week -- >>>> > >>>> >>> >> > > > SOLR-13129 >>>> > >>>> >>> >> > > > >>>> > >>>> >>> >&g

Re: Lucene/Solr 8.0

locker. I'm not familiar > >>>> >>> >> > > >> enough with the UI code to help either unfortunately. > >>>> >>> >> > > >> > >>>> >>> >> > > >> On

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

//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 >>> >>&g

Re: Lucene/Solr 8.0

ing 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 >>> >> > >

Re: Lucene/Solr 8.0

t; 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,

Re: Lucene/Solr 8.0

>>>> > > > >>>> > > > >>>> > > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck > wrote: > > > >>>> > > > > >>>> > I'd like to suggest that > https://issues.apache.org/ji

Re: Lucene/Solr 8.0

t;>>> > > >>>> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck wrote: > > >>>> > > > >>>> > I'd like to suggest that > > >>>> > https://issues.apache.org/jira/browse/SOLR-10211

Re: Lucene/Solr 8.0

t;>> > >>>> > >>>> > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck wrote: > >>>> > > >>>> > I'd like to suggest that > >>>> > https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block >

Re: Lucene/Solr 8.0

us Heck 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 2

Re: Lucene/Solr 8.0

; >> >>> >> I am working on giving my best release time guess as possible on the >>> FOSDEM conference! >>> >> >>> >> Uwe >>> >> >>> >> - >>> >> Uwe Schindler >>> >> Achterdiek 19,

Re: Lucene/Solr 8.0

t; > >> 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 <http:

Re: Lucene/Solr 8.0

; >> Cool, >>> >> >>> >> I am working on giving my best release time guess as possible on the >>> >> FOSDEM conference! >>> >> >>> >> Uwe >>> >> >>> >> - >>> >> Uwe Schind

Re: Lucene/Solr 8.0

on the >> FOSDEM conference! >> >> >> >> Uwe >> >> >> >> - >> >> Uwe Schindler >> >> Achterdiek 19, D-28357 Bremen >> >> http://www.thetaphi.de >> >> eMail: u...@thetaphi.de >> >>

Re: Lucene/Solr 8.0

; Achterdiek 19, D-28357 Bremen > >> http://www.thetaphi.de > >> eMail: u...@thetaphi.de > >> > >> > -Original Message- > >> > From: Adrien Grand > >> > Sent: Thursday, January 24, 2019 5:33 PM > >> > To: Lucene Dev > &g

Re: Lucene/Solr 8.0

e >> eMail: u...@thetaphi.de >> >> > -Original Message- >> > From: Adrien Grand >> > Sent: Thursday, January 24, 2019 5:33 PM >> > To: Lucene Dev >> > Subject: Re: Lucene/Solr 8.0 >> > >> > +1 to release 7.7 and 8.0 in a row

Re: Lucene/Solr 8.0

M conference! > > Uwe > > - > Uwe Schindler > Achterdiek 19, D-28357 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > > -Original Message- > > From: Adrien Grand > > Sent: Thursday, January 24, 2019 5:33 PM > > To: Lucene

RE: Lucene/Solr 8.0

9 5:33 PM > To: Lucene Dev > 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 > wrote: > > > > Hi, > > As we agreed some time ago I'd like to start on rele

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

or 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:*

Re: Lucene/Solr 8.0

enabled for a while. >> >> Uwe >> >> - >> Uwe Schindler >> Achterdiek 19, D-28357 Bremen >> http://www.thetaphi.de <http://www.thetaphi.de/> >> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de> >> >> From: Alan Woodwar

Re: Lucene/Solr 8.0

com>> > Sent: Monday, January 7, 2019 11:30 AM > To: dev@lucene.apache.org <mailto: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 mast

Re: Lucene/Solr 8.0

Thanks for doing this Alan. I'll handle RAMDirectory* removals from the new master (LUCENE-8474) D. On Tue, Jan 8, 2019 at 10:11 AM Alan Woodward wrote: > > > It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE > > in Jira to "master (9.0)" but IIUC that's definitely *NOT*

Re: Lucene/Solr 8.0

> It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE > in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... > because it means all the stuff that's been committed to origin/master over > the past X months won't be listed as "fixed in '8.0'" when people

RE: Lucene/Solr 8.0

ubject: 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

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. It looks like someone

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

Re: Lucene/Solr 8.0

January. On Wed, Dec 19, 2018 at 2:04 AM S G 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 > wrote:

Re: Lucene/Solr 8.0

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 wrote: > I see 10 JIRA issues matching this filter: project in (SOLR,

Re: Lucene/Solr 8.0

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:

Re: Lucene/Solr 8.0

+1 On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward 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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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 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 > wrote: > > > > +1 too.

Re: Lucene/Solr 8.0

+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 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

Re: Lucene/Solr 8.0

+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 a écrit : > +1 to a 7.6 —lots of stuff in there > On Thu, Oct 18,

Re: Lucene/Solr 8.0

+1 to a 7.6 —lots of stuff in there On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize 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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

> 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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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,

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 We're planning to work on these issues in the coming days,

Re: Lucene/Solr 8.0

Đạ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 a écrit : > For the record here is the JIRA query for blockers that Erick referred to: >

Re: Lucene/Solr 8.0

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%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 Le lun. 3 sept. 2018 à 10:36, jim

Re: Lucene/Solr 8.0

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 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 =

Re: Lucene/Solr 8.0

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 wrote: > > Hi Jim, > > I really want to introduce the support of

Re: Lucene/Solr 8.0

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 wrote: > Hi all, > I'd

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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 wrote: > I'd like to revive this thread now

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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

Re: Lucene/Solr 8.0

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