+1 to a 7.6 —lots of stuff in there On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <[email protected]> wrote:
> If we're planning to postpone cutting an 8.0 branch until a few weeks from > now then I'd like to propose (and volunteer to RM) a 7.6 release targeted > for late November or early December (following the typical 2 month release > pattern). It feels like this might give a little breathing room for > finishing up 8.0 blockers? And looking at the change log there appear to be > a healthy list of features, bug fixes, and improvements to both Solr and > Lucene that warrant a 7.6 release? Personally I wouldn't mind releasing the > LatLonShape encoding changes in LUCENE-8521 > <https://issues.apache.org/jira/browse/LUCENE-8521> and selective > indexing work done in LUCENE-8496 > <https://issues.apache.org/jira/browse/LUCENE-8496>. Any objections or > thoughts? > > - Nick > > > On Thu, Oct 18, 2018 at 5:32 AM Đạt Cao Mạnh <[email protected]> > wrote: > >> Thanks Cassandra and Jim, >> >> I created a blocker issue for Solr 8.0 SOLR-12883 >> <https://issues.apache.org/jira/browse/SOLR-12883>, currently in >> jira/http2 branch there are a draft-unmature implementation of SPNEGO >> authentication which enough to makes the test pass, this implementation >> will be removed when SOLR-12883 gets resolved . Therefore I don't see any >> problem on merging jira/http2 to master branch in the next week. >> >> On Thu, Oct 18, 2018 at 2:33 AM jim ferenczi <[email protected]> >> wrote: >> >>> > But if you're working with a different assumption - that just the >>> existence of the branch does not stop Dat from still merging his work and >>> the work being included in 8.0 - then I agree, waiting for him to merge >>> doesn't need to stop the creation of the branch. >>> >>> Yes that's my reasoning. This issue is a blocker so we won't release >>> without it but we can work on the branch in the meantime and let other >>> people work on new features that are not targeted to 8. >>> >>> Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <[email protected]> >>> a écrit : >>> >>>> OK - I was making an assumption that the timeline for the first 8.0 RC >>>> would be ASAP after the branch is created. >>>> >>>> It's a common perception that making a branch freezes adding new >>>> features to the release, perhaps in an unofficial way (more of a courtesy >>>> rather than a rule). But if you're working with a different assumption - >>>> that just the existence of the branch does not stop Dat from still merging >>>> his work and the work being included in 8.0 - then I agree, waiting for him >>>> to merge doesn't need to stop the creation of the branch. >>>> >>>> If, however, once the branch is there people object to Dat merging his >>>> work because it's "too late", then the branch shouldn't be created yet >>>> because we want to really try to clear that blocker for 8.0. >>>> >>>> Cassandra >>>> >>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <[email protected]> >>>> wrote: >>>> >>>>> Ok thanks for answering. >>>>> >>>>> > - I think Solr needs a couple more weeks since the work Dat is doing >>>>> isn't quite done yet. >>>>> >>>>> We can wait a few more weeks to create the branch but I don't think >>>>> that one action (creating the branch) prevents the other (the work Dat is >>>>> doing). >>>>> HTTP/2 is one of the blocker for the release but it can be done in >>>>> master and backported to the appropriate branch as any other feature ? We >>>>> just need an issue with the blocker label to ensure that >>>>> we don't miss it ;). Creating the branch early would also help in case >>>>> you don't want to release all the work at once in 8.0.0. >>>>> Next week was just a proposal, what I meant was soon because we target >>>>> a release in a few months. >>>>> >>>>> >>>>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett <[email protected]> >>>>> a écrit : >>>>> >>>>>> IMO next week is a bit too soon for the branch - I think Solr needs a >>>>>> couple more weeks since the work Dat is doing isn't quite done yet. >>>>>> >>>>>> Solr needs the HTTP/2 work Dat has been doing, and he told me >>>>>> yesterday he feels it is nearly ready to be merged into master. However, >>>>>> it >>>>>> does require a new release of Jetty to Solr is able to retain Kerberos >>>>>> authentication support (Dat has been working with that team to help test >>>>>> the changes Jetty needs to support Kerberos with HTTP/2). They should get >>>>>> that release out soon, but we are dependent on them a little bit. >>>>>> >>>>>> He can hopefully reply with more details on his status and what else >>>>>> needs to be done. >>>>>> >>>>>> Once Dat merges his work, IMO we should leave it in master for a >>>>>> little bit. While he has been beasting and testing with Jenkins as he >>>>>> goes >>>>>> along, I think it would be good to have all the regular master builds >>>>>> work >>>>>> on it for a little bit also. >>>>>> >>>>>> Of the other blockers, the only other large-ish one is to fully >>>>>> remove Trie* fields, which some of us also discussed yesterday and it >>>>>> seemed we concluded that Solr isn't really ready to do that. The >>>>>> performance issues with single value lookups are a major obstacle. It >>>>>> would >>>>>> be nice if someone with a bit more experience with that could comment in >>>>>> the issue (SOLR-12632) and/or unmark it as a blocker. >>>>>> >>>>>> Cassandra >>>>>> >>>>>> On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson < >>>>>> [email protected]> wrote: >>>>>> >>>>>>> I find 9 open blockers for 8.0: >>>>>>> >>>>>>> >>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN >>>>>>> >>>>>>> As David mentioned, many of the SOlr committers are at Activate, >>>>>>> which >>>>>>> ends Thursday so feedback (and work) may be a bit delayed. >>>>>>> On Wed, Oct 17, 2018 at 8:11 AM David Smiley < >>>>>>> [email protected]> wrote: >>>>>>> > >>>>>>> > Hi, >>>>>>> > >>>>>>> > Thanks for volunteering to do the 8.0 release Jim! >>>>>>> > >>>>>>> > Many of us are at the Activate Conference in Montreal. We had a >>>>>>> committers meeting where we discussed some of the blockers. I think >>>>>>> only a >>>>>>> couple items were raised. I'll leave Dat to discuss the one on HTTP2. >>>>>>> On >>>>>>> the Solr nested docs front, I articulated one and we mostly came to a >>>>>>> decision on how to do it. It's not "hard" just a matter of how to hook >>>>>>> in >>>>>>> some functionality so that it's user-friendly. I'll file an issue for >>>>>>> this. Inexplicably I'm sheepish about marking issues "blocker" but I >>>>>>> shouldn't be. I'll file that issue and look at another issue or two >>>>>>> that >>>>>>> ought to be blockers. Nothing is "hard" or tons of work that is in my >>>>>>> sphere of work. >>>>>>> > >>>>>>> > On the Lucene side, I will commit >>>>>>> https://issues.apache.org/jira/browse/LUCENE-7875 RE MultiFields >>>>>>> either late tonight or tomorrow when I have time. It's ready to be >>>>>>> committed; just sitting there. It's a minor thing but important to make >>>>>>> this change now before 8.0. >>>>>>> > >>>>>>> > I personally plan to spend more time on the upcoming weeks on a >>>>>>> few of these 8.0 things. >>>>>>> > >>>>>>> > ~ David >>>>>>> > >>>>>>> > >>>>>>> > On Wed, Oct 17, 2018 at 4:21 AM jim ferenczi < >>>>>>> [email protected]> wrote: >>>>>>> >> >>>>>>> >> Hi, >>>>>>> >> We still have two blockers for the Lucene 8 release: >>>>>>> >> >>>>>>> https://issues.apache.org/jira/browse/LUCENE-7075?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>>>>>> >> We're planning to work on these issues in the coming days, are >>>>>>> there any other blockers (not in the list) on Solr side. >>>>>>> >> Now that Lucene 7.5 is released I'd like to create a Lucene 8 >>>>>>> branch soon (next week for instance ? ). There are some work to do to >>>>>>> make >>>>>>> sure that all tests pass, add the new version... >>>>>>> >> I can take care of it if there are no objections. Creating the >>>>>>> branch in advance would help to stabilize this version (people can >>>>>>> continue >>>>>>> to work on new features that are not targeted for 8.0) and >>>>>>> >> we can discuss the best date for the release when all blockers >>>>>>> are resolved. What do you think ? >>>>>>> >> >>>>>>> >> >>>>>>> >> >>>>>>> >> Le mar. 18 sept. 2018 à 11:32, Adrien Grand <[email protected]> >>>>>>> a écrit : >>>>>>> >>> >>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 the >>>>>>> right issue for HTTP/2 support? Should we make it a blocker for 8.0? >>>>>>> >>> >>>>>>> >>> Le lun. 3 sept. 2018 à 23:37, Adrien Grand <[email protected]> >>>>>>> a écrit : >>>>>>> >>>> >>>>>>> >>>> For the record here is the JIRA query for blockers that Erick >>>>>>> referred to: >>>>>>> https://issues.apache.org/jira/browse/SOLR-12720?jql=(project%3D%22Lucene%20-%20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%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] >>>>>>> >>>>>> >>>>>>> > -- >>>>>>> > 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] >>>>>>> >>>>>>> -- > > Nicholas Knize, Ph.D., GISP > Geospatial Software Guy | Elasticsearch > Apache Lucene Committer > [email protected] > -- Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
