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] >> >>
