Đạ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%3DBlocker%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 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: [email protected] >>> >>>>> >>> For additional commands, e-mail: [email protected] >>> >>>>> >>> >>> >>>>> > >>> >>>>> >>> >>>>> >>> --------------------------------------------------------------------- >>> >>>>> To unsubscribe, e-mail: [email protected] >>> >>>>> For additional commands, e-mail: [email protected] >>> >>>>> >>> >>> -- >>> >>> Lucene/Solr Search Committer, Consultant, 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] >>> >>>
