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 <caomanhdat...@gmail.com> 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 <jim.feren...@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 <casstarg...@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.feren...@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 <casstarg...@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 < >>>>> erickerick...@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.smi...@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.feren...@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%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 <jpou...@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 <jpou...@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%3DBlocker%20and%20resolution%20%3D%20Unresolved%20 >>>>>> >>>> >>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi < >>>>>> jim.feren...@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 < >>>>>> erickerick...@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 < >>>>>> caomanhdat...@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.feren...@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.smi...@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 < >>>>>> jpou...@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 < >>>>>> rcm...@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 < >>>>>> jpou...@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 < >>>>>> jpou...@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 < >>>>>> rcm...@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 < >>>>>> jpou...@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-unsubscr...@lucene.apache.org >>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: >>>>>> dev-h...@lucene.apache.org >>>>>> >>>>>> >>>>> >>> >>>>>> >>>>>> >>>>> > >>>>>> >>>>>> >>>>> >>>>>> >>>>>> >>>>> >>>>>> --------------------------------------------------------------------- >>>>>> >>>>>> >>>>> To unsubscribe, e-mail: >>>>>> dev-unsubscr...@lucene.apache.org >>>>>> >>>>>> >>>>> For additional commands, e-mail: >>>>>> dev-h...@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-unsubscr...@lucene.apache.org >>>>>> >>>>>> For additional commands, e-mail: dev-h...@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-unsubscr...@lucene.apache.org >>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org >>>>>> >>>>>> -- Nicholas Knize, Ph.D., GISP Geospatial Software Guy | Elasticsearch Apache Lucene Committer nkn...@apache.org
