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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> a > écrit : > >> > >> +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 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 <[email protected]> > 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 <[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 > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
