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