Jim, Since 7.7 needs to be released before 8.0 does that leave time to get SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is currently under review.
Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others feel this should make it into 8.0 or not. Kevin Risden On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.feren...@gmail.com> wrote: > > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't > handle two concurrent releases in our tests > (https://issues.apache.org/jira/browse/LUCENE-8665). > 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 bump for 8.0 when 7.7 is out. > > > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.feren...@gmail.com> a écrit : >> >> Hi, >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create >> the Jenkins tasks for these versions, Uwe can you also add them to the >> Policeman's Jenkins job ? >> This also means that the feature freeze phase has started for both versions >> (7.7 and 8.0): >> >> No new features may be committed to the branch. >> Documentation patches, build patches and serious bug fixes may be committed >> to the branch. However, you should submit all patches you want to commit to >> Jira first to give others the chance to review and possibly vote against the >> patch. Keep in mind that it is our main intention to keep the branch as >> stable as possible. >> All patches that are intended for the branch should first be committed to >> the unstable branch, merged into the stable branch, and then into the >> current release branch. >> Normal unstable and stable branch development may continue as usual. >> However, if you plan to commit a big change to the unstable branch while the >> branch feature freeze is in effect, think twice: can't the addition wait a >> couple more days? Merges of bug fixes into the branch may become more >> difficult. >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a >> release candidate build. >> >> >> Thanks, >> Jim >> >> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teof...@gmail.com> a >> écrit : >>> >>> sure, thanks Jim! >>> >>> Tommaso >>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi >>> <jim.feren...@gmail.com> 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 >>> > <tommaso.teof...@gmail.com> 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 >>> >> <jpou...@gmail.com> ha scritto: >>> >> > >>> >> > Hi Noble, >>> >> > >>> >> > No it hasn't created yet. >>> >> > >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.p...@gmail.com> >>> >> > wrote: >>> >> > > >>> >> > > Is the branch already cut for 8.0? which is it? >>> >> > > >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley >>> >> > > <david.w.smi...@gmail.com> 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 >>> >> > > > <jan....@cominvent.com> 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 >>> >> > > >> <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 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 >>> >> > > >> >>> >> > > >> >>> >> > > > -- >>> >> > > > 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: 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 >>> >> > >>> >> >>> >> >>> >> --------------------------------------------------------------------- >>> >> 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 >>> --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
