lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Knize <nkn...@gmail.com>
Subject Re: Lucene/Solr 8.0
Date Thu, 31 Jan 2019 23:27:05 GMT
Thank you Jim. LUCENE-8669
<https://issues.apache.org/jira/browse/LUCENE-8669>has been merged.

- Nick

On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com> 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 <nknize@gmail.com> 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 <krisden@apache.org> 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 <jim.ferenczi@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.ferenczi@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.teofili@gmail.com> a écrit :
>>> >>>
>>> >>> sure, thanks Jim!
>>> >>>
>>> >>> Tommaso
>>> >>>
>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>> <jim.ferenczi@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.teofili@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
>>> >>> >> <jpountz@gmail.com> ha scritto:
>>> >>> >> >
>>> >>> >> > Hi Noble,
>>> >>> >> >
>>> >>> >> > No it hasn't created yet.
>>> >>> >> >
>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>> noble.paul@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.smiley@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.asf@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 <
>>> tomasflobbe@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.heck@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 <
>>> jpountz@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.heck@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 <
>>> uwe@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
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> > -----Original Message-----
>>> >>> >> > > >>>> >> > From: Adrien Grand <jpountz@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.ferenczi@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 <
>>> romseygeek@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 <
>>> romseygeek@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 <
>>> uwe@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
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> From: Alan Woodward <romseygeek@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.smiley@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> January.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>> sg.online.email@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.smiley@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 <
>>> jpountz@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> +1
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>> >> > > >>>> >> > <romseygeek@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 <
>>> casstargett@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
>>> >>> >> > > >>>> >> > <erickerickson@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.ferenczi@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.smiley@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
>>> >>> >> > > >>>> >> > <nknize@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
>>> >>> >> > > >>>> >> > <caomanhdat317@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.ferenczi@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
>>> >>> >> > > >>>> >> > <casstargett@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.ferenczi@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
>>> >>> >> > > >>>> >> > <casstargett@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
>>> >>> >> > > >>>> >> > <erickerickson@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.smiley@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.ferenczi@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
>>> >>> >> > > >>>> >> > <jpountz@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
>>> >>> >> > > >>>> >> > <jpountz@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.ferenczi@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
>>> >>> >> > > >>>> >> > <erickerickson@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
>>> >>> >> > > >>>> >> > <caomanhdat317@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.ferenczi@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.smiley@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
>>> >>> >> > > >>>> >> > <jpountz@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
>>> >>> >> > > >>>> >> > <rcmuir@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 <jpountz@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
>>> >>> >> > > >>>> >> > <jpountz@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
>>> >>> >> > > >>>> >> > <rcmuir@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 <jpountz@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional
>>> commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> -----------------------------------------------------------
>>> >>> >> > > >>>> >> > ----------
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe,
>>> e-mail: dev-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional
>>> commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands,
>>> e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail:
>>> dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> >>> >> > > >>>> >> > >> >> >>> --
>>> >>> >> > > >>>> >> > >> >> >>>
>>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >>
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Adrien
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> ---------------------------------------------------------------------
>>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail:
>>> dev-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> For additional commands, e-mail:
>>> dev-help@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>
>>
>> --

Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene PMC Member and Committer
nknize@apache.org

Mime
View raw message