lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tomás Fernández Löbbe <tomasflo...@gmail.com>
Subject Re: Lucene/Solr 8.0
Date Fri, 25 Jan 2019 19:39:48 GMT
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
>> >> 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
>> >> > >> 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
>> >> > >>
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >> > --
>> >> > 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
>> >>
>> >
>> >
>> > --
>> > http://www.the111shift.com
>>
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> http://www.the111shift.com
>

Mime
View raw message