Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <
>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>>>> >>>
>>>> >>>>> >
>>>> >>>>>
>>>> >>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>

Re: Lucene/Solr 8.0

[Dawid Weiss <da...@gmail.com>]

Thanks for doing this Alan. I'll handle RAMDirectory* removals from
the new master (LUCENE-8474)

D.

On Tue, Jan 8, 2019 at 10:11 AM Alan Woodward <ro...@gmail.com> wrote:
>
> > It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE
> > in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ...
> > because it means all the stuff that's been committed to origin/master over
> > the past X months won't be listed as "fixed in '8.0'" when people look
> > at jira in the future.
>
> That would be me… I’ll clean it up, thanks for pointing it out Hoss.
>
> > On 7 Jan 2019, at 23:45, Chris Hostetter <ho...@fucit.org> wrote:
> >
> > : OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > : from master, and am in the process of updating the master branch to
> > : version 9.  New commits that should be included in the 8.0 release
> > : should also be back-ported to branch_8x from master.
> >
> > It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE
> > in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ...
> > because it means all the stuff that's been committed to origin/master over
> > the past X months won't be listed as "fixed in '8.0'" when people look
> > at jira in the future.
> >
> > I'm pretty sure "master (8.0)" should have been renamed "8.0" and a completely
> > new version (with a new internal ID in jira) should have been added for
> > "master (9.0)"
> >
> >       Right?
> >
> > (In the meantime, it seems folks have already added new "8.0"
> > versions for SOLR/LUCENE to Jira, which have a handful of issues mapped to
> > them, that will need cleaned up)
> >
> >
> >
> > : > >> >>>>>>
> > : > >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> > : > >> >>>>>>>>> >>>
> > : > >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> > : > >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> > : > >> >>>>>>>>> >>>>>> >>>>> >>
> > : > >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>> >>>>> >>>
> > : > >> >>>>>>>>> >>>>>> >>>>> >
> > : > >> >>>>>>>>> >>>>>> >>>>>
> > : > >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
> > : > >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>> >>>>>
> > : > >> >>>>>>>>> >>>>>> >>> --
> > : > >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > : > >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> > : > >> >>>>>>>>> >>>>>>
> > : > >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
> > : > >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> >>>>>>
> > : > >> >>>>>>>>> > --
> > : > >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > : > >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> > : > >> >>>>>>>>>
> > : > >> >>>>>>>>> ---------------------------------------------------------------------
> > : > >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> >>>>>>>>>
> > : > >> >>> --
> > : > >> >>>
> > : > >> >>> Nicholas Knize, Ph.D., GISP
> > : > >> >>> Geospatial Software Guy  |  Elasticsearch
> > : > >> >>> Apache Lucene Committer
> > : > >> >>> nknize@apache.org <ma...@apache.org>
> > : > >> >>
> > : > >> >> --
> > : > >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> > : > >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> > : > >>
> > : > >> ---------------------------------------------------------------------
> > : > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : > >>
> > : > >
> > : >
> > : >
> > : > --
> > : > Adrien
> > : >
> > : > ---------------------------------------------------------------------
> > : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> > : > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> > : >
> > : > --
> > : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > : > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>--
> > : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > : > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> > :
> >
> > -Hoss
> > http://www.lucidworks.com/
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

> It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE 
> in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... 
> because it means all the stuff that's been committed to origin/master over 
> the past X months won't be listed as "fixed in '8.0'" when people look 
> at jira in the future.

That would be me… I’ll clean it up, thanks for pointing it out Hoss.

> On 7 Jan 2019, at 23:45, Chris Hostetter <ho...@fucit.org> wrote:
> 
> : OK, Christmas caught up with me a bit… I’ve just created a branch for 8x 
> : from master, and am in the process of updating the master branch to 
> : version 9.  New commits that should be included in the 8.0 release 
> : should also be back-ported to branch_8x from master.
> 
> It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE 
> in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... 
> because it means all the stuff that's been committed to origin/master over 
> the past X months won't be listed as "fixed in '8.0'" when people look 
> at jira in the future.
> 
> I'm pretty sure "master (8.0)" should have been renamed "8.0" and a completely 
> new version (with a new internal ID in jira) should have been added for 
> "master (9.0)"
> 
> 	Right?
> 
> (In the meantime, it seems folks have already added new "8.0" 
> versions for SOLR/LUCENE to Jira, which have a handful of issues mapped to 
> them, that will need cleaned up)
> 
> 
> 
> : > >> >>>>>>
> : > >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> : > >> >>>>>>>>> >>>
> : > >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> : > >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> : > >> >>>>>>>>> >>>>>> >>>>> >>
> : > >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>> >>>>> >>>
> : > >> >>>>>>>>> >>>>>> >>>>> >
> : > >> >>>>>>>>> >>>>>> >>>>>
> : > >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
> : > >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>> >>>>>
> : > >> >>>>>>>>> >>>>>> >>> --
> : > >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> : > >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> : > >> >>>>>>>>> >>>>>>
> : > >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
> : > >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> >>>>>>
> : > >> >>>>>>>>> > --
> : > >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> : > >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> : > >> >>>>>>>>>
> : > >> >>>>>>>>> ---------------------------------------------------------------------
> : > >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > >> >>>>>>>>>
> : > >> >>> --
> : > >> >>>
> : > >> >>> Nicholas Knize, Ph.D., GISP
> : > >> >>> Geospatial Software Guy  |  Elasticsearch
> : > >> >>> Apache Lucene Committer
> : > >> >>> nknize@apache.org <ma...@apache.org>
> : > >> >>
> : > >> >> --
> : > >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> : > >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> : > >>
> : > >> ---------------------------------------------------------------------
> : > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > >>
> : > >
> : > 
> : > 
> : > -- 
> : > Adrien
> : > 
> : > ---------------------------------------------------------------------
> : > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> : > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> : > 
> : > -- 
> : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> : > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>-- 
> : > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> : > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> : 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Chris Hostetter <ho...@fucit.org>]

: OK, Christmas caught up with me a bit… I’ve just created a branch for 8x 
: from master, and am in the process of updating the master branch to 
: version 9.  New commits that should be included in the 8.0 release 
: should also be back-ported to branch_8x from master.

It looks like someone renamed the "master (8.0)" version of SOLR & LUCENE 
in Jira to "master (9.0)" but IIUC that's definitely *NOT* correct ... 
because it means all the stuff that's been committed to origin/master over 
the past X months won't be listed as "fixed in '8.0'" when people look 
at jira in the future.

I'm pretty sure "master (8.0)" should have been renamed "8.0" and a completely 
new version (with a new internal ID in jira) should have been added for 
"master (9.0)"

	Right?

(In the meantime, it seems folks have already added new "8.0" 
versions for SOLR/LUCENE to Jira, which have a handful of issues mapped to 
them, that will need cleaned up)



: > >> >>>>>>
: > >> >>>>>> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
: > >> >>>>>>>>> >>>
: > >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
: > >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
: > >> >>>>>>>>> >>>>>> >>>>> >>
: > >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
: > >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
: > >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
: > >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
: > >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
: > >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> >>>
: > >> >>>>>>>>> >>>>>> >>>>> >
: > >> >>>>>>>>> >>>>>> >>>>>
: > >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
: > >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> >>>>>
: > >> >>>>>>>>> >>>>>> >>> --
: > >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: > >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
: > >> >>>>>>>>> >>>>>>
: > >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
: > >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> >>>>>>
: > >> >>>>>>>>> > --
: > >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: > >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
: > >> >>>>>>>>>
: > >> >>>>>>>>> ---------------------------------------------------------------------
: > >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > >> >>>>>>>>>
: > >> >>> --
: > >> >>>
: > >> >>> Nicholas Knize, Ph.D., GISP
: > >> >>> Geospatial Software Guy  |  Elasticsearch
: > >> >>> Apache Lucene Committer
: > >> >>> nknize@apache.org <ma...@apache.org>
: > >> >>
: > >> >> --
: > >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
: > >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
: > >>
: > >> ---------------------------------------------------------------------
: > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > >>
: > >
: > 
: > 
: > -- 
: > Adrien
: > 
: > ---------------------------------------------------------------------
: > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
: > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
: > 
: > -- 
: > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
: > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>-- 
: > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
: > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
: 

-Hoss
http://www.lucidworks.com/

Re: Lucene/Solr 8.0

[Kevin Risden <kr...@apache.org>]

I am hoping to take a look at upgrading the Hadoop 2.x dependencies to
3.x this weekend/upcoming week before the feature freeze. I know I am
a bit late to starting this but would be great to not be stuck on
Hadoop 2.x much longer. SOLR-9515 was filed by Mark Miller a while ago
for this. There are quite a few Solr JIRAs about issues with JDK9+ and
many of these have been fixed in the Hadoop 3.1/3.2 timeframe. I'm
hoping to sit down and figure out the details. Mark Miller had
previously put up a patch and Hrishikesh Gadre had created JIRAs
(SOLR-9761) for cleaning up some of the security pieces.

I am first looking to make sure Hadoop 3.x works on JDK8 and then can
figure out how many of the JDK9+ JIRAs have been resolved.

Kevin Risden

On Fri, Jan 25, 2019 at 2:40 PM Tomás Fernández Löbbe
<to...@gmail.com> wrote:
>
> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>
> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>
>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>
>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>
>>> Releasing a new major is very challenging on its own, I'd rather not
>>> call it a blocker and delay the release for it since this isn't a new
>>> regression in 8.0: it looks like a problem that has affected Solr
>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> maybe this is something that could get fixed before we build a RC?
>>>
>>>
>>>
>>>
>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>> >
>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>> >
>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >>
>>> >> Cool,
>>> >>
>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>> >>
>>> >> Uwe
>>> >>
>>> >> -----
>>> >> Uwe Schindler
>>> >> Achterdiek 19, D-28357 Bremen
>>> >> http://www.thetaphi.de
>>> >> eMail: uwe@thetaphi.de
>>> >>
>>> >> > -----Original Message-----
>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> >> > Subject: Re: Lucene/Solr 8.0
>>> >> >
>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>> >> >
>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>> >> > wrote:
>>> >> > >
>>> >> > > Hi,
>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>> >> > already created so we can start the process anytime now. Unless there are
>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>> >> > first candidate the week after.
>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>> >> > the question now is whether we are ok to start the release process or if there
>>> >> > are any blockers left ;).
>>> >> > >
>>> >> > >
>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>> >> > a écrit :
>>> >> > >>
>>> >> > >> I’ve started to work through the various deprecations on the new master
>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>> >> > several of them, as it’s not entirely clear what to do.
>>> >> > >>
>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>> >> > are more involved than just deleting code.
>>> >> > >>
>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> >> > >>
>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>> >> > for now.
>>> >> > >>
>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >> > >>
>>> >> > >> Hi,
>>> >> > >>
>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>> >> > later today.
>>> >> > >>
>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>> >> > the jenkins jobs enabled for a while.
>>> >> > >>
>>> >> > >> Uwe
>>> >> > >>
>>> >> > >> -----
>>> >> > >> Uwe Schindler
>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> >> > >> http://www.thetaphi.de
>>> >> > >> eMail: uwe@thetaphi.de
>>> >> > >>
>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> >> > >> To: dev@lucene.apache.org
>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> >> > >>
>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>> >> > from master, and am in the process of updating the master branch to version
>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>> >> > back-ported to branch_8x from master.
>>> >> > >>
>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>> >> > replacement work that needs to be done.
>>> >> > >>
>>> >> > >>
>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> January.
>>> >> > >>
>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>> >> > on nested-documents we are waiting to get our hands on.
>>> >> > >> Any idea when Solr 8 would be out ?
>>> >> > >>
>>> >> > >> Thx
>>> >> > >> SG
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >> > <da...@gmail.com> wrote:
>>> >> > >>
>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> >> > >>    click here:
>>> >> > >>
>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >> > >>
>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>> >> > assigned.
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> +1
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >> > <ro...@gmail.com> wrote:
>>> >> > >> >
>>> >> > >> > Hi all,
>>> >> > >> >
>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>> >> > clean up the master branch and uncover anything that still needs to be done
>>> >> > on 8.0 before we start the release process next year.
>>> >> > >> >
>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>> >> > wrote:
>>> >> > >> >
>>> >> > >> > 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
>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>> >> > 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
>>> >> > <da...@gmail.com> a écrit :
>>> >> > >> >> >>
>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> >> > <nk...@gmail.com> 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
>>> >> > <ca...@gmail.com> 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
>>> >> > <ji...@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
>>> >> > <ca...@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
>>> >> > <ji...@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
>>> >> > <ca...@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
>>> >> > <er...@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
>>> >> > <da...@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
>>> >> > <ji...@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%3DBlocke
>>> >> > r%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
>>> >> > <jp...@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
>>> >> > <jp...@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%3DBlocke
>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> >> > >> >> >>>>>>>>> >>>>
>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> >> > <ji...@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
>>> >> > <er...@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
>>> >> > <ca...@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
>>> >> > <ji...@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
>>> >> > <da...@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
>>> >> > <jp...@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
>>> >> > <rc...@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 <jp...@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
>>> >> > <jp...@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
>>> >> > <rc...@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 <jp...@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>>> >> > help@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>>> >> > ----------
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>> >> > help@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>> >> > help@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>> >> > help@lucene.apache.org
>>> >> > >> >> >>>>>>>>>
>>> >> > >> >> >>> --
>>> >> > >> >> >>>
>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >> > >> >> >>> Apache Lucene Committer
>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > >> >>
>>> >> > >> >
>>> >> > >>
>>> >> > >>
>>> >> > >> --
>>> >> > >> Adrien
>>> >> > >>
>>> >> > >> ---------------------------------------------------------------------
>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > >>
>>> >> > >> --
>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > >>
>>> >> > >> --
>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Adrien
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >
>>> >
>>> > --
>>> > http://www.the111shift.com
>>>
>>>
>>>
>>> --
>>> Adrien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>
>>
>> --
>> http://www.the111shift.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Kevin Risden <kr...@apache.org>]

Thanks Jim agree with your concerns. Reviews have been positive so
far. I am pretty confident that this won't break due to the amount of
testing I've done over the past few days. I am planning to merge the
change to master and 8.x later today. I'll keep and eye on Jenkins and
if the first few runs look ok I'll look at merging it into 8.0.

Kevin Risden

On Wed, Jan 30, 2019 at 2:36 PM jim ferenczi <ji...@gmail.com> wrote:
>
> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>
> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>
>> Hey Jim,
>>
>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>
>> On Wed, Jan 30, 2019 at 1:07 PM
Kevin Risden <kr...@apache.org> wrote:
>>>
>>> Jim,
>>>
>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>> currently under review.
>>>
>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>> feel this should make it into 8.0 or not.
>>>
>>> Kevin Risden
>>>
>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>> >
>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>> >
>>> >
>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>> >>
>>> >> Hi,
>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>> >>
>>> >> No new features may be committed to the branch.
>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Jim
>>> >>
>>> >>
>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>> >>>
>>> >>> sure, thanks Jim!
>>> >>>
>>> >>> Tommaso
>>> >>>
>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>> <ji...@gmail.com> ha scritto:
>>> >>> >
>>> >>> > Go ahead Tommaso the branch is not created yet.
>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>> >>> > early next week. Would that work for you ?
>>> >>> >
>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>> >>> >>
>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>> >>> >>
>>> >>> >> Regards,
>>> >>> >> Tommaso
>>> >>> >>
>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >>> >> <jp...@gmail.com> ha scritto:
>>> >>> >> >
>>> >>> >> > Hi Noble,
>>> >>> >> >
>>> >>> >> > No it hasn't created yet.
>>> >>> >> >
>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>> >>> >> > >
>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>> >>> >> > >
>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>> >>> >> > > >
>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>>> >>> >> > > >
>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>> >>> >> > > >>
>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>> >>> >> > > >> I'll try to take a look next week.
>>> >>> >> > > >>
>>> >>> >> > > >> --
>>> >>> >> > > >> Jan Høydahl, search solution architect
>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>>> >>> >> > > >>
>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>> >>> >> > > >>
>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>> >>> >> > > >>
>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>> >>> >> > > >>>
>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>> >>> >> > > >>>
>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>> >>> >> > > >>>>
>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>> >>> >> > > >>>> >
>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>> >>> >> > > >>>> >
>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> Cool,
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> Uwe
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> -----
>>> >>> >> > > >>>> >> Uwe Schindler
>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> > -----Original Message-----
>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > > Hi,
>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>> >>> >> > > >>>> >> > first candidate the week after.
>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>>> >>> >> > > >>>> >> > are any blockers left ;).
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>> >>> >> > > >>>> >> > a écrit :
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>> >>> >> > > >>>> >> > for now.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Hi,
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>> >>> >> > > >>>> >> > later today.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Uwe
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> -----
>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> January.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Thx
>>> >>> >> > > >>>> >> > >> SG
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> >>> >> > > >>>> >> > >>    click here:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>> >>> >> > > >>>> >> > assigned.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> +1
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > Hi all,
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > 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
>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>> >>> >> > > >>>> >> > 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
>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>> >>> >> > > >>>> >> > >> >> >>
>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <er...@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
>>> >>> >> > > >>>> >> > <da...@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
>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>>> >>> >> > > >>>> >> > r%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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <er...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <da...@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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>>> >>> >> > > >>>> >> > ----------
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> >>> >> > > >>>> >> > >> >> >>> --
>>> >>> >> > > >>>> >> > >> >> >>>
>>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >>
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Adrien
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> ---------------------------------------------------------------------
>>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > --
>>> >>> >> > > >>>> >> > Adrien
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > ---------------------------------------------------------------------
>>> >>> >> > > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >>
>>> >>> >> > > >
>>
>> --
>>
>> Nicholas Knize, Ph.D., GISP
>> Geospatial Software Guy  |  Elasticsearch
>> Apache Lucene Committer
>> nknize@apache.org

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

Thanks for bringing light to SOLR-13126 Mikhail.  This is actually a Lucene
bug; it the issue ought to move to Lucene and have a Lucene level test.
It's a shame to see this regression survived several minor releases.

~ David

On Thu, Feb 14, 2019 at 4:36 AM Mikhail Khludnev <mk...@apache.org> wrote:

> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>
> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
> wrote:
>
>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>
> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>>
>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to
>> Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>> since there’s a lot of editing yet to be done for it.
>>
>> Cassandra
>>
>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>> wrote:
>>
>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
>> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
>> even if it's committed after the 8.0 for the code?  I could avoid touching
>> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
>> change list any way).
>>
>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>>
>> Thanks for letting me know Jason.  Your commit will have missed the cut,
>>> yes, but I don’t think it matters that much.  It will get picked up in a
>>> respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>> then we can just alter CHANGES.txt
>>>
>>>
>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>> wrote:
>>> >
>>> > Hey Alan,
>>> >
>>> > I just committed a minor inconsequential bugfix
>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>> > realize I was cutting it so close to your work on cutting RC1, but
>>> > from commits I see you made this morning preparing for the RC I
>>> > suspect I cut things _very_ close and just missed it.
>>> >
>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>> > problems for you on the release end.  I'm happy to do whatever's
>>> > easiest for you regarding that commit.  It'd be nice to have it
>>> > included in 8.0, but it's not imperative by any means if I've already
>>> > missed the first RC, or it's easier for you to omit from potential
>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>> > go back and update CHANGES.txt I think.
>>> >
>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>> > Thanks for stepping up and handling the release.
>>> >
>>> > Best,
>>> >
>>> > Jason
>>> >
>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> >>
>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
>>> many times in the past so I just mechanically changed the redirect without
>>> thinking of when or if the ref guide was also released.
>>> >> I'll be more careful next time ;).
>>> >>
>>> >> On another note, now that 7.7 is out and that we're preparing the
>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>> was already discussed some time ago
>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
>>> reached a consensus and we have maybe new options with the move to gitbox.
>>> One option discussed in the thread was to remove all files and add a README
>>> that says that this branch is dead. I don't know if it's possible but we
>>> could also make the branch protected in gitbox in order to avoid new
>>> commits. What do you think ? Should we keep this branch and just consider
>>> new commits as useless or should we try to "clean up" all Nx branches that
>>> are not active anymore (5x, 6x, 7x) ?
>>> >>
>>> >> Jim
>>> >>
>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>> casstargett@gmail.com> a écrit :
>>> >>>
>>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>>> just do a blanket find/replace in .htaccess to update the version. If we’re
>>> not going to coordinate binary releases with Ref Guide releases, we need to
>>> be careful not to change the redirects unless that version’s Ref Guide
>>> release is also imminent.
>>> >>>
>>> >>> This is noted in the ReleaseToDo (
>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>> >>>
>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
>>> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
>>> needs to maybe take care of it), but all non-version specific Ref Guide
>>> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
>>> we have an easy way to avoid routing people to dead links.
>>> >>>
>>> >>> Cassandra
>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>>> wrote:
>>> >>>
>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>>> volunteer to be the manager for this round.  My current plan is to build a
>>> release candidate early next week, as soon as the 7.7 release has been
>>> announced.
>>> >>>
>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>> >>>
>>> >>> It is a shame, I agree, but some of this stuff has been deprecated
>>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>>> cleaning this stuff up once 8.0 is out of the door though.
>>> >>>
>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
>>> cycle to remove things that have been deprecated in previous releases?
>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>> further.
>>> >>>
>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we
>>> may need to back port some extra deprecations to 8x.  We don’t necessarily
>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
>>> any problems.  I opened the issues to ensure that we didn’t keep carrying
>>> deprecated code through any further releases.
>>> >>>>
>>> >>>>
>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> I want to ensure people are aware of two issues "Remove deprecated
>>> code in master" that Alan filed:
>>> >>>>
>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>> >>>> There's a "master-deprecations" branch as well.
>>> >>>>
>>> >>>> Although both issues are marked "master (9.0)", I think the intent
>>> is actually 8.0 so that we are finally rid of the deprecated code?
>>> >>>>
>>> >>>> ~ David
>>> >>>>
>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>> wrote:
>>> >>>>>
>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
>>> 8.0.
>>> >>>>> I'm keeping any eye on the builds this weekend but all indications
>>> are
>>> >>>>> no issues so far.
>>> >>>>>
>>> >>>>> Kevin Risden
>>> >>>>>
>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>> wrote:
>>> >>>>>>
>>> >>>>>> Nick, this change seems to be causing test failures. Can you have
>>> a look?
>>> >>>>>>
>>> >>>>>> See eg.
>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>> >>>>>>
>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>>> wrote:
>>> >>>>>>>
>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>> >>>>>>>
>>> >>>>>>> - Nick
>>> >>>>>>>
>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>> jim.ferenczi@gmail.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>> start the first RC when your patch is merged.
>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a
>>> good idea to rush this in for 8.0. Would it be safer to target another
>>> version in order to take some time to ensure that it's not breaking
>>> anything ? I guess that your concern is that a change like this should
>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>> this part of the code and the implications of such a change so I let you
>>> decide what we should do here but let's not delay the release if we realize
>>> that this change requires more than a few days to be merged.
>>> >>>>>>>>
>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com>
>>> a écrit :
>>> >>>>>>>>>
>>> >>>>>>>>> Hey Jim,
>>> >>>>>>>>>
>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>>> along with a pretty straightforward patch. This is a critical one that I
>>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>> >>>>>>>>>
>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Jim,
>>> >>>>>>>>>>
>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>> time to get
>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated
>>> and it is
>>> >>>>>>>>>> currently under review.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious
>>> if others
>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Kevin Risden
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>> jim.ferenczi@gmail.com> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x
>>> because we don't handle two concurrent releases in our tests (
>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job
>>> for this version only and will build the first candidate for this version
>>> later this week if there are no objection.
>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>> jim.ferenczi@gmail.com> a écrit :
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>> add them to the Policeman's Jenkins job ?
>>> >>>>>>>>>>>> This also means that the feature freeze phase has started
>>> for both versions (7.7 and 8.0):
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes
>>> may be committed to the branch. However, you should submit all patches you
>>> want to commit to Jira first to give others the chance to review and
>>> possibly vote against the patch. Keep in mind that it is our main intention
>>> to keep the branch as stable as possible.
>>> >>>>>>>>>>>> All patches that are intended for the branch should first
>>> be committed to the unstable branch, merged into the stable branch, and
>>> then into the current release branch.
>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue
>>> as usual. However, if you plan to commit a big change to the unstable
>>> branch while the branch feature freeze is in effect, think twice: can't the
>>> addition wait a couple more days? Merges of bug fixes into the branch may
>>> become more difficult.
>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>> "Blocker" will delay a release candidate build.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Thanks,
>>> >>>>>>>>>>>> Jim
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> sure, thanks Jim!
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>> another week to work on a patch and we can update the status at the end of
>>> the week in order to decide if we can start the first build candidate
>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I'd like to backport
>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>> still time.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Regards,
>>> >>>>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> Hi Noble,
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>> noble.paul@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>> david.w.smiley@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>>> blocker) that I feel pretty good about.  This provides a key part of the
>>> nested document support.
>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week --
>>> SOLR-13129
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>> jan.asf@cominvent.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>> ooold bug.
>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>> feature in the UI and replace it with an error message popup or something.
>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>>> tomasflobbe@gmail.com>:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long
>>> as there is a reasonable time horizon for the issue being resolved I'm +1
>>> on making it a blocker. I'm not familiar enough with the UI code to help
>>> either unfortunately.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once
>>> before... And it's actually
>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>> a duplicate of an earlier issue (
>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>> question of whether or not overall quality has a bearing on the decision to
>>> release. As it turns out the screen shot I posted to the issue is less than
>>> half of the shards that eventually got created since there was an
>>> outstanding queue of requests still processing at the time. I'm now having
>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>> or less makes it impossible to recommend the use of the admin UI for
>>> anything other than read only observation of the cluster. Now imagine
>>> someone leaves a browser window open and forgets about it rather than
>>> browsing away or closing the window, not knowing that it's silently pumping
>>> out requests after showing an error... would completely hose a node, and
>>> until they tracked down the source of the requests, (hope he didn't go
>>> home) it would be impossible to resolve...
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>> jpountz@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
>>> own, I'd rather not
>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>> since this isn't a new
>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that
>>> has affected Solr
>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
>>> code at all, but
>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>> before we build a RC?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>> 8.0. I just got burned by it a second time.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>> guess as possible on the FOSDEM conference!
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on
>>> the week of February 4th.
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>> jim.ferenczi@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start
>>> on releasing 8.0. The branch is
>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>> anytime now. Unless there are
>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze
>>> next week in order to build the
>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we
>>> can handle both with Alan so
>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start
>>> the release process or if there
>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>> deprecations on the new master
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going
>>> to need some assistance for
>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>> what to do.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one
>>> for lucene and one for Solr,
>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be
>>> removed in each one.  I’ll create
>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and
>>> push the changes I’ve already
>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA
>>> issues for any changes that
>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>> particularly for the Solr deprecations
>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>> release at the same time as 8.0, to
>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>>> let’s keep those jobs enabled
>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>>> Jenkins once I have some time
>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x?
>>> Should we stop using it
>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>> branch_7_6 only for bugfixes), or
>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In
>>> the latter case I would keep
>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
>>> just created a branch for 8x
>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating
>>> the master branch to version
>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the
>>> 8.0 release should also be
>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as
>>> I know there are still some
>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>> should let us clean up master by
>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible,
>>> and give us an idea of any
>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>> david.w.smiley@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>> sg.online.email@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>> soon as there is an enhancement
>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
>>> hands on.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>>>  project in (SOLR, LUCENE) AND
>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>> fixVersion = "master (8.0)"
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work
>>> on those issues not yet
>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>>> jpountz@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>> Nick!) we should think about
>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>> 9.0.  I’ll volunteer to create the
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>> should have some time to
>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything
>>> that still needs to be done
>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next
>>> year.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <
>>> casstargett@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>>> Knize
>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36,
>>> jim ferenczi
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@gmail.com> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi Robert,
>>> >>>>>>>>>>>>>>
>>
>> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Jörn Franke <jo...@gmail.com>]

It would be also useful to include aspects of supported/semi-supported JDKs and versions as well as potentially OS specific issues. Finally a small sentence of migration needs would be useful.

Some of this information is available on the web site, but I do think that it make sense to refer/link to them in the release notes.

> Am 16.03.2019 um 04:35 schrieb David Smiley <da...@gmail.com>:
> 
> RE https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes
> 
> I'm not sure if it'd make that much difference but I'd like to move the release notes step down a little to follow the creation of the release branch since that's when the features are truly frozen.  Cool?
> 
> Jan: Yeah totally agree RE quality varies.  I think the release highlights is a fundamental editorial task requiring someone looking at the entirety of the issues, with plenty of judgement calls, to decide what's worth mentioning. That "releasedocmaker" tool looks cool for generating a CHANGELOG.md, but I don't think it'd be that great for the release highlights.  Well it might be okay but the results would simply be "a start" instead of starting with a blank slate each release.  Often times the biggest things that happen in a release are comprised of multiple issues, not one; yet "releasedocmaker" is a per-issue thing.
> 
> Even though the release announcement has been published, it's never too late to retroactively edit the information published to Solr's website!  To that end, I will edit the wiki version after sending this email to add an item about enhanced nested document support.  I think more should be said about HTTP/2 by someone following it closely, and in particular mention that work continues to 8.1 on it (and beyond?).  Please mention what value this brings.  These two items are the big ones IMO but others may have more to add.
> https://wiki.apache.org/solr/ReleaseNote80
> I will take care to re-publish it to the website next week.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Fri, Mar 15, 2019 at 4:20 AM Jan Høydahl <ja...@cominvent.com> wrote:
>> The varying quality of release notes has been a problem for a long time.
>> Sometimes random unimportant features are highlighted and the list gets way too long,
>> and this time it was way too short.
>> 
>> I think another alternative is to get some help from JIRA and Yetus here, by enabling the
>> "release notes" field in JIRA and start using https://yetus.apache.org/documentation/0.9.0/releasedocmaker/
>> 
>> Have not tried it but I think it is in use by other projects. There would of course need to be
>> some guidelines for when to use the field and not, but at least most of the work would
>> be done by developers when resolving an important JIRA, not by RM at release time.
>> 
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>> 
>>> 14. mar. 2019 kl. 18:44 skrev Adrien Grand <jp...@gmail.com>:
>>> 
>>> +1 David The highlights section is embarrassing indeed, we should call
>>> for action earlier in the future like the ReleaseTodo on the wiki
>>> suggests[1].
>>> I don't think it is not the only problem though. In the couple
>>> releases that I managed, I felt like the production of release notes
>>> was one the most unpleasant parts of the process due to the fact that
>>> not many people tend to help. It would be nice if we could figure out
>>> a way to encourage collaboration of more committers on the production
>>> of release notes. Or maybe we should stop doing this at release time,
>>> and use the same approach as MIGRATE.txt and ask contributors to
>>> document highlights at the same time as they push a change that is
>>> worth highlighting?
>>> 
>>> [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes
>>> 
>>> 
>>>> On Thu, Mar 14, 2019 at 2:34 PM David Smiley <da...@gmail.com> wrote:
>>>> 
>>>> The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
>>>> In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
>>>> That would not have been embarrassing.
>>>> Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
>>>> that is a juncture in which the features are frozen and there's plenty of time to update.
>>>> Last night I saw the call to action but it was woefully too late for me to help.
>>>> 
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>> 
>>>> 
>>>>> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>>>>> 
>>>>> I organized existing items of the Lucene release notes into sections
>>>>> and added a new item about FeatureField,
>>>>> LongPoint#newDistanceFeatureQuery and
>>>>> LatLonPoint#newDistanceFeatureQuery.
>>>>> 
>>>>>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> Jim and I have created wiki pages for the 8.0 release highlights here:
>>>>>> https://wiki.apache.org/solr/ReleaseNote80
>>>>>> https://wiki.apache.org/lucene-java/ReleaseNote80
>>>>>> 
>>>>>> Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
>>>>>> 
>>>>>> 
>>>>>> On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>>>>>> 
>>>>>> I'm committing them,
>>>>>> Thanks Ishan
>>>>>> 
>>>>>> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Awesome, thank you Ishan!
>>>>>> 
>>>>>> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>>>>>> 
>>>>>> Would anyone like to volunteer to be release manager for 7.7.1?
>>>>>> 
>>>>>> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>>>>>> 
>>>>>> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>>>>>> 
>>>>>> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>>>>>> 
>>>>>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>>>>>> 
>>>>>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> Thank you, Alan. Give me an hour.
>>>>>> 
>>>>>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>>>>>> 
>>>>>> 
>>>>>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>>>>> 
>>>>>> Mikhail, will you be able to get your fix in soon as well?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>>>> 
>>>>>> Hi Alan,
>>>>>> 
>>>>>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>>>>>> 
>>>>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi Shalin,
>>>>>> 
>>>>>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>>>>>> 
>>>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>>>> 
>>>>>> Hi Alan,
>>>>>> 
>>>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>>>>> 
>>>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>>>>> 
>>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>>>> 
>>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>>>> 
>>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>>>> 
>>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>>>>>> 
>>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>>>> 
>>>>>> Cassandra
>>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>>>>>> 
>>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>>> 
>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>>> 
>>>>>> 
>>>>>> On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>>>>>> 
>>>>>> Hey Alan,
>>>>>> 
>>>>>> I just committed a minor inconsequential bugfix
>>>>>> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>> realize I was cutting it so close to your work on cutting RC1, but
>>>>>> from commits I see you made this morning preparing for the RC I
>>>>>> suspect I cut things _very_ close and just missed it.
>>>>>> 
>>>>>> Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>> problems for you on the release end.  I'm happy to do whatever's
>>>>>> easiest for you regarding that commit.  It'd be nice to have it
>>>>>> included in 8.0, but it's not imperative by any means if I've already
>>>>>> missed the first RC, or it's easier for you to omit from potential
>>>>>> subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>> go back and update CHANGES.txt I think.
>>>>>> 
>>>>>> Sorry again for the potential complication.  I hate to be "that guy".
>>>>>> Thanks for stepping up and handling the release.
>>>>>> 
>>>>>> Best,
>>>>>> 
>>>>>> Jason
>>>>>> 
>>>>>> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>>> I'll be more careful next time ;).
>>>>>> 
>>>>>> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>>> 
>>>>>> Jim
>>>>>> 
>>>>>> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>>> 
>>>>>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>> 
>>>>>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>>> 
>>>>>> Cassandra
>>>>>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>>>>>> 
>>>>>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>>> 
>>>>>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>> 
>>>>>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>>>>>> 
>>>>>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>>> 
>>>>>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>>> 
>>>>>> 
>>>>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>>>>> 
>>>>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>>> There's a "master-deprecations" branch as well.
>>>>>> 
>>>>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>> 
>>>>>> ~ David
>>>>>> 
>>>>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>>> no issues so far.
>>>>>> 
>>>>>> Kevin Risden
>>>>>> 
>>>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>> 
>>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>>>> 
>>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>> 
>>>>>> - Nick
>>>>>> 
>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>> 
>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> Hey Jim,
>>>>>> 
>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>> 
>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>> 
>>>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>> 
>>>>>> 
>>>>>> Jim,
>>>>>> 
>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>> currently under review.
>>>>>> 
>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>> feel this should make it into 8.0 or not.
>>>>>> 
>>>>>> Kevin Risden
>>>>>> 
>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>> 
>>>>>> 
>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>> 
>>>>>> No new features may be committed to the branch.
>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>> 
>>>>>> 
>>>>>> Thanks,
>>>>>> Jim
>>>>>> 
>>>>>> 
>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> sure, thanks Jim!
>>>>>> 
>>>>>> Tommaso
>>>>>> 
>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>> <ji...@gmail.com> ha scritto:
>>>>>> 
>>>>>> 
>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>> early next week. Would that work for you ?
>>>>>> 
>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>> 
>>>>>> Regards,
>>>>>> Tommaso
>>>>>> 
>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>> <jp...@gmail.com> ha scritto:
>>>>>> 
>>>>>> 
>>>>>> Hi Noble,
>>>>>> 
>>>>>> No it hasn't created yet.
>>>>>> 
>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>> 
>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>> 
>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>> I'll try to take a look next week.
>>>>>> 
>>>>>> --
>>>>>> Jan Høydahl, search solution architect
>>>>>> Cominvent AS - www.cominvent.com
>>>>>> 
>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>>>> 
>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>> 
>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>> 
>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>>>> 
>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>> 
>>>>>> 
>>>>>> Cool,
>>>>>> 
>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>> 
>>>>>> Uwe
>>>>>> 
>>>>>> -----
>>>>>> Uwe Schindler
>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> http://www.thetaphi.de
>>>>>> eMail: uwe@thetaphi.de
>>>>>> 
>>>>>> -----Original Message-----
>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> 
>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>> 
>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi,
>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>> 
>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>> first candidate the week after.
>>>>>> 
>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>> 
>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>> are any blockers left ;).
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>>>> 
>>>>>> a écrit :
>>>>>> 
>>>>>> 
>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>> 
>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>> 
>>>>>> 
>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>> 
>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>> are more involved than just deleting code.
>>>>>> 
>>>>>> 
>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>> 
>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>> 
>>>>>> 
>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>> 
>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>> for now.
>>>>>> 
>>>>>> 
>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>> 
>>>>>> later today.
>>>>>> 
>>>>>> 
>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>> 
>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>> the jenkins jobs enabled for a while.
>>>>>> 
>>>>>> 
>>>>>> Uwe
>>>>>> 
>>>>>> -----
>>>>>> Uwe Schindler
>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> http://www.thetaphi.de
>>>>>> eMail: uwe@thetaphi.de
>>>>>> 
>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>> To: dev@lucene.apache.org
>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> 
>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>> 
>>>>>> from master, and am in the process of updating the master branch to version
>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>> back-ported to branch_8x from master.
>>>>>> 
>>>>>> 
>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>> 
>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>> replacement work that needs to be done.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> January.
>>>>>> 
>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>> 
>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>> 
>>>>>> Any idea when Solr 8 would be out ?
>>>>>> 
>>>>>> Thx
>>>>>> SG
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>> 
>>>>>> <da...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>> 
>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>> 
>>>>>> click here:
>>>>>> 
>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>> 
>>>>>> 
>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>> 
>>>>>> assigned.
>>>>>> 
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> +1
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>> 
>>>>>> <ro...@gmail.com> wrote:
>>>>>> 
>>>>>> 
>>>>>> Hi all,
>>>>>> 
>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>> 
>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>> on 8.0 before we start the release process next year.
>>>>>> 
>>>>>> 
>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>>>> 
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>> 
>>>>>> 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
>>>>>> 
>>>>>> <da...@gmail.com> a écrit :
>>>>>> 
>>>>>> 
>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>> 
>>>>>> <nk...@gmail.com> 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
>>>>>> 
>>>>>> <ca...@gmail.com> 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
>>>>>> 
>>>>>> <ji...@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
>>>>>> 
>>>>>> <ca...@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
>>>>>> 
>>>>>> <ji...@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
>>>>>> 
>>>>>> <ca...@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
>>>>>> 
>>>>>> <er...@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
>>>>>> 
>>>>>> <da...@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
>>>>>> 
>>>>>> <ji...@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%3DBlocke
>>>>>> r%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
>>>>>> 
>>>>>> <jp...@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
>>>>>> 
>>>>>> <jp...@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%3DBlocke
>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>> 
>>>>>> 
>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>> 
>>>>>> <ji...@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
>>>>>> 
>>>>>> <er...@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
>>>>>> 
>>>>>> <ca...@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
>>>>>> 
>>>>>> <ji...@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
>>>>>> 
>>>>>> <da...@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 --
>>>>>> 
>>>>>> &g
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> Sincerely yours
>>>>>> Mikhail Khludnev
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> --
>>>>>> -----------------------------------------------------
>>>>>> Noble Paul
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> --
>>>>> Adrien
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> 
>>> 
>>> 
>>> --
>>> Adrien
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
>> 

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

RE https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes

I'm not sure if it'd make that much difference but I'd like to move the
release notes step down a little to follow the creation of the release
branch since that's when the features are truly frozen.  Cool?

Jan: Yeah totally agree RE quality varies.  I think the release highlights
is a fundamental editorial task requiring someone looking at the entirety
of the issues, with plenty of judgement calls, to decide what's worth
mentioning. That "releasedocmaker" tool looks cool for generating a
CHANGELOG.md, but I don't think it'd be that great for the release
highlights.  Well it might be okay but the results would simply be "a
start" instead of starting with a blank slate each release.  Often times
the biggest things that happen in a release are comprised of multiple
issues, not one; yet "releasedocmaker" is a per-issue thing.

Even though the release announcement has been published, it's never too
late to retroactively edit the information published to Solr's website!  To
that end, I will edit the wiki version after sending this email to add an
item about enhanced nested document support.  I think more should be said
about HTTP/2 by someone following it closely, and in particular mention
that work continues to 8.1 on it (and beyond?).  Please mention what value
this brings.  These two items are the big ones IMO but others may have more
to add.
https://wiki.apache.org/solr/ReleaseNote80
I will take care to re-publish it to the website next week.
<https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes>
~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Fri, Mar 15, 2019 at 4:20 AM Jan Høydahl <ja...@cominvent.com> wrote:

> The varying quality of release notes has been a problem for a long time.
> Sometimes random unimportant features are highlighted and the list gets
> way too long,
> and this time it was way too short.
>
> I think another alternative is to get some help from JIRA and Yetus here,
> by enabling the
> "release notes" field in JIRA and start using
> https://yetus.apache.org/documentation/0.9.0/releasedocmaker/
>
> Have not tried it but I think it is in use by other projects. There would
> of course need to be
> some guidelines for when to use the field and not, but at least most of
> the work would
> be done by developers when resolving an important JIRA, not by RM at
> release time.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 14. mar. 2019 kl. 18:44 skrev Adrien Grand <jp...@gmail.com>:
>
> +1 David The highlights section is embarrassing indeed, we should call
> for action earlier in the future like the ReleaseTodo on the wiki
> suggests[1].
> I don't think it is not the only problem though. In the couple
> releases that I managed, I felt like the production of release notes
> was one the most unpleasant parts of the process due to the fact that
> not many people tend to help. It would be nice if we could figure out
> a way to encourage collaboration of more committers on the production
> of release notes. Or maybe we should stop doing this at release time,
> and use the same approach as MIGRATE.txt and ask contributors to
> document highlights at the same time as they push a change that is
> worth highlighting?
>
> [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes
>
>
> On Thu, Mar 14, 2019 at 2:34 PM David Smiley <da...@gmail.com>
> wrote:
>
>
> The Solr highlights section of the announcement is severely incomplete as
> to appear embarrassing.
> In the absence of time/effort to fix it should have simply been omitted;
> the CHANGES.txt has details.
> That would not have been embarrassing.
> Maybe next time we could have a call to action about the release
> highlights that coincides with the creation of the release branch;
> that is a juncture in which the features are frozen and there's plenty of
> time to update.
> Last night I saw the call to action but it was woefully too late for me to
> help.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>
>
> I organized existing items of the Lucene release notes into sections
> and added a new item about FeatureField,
> LongPoint#newDistanceFeatureQuery and
> LatLonPoint#newDistanceFeatureQuery.
>
> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> Jim and I have created wiki pages for the 8.0 release highlights here:
> https://wiki.apache.org/solr/ReleaseNote80
> https://wiki.apache.org/lucene-java/ReleaseNote80
>
> Feel free to edit and improve them - the Solr one in particular could do
> with some beefing up.
>
>
> On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>
> I'm committing them,
> Thanks Ishan
>
> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> Awesome, thank you Ishan!
>
> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com>
> wrote:
>
> Would anyone like to volunteer to be release manager for 7.7.1?
>
> I can volunteer for 7.7.1. I'll start as soon as both these issues are
> committed.
>
> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
>
> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally
> we would get this done quickly so that I can continue releasing 8.0.0.
>
> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>
> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>
>
> Thank you, Alan. Give me an hour.
>
> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>
>
> OK, let’s do an RC2.  When do you think you can have a fix in?
>
> Mikhail, will you be able to get your fix in soon as well?
>
>
>
> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>
>
>
> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
>
> Hi Alan,
>
> There is a work-around which is to change the default to using legacy
> assignment using cluster properties. But I don't like the idea of releasing
> something that we know is broken and asking everyone to set a cluster
> property to workaround it. I'd rather just rollback the commits that caused
> the problem and then release 8.0
>
> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> Hi Shalin,
>
> I'm not familiar with this bit of code - is there a workaround available?
>  ie a way of using a different replica placement strategy when creating a
> collection?  If there is, I'd be tempted to continue with the vote as is
> and then do an immediate 8.0.1 release once you have things fixed,
> particularly if we’re going to require a 7.7.1 as well.
>
> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
>
> Hi Alan,
>
> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
> interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
>
> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> The release candidate has already been built and voting is in progress, so
> it’s missed the boat unless there’s a respin.  It does look like a nasty
> bug though, so if you have a fix then feel free too commit it to the 8_0
> branch in case we do an 8.0.1 release.
>
> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>
> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>
> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>
> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>
> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to
> Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
> since there’s a lot of editing yet to be done for it.
>
> Cassandra
> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
> wrote:
>
> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129
> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include
> this even if it's committed after the 8.0 for the code?  I could avoid
> touching CHANGES.txt if that helps (it'd be of dubious value to users
> browsing the change list any way).
>
> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
> wrote:
>
>
> Thanks for letting me know Jason.  Your commit will have missed the cut,
> yes, but I don’t think it matters that much.  It will get picked up in a
> respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
>
>
> On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>
> Hey Alan,
>
> I just committed a minor inconsequential bugfix
> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> realize I was cutting it so close to your work on cutting RC1, but
> from commits I see you made this morning preparing for the RC I
> suspect I cut things _very_ close and just missed it.
>
> Hopefully my ill-timed commit to branch_8_0 doesn't create any
> problems for you on the release end.  I'm happy to do whatever's
> easiest for you regarding that commit.  It'd be nice to have it
> included in 8.0, but it's not imperative by any means if I've already
> missed the first RC, or it's easier for you to omit from potential
> subsequent RCs.  Let me know if there's anything you'd like me to do
> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> go back and update CHANGES.txt I think.
>
> Sorry again for the potential complication.  I hate to be "that guy".
> Thanks for stepping up and handling the release.
>
> Best,
>
> Jason
>
> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
> wrote:
>
>
> Thanks for fixing Cassandra and sorry for the noise. I did this too many
> times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> I'll be more careful next time ;).
>
> On another note, now that 7.7 is out and that we're preparing the release
> for 8.0 what do you think of removing/nuking the 7x branch. This was
> already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
>
> Jim
>
> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com>
> a écrit :
>
>
> I’d like to remind RMs that when finishing up a release, we can’t just do
> a blanket find/replace in .htaccess to update the version. If we’re not
> going to coordinate binary releases with Ref Guide releases, we need to be
> careful not to change the redirects unless that version’s Ref Guide release
> is also imminent.
>
> This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>
> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
> needs to maybe take care of it), but all non-version specific Ref Guide
> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
> we have an easy way to avoid routing people to dead links.
>
> Cassandra
> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
>
> Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
>
> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>
> It is a shame, I agree, but some of this stuff has been deprecated since
> 3.6, so another release cycle won’t hurt :). We should prioritise cleaning
> this stuff up once 8.0 is out of the door though.
>
> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>
> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle
> to remove things that have been deprecated in previous releases?
>  solr.LatLonType is one example.  It's a shame to keep around such things
> further.
>
> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>
>
> Not quite - the plan is to remove things entirely in 9.0, but we may need
> to back port some extra deprecations to 8x.  We don’t necessarily need them
> in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
>
>
> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>
> I want to ensure people are aware of two issues "Remove deprecated code in
> master" that Alan filed:
>
> https://issues.apache.org/jira/browse/SOLR-13138
> https://issues.apache.org/jira/browse/LUCENE-8638
> There's a "master-deprecations" branch as well.
>
> Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
>
> ~ David
>
> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>
>
> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> I'm keeping any eye on the builds this weekend but all indications are
> no issues so far.
>
> Kevin Risden
>
> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>
>
> Nick, this change seems to be causing test failures. Can you have a look?
>
> See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>
> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>
>
> Thank you Jim. LUCENE-8669 has been merged.
>
> - Nick
>
> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
> wrote:
>
>
> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
> first RC when your patch is merged.
> Kevin, this looks like a big change so I am not sure if it's a good idea
> to rush this in for 8.0. Would it be safer to target another version in
> order to take some time to ensure that it's not breaking anything ? I guess
> that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
>
> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>
>
> Hey Jim,
>
> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with
> a pretty straightforward patch. This is a critical one that I think needs
> to be in for 7.7 and 8.0. Can I set this as a blocker?
>
> On Wed, Jan 30, 2019 at 1:07 PM
>
> Kevin Risden <kr...@apache.org> wrote:
>
>
> Jim,
>
> Since 7.7 needs to be released before 8.0 does that leave time to get
> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> currently under review.
>
> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> feel this should make it into 8.0 or not.
>
> Kevin Risden
>
> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
> wrote:
>
>
> I had to revert the version bump for 8.0 (8.1) on branch_8x because we
> don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> Since we want to release 7.7 first I created the Jenkins job for this
> version only and will build the first candidate for this version later this
> week if there are no objection.
> I'll restore the version bump for 8.0 when 7.7 is out.
>
>
> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
> écrit :
>
>
> Hi,
> Hearing no objection I created the branches for 8.0 and 7.7. I'll now
> create the Jenkins tasks for these versions, Uwe can you also add them to
> the Policeman's Jenkins job ?
> This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
>
> No new features may be committed to the branch.
> Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> All patches that are intended for the branch should first be committed to
> the unstable branch, merged into the stable branch, and then into the
> current release branch.
> Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch while
> the branch feature freeze is in effect, think twice: can't the addition
> wait a couple more days? Merges of bug fixes into the branch may become
> more difficult.
> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay
> a release candidate build.
>
>
> Thanks,
> Jim
>
>
> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com>
> a écrit :
>
>
> sure, thanks Jim!
>
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> <ji...@gmail.com> ha scritto:
>
>
> Go ahead Tommaso the branch is not created yet.
> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
> and to announce the feature freeze the same day.
> For blocker issues that are still open this leaves another week to work on
> a patch and we can update the status at the end of the week in order to
> decide if we can start the first build candidate
> early next week. Would that work for you ?
>
> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com>
> a écrit :
>
>
> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>
> Regards,
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> <jp...@gmail.com> ha scritto:
>
>
> Hi Noble,
>
> No it hasn't created yet.
>
> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com>
> wrote:
>
>
> I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> I will work on some documentation for it this week -- SOLR-13129
>
> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>
>
> I don't think it is critical for this to be a blocker for 8.0. If it gets
> fixed in 8.0.1 that's ok too, given this is an ooold bug.
> I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> I'll try to take a look next week.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com
> >:
>
> I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
>
> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>
>
> It looks like someone tried to make it a blocker once before... And it's
> actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
>
> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>
>
> Releasing a new major is very challenging on its own, I'd rather not
> call it a blocker and delay the release for it since this isn't a new
> regression in 8.0: it looks like a problem that has affected Solr
> since at least 6.3? I'm not familiar with the UI code at all, but
> maybe this is something that could get fixed before we build a RC?
>
>
>
>
> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>
>
> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211
> be promoted to block 8.0. I just got burned by it a second time.
>
> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>
>
> Cool,
>
> I am working on giving my best release time guess as possible on the
> FOSDEM conference!
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> -----Original Message-----
> From: Adrien Grand <jp...@gmail.com>
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev <de...@lucene.apache.org>
> Subject: Re: Lucene/Solr 8.0
>
> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>
> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> wrote:
>
>
> Hi,
> As we agreed some time ago I'd like to start on releasing 8.0. The branch
> is
>
> already created so we can start the process anytime now. Unless there are
> objections I'd like to start the feature freeze next week in order to
> build the
> first candidate the week after.
>
> We'll also need a 7.7 release but I think we can handle both with Alan so
>
> the question now is whether we are ok to start the release process or if
> there
> are any blockers left ;).
>
>
>
> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>
> a écrit :
>
>
> I’ve started to work through the various deprecations on the new master
>
> branch.  There are a lot of them, and I’m going to need some assistance for
> several of them, as it’s not entirely clear what to do.
>
>
> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>
> with lists of the deprecations that need to be removed in each one.  I’ll
> create
> a shared branch on gitbox to work against, and push the changes I’ve
> already
> done there.  We can then create individual JIRA issues for any changes that
> are more involved than just deleting code.
>
>
> All assistance gratefully received, particularly for the Solr deprecations
>
> where there’s a lot of code I’m unfamiliar with.
>
>
> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>
> wrote:
>
>
> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>
> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> for now.
>
>
> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi,
>
> I will start and add the branch_8x jobs to Jenkins once I have some time
>
> later today.
>
>
> The question: How to proceed with branch_7x? Should we stop using it
>
> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> are we planning to one more Lucene/Solr 7.7? In the latter case I would
> keep
> the jenkins jobs enabled for a while.
>
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Alan Woodward <ro...@gmail.com>
> Sent: Monday, January 7, 2019 11:30 AM
> To: dev@lucene.apache.org
> Subject: Re: Lucene/Solr 8.0
>
> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>
> from master, and am in the process of updating the master branch to version
> 9.  New commits that should be included in the 8.0 release should also be
> back-ported to branch_8x from master.
>
>
> This is not intended as a feature freeze, as I know there are still some
>
> things being worked on for 8.0; however, it should let us clean up master
> by
> removing as much deprecated code as possible, and give us an idea of any
> replacement work that needs to be done.
>
>
>
> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>
> wrote:
>
>
> January.
>
> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>
> wrote:
>
>
> It would be nice to see Solr 8 in January soon as there is an enhancement
>
> on nested-documents we are waiting to get our hands on.
>
> Any idea when Solr 8 would be out ?
>
> Thx
> SG
>
> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>
> <da...@gmail.com> wrote:
>
>
> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>
> priority = Blocker and status = open and fixVersion = "master (8.0)"
>
> click here:
>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>
>
> Thru the end of the month, I intend to work on those issues not yet
>
> assigned.
>
>
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>
> wrote:
>
>
> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>
> <ro...@gmail.com> wrote:
>
>
> Hi all,
>
> Now that 7.6 is out of the door (thanks Nick!) we should think about
>
> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create
> the
> branch this week - say Wednesday?  Then we should have some time to
> clean up the master branch and uncover anything that still needs to be done
> on 8.0 before we start the release process next year.
>
>
> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>
> wrote:
>
>
> 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
>
> <er...@gmail.com> 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 <ji...@gmail.com>
>
> 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
>
> <da...@gmail.com> a écrit :
>
>
> +1 to a 7.6 —lots of stuff in there
> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>
> <nk...@gmail.com> 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
>
> <ca...@gmail.com> 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
>
> <ji...@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
>
> <ca...@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
>
> <ji...@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
>
> <ca...@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
>
> <er...@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
>
> <da...@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
>
> <ji...@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%3DBlocke
> r%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
>
> <jp...@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
>
> <jp...@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%3DBlocke
> r%20and%20resolution%20%3D%20Unresolved%20
>
>
> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>
> <ji...@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
>
> <er...@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
>
> <ca...@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
>
> <ji...@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
>
> <da...@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 --
>
> &g
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> <de...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org
> <de...@lucene.apache.org>
>
>
>

Re: Lucene/Solr 8.0

[Jan Høydahl <ja...@cominvent.com>]

The varying quality of release notes has been a problem for a long time.
Sometimes random unimportant features are highlighted and the list gets way too long,
and this time it was way too short.

I think another alternative is to get some help from JIRA and Yetus here, by enabling the
"release notes" field in JIRA and start using https://yetus.apache.org/documentation/0.9.0/releasedocmaker/

Have not tried it but I think it is in use by other projects. There would of course need to be
some guidelines for when to use the field and not, but at least most of the work would
be done by developers when resolving an important JIRA, not by RM at release time.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 14. mar. 2019 kl. 18:44 skrev Adrien Grand <jp...@gmail.com>:
> 
> +1 David The highlights section is embarrassing indeed, we should call
> for action earlier in the future like the ReleaseTodo on the wiki
> suggests[1].
> I don't think it is not the only problem though. In the couple
> releases that I managed, I felt like the production of release notes
> was one the most unpleasant parts of the process due to the fact that
> not many people tend to help. It would be nice if we could figure out
> a way to encourage collaboration of more committers on the production
> of release notes. Or maybe we should stop doing this at release time,
> and use the same approach as MIGRATE.txt and ask contributors to
> document highlights at the same time as they push a change that is
> worth highlighting?
> 
> [1] https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes
> 
> 
> On Thu, Mar 14, 2019 at 2:34 PM David Smiley <da...@gmail.com> wrote:
>> 
>> The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
>> In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
>> That would not have been embarrassing.
>> Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
>> that is a juncture in which the features are frozen and there's plenty of time to update.
>> Last night I saw the call to action but it was woefully too late for me to help.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>>> 
>>> I organized existing items of the Lucene release notes into sections
>>> and added a new item about FeatureField,
>>> LongPoint#newDistanceFeatureQuery and
>>> LatLonPoint#newDistanceFeatureQuery.
>>> 
>>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> Jim and I have created wiki pages for the 8.0 release highlights here:
>>>> https://wiki.apache.org/solr/ReleaseNote80
>>>> https://wiki.apache.org/lucene-java/ReleaseNote80
>>>> 
>>>> Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
>>>> 
>>>> 
>>>> On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>>>> 
>>>> I'm committing them,
>>>> Thanks Ishan
>>>> 
>>>> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Awesome, thank you Ishan!
>>>> 
>>>> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>>>> 
>>>> Would anyone like to volunteer to be release manager for 7.7.1?
>>>> 
>>>> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>>>> 
>>>> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>>>> 
>>>> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>>>> 
>>>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>>>> 
>>>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>>>> 
>>>> 
>>>> Thank you, Alan. Give me an hour.
>>>> 
>>>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>>>> 
>>>> 
>>>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>>> 
>>>> Mikhail, will you be able to get your fix in soon as well?
>>>> 
>>>> 
>>>> 
>>>> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>>>> 
>>>> 
>>>> 
>>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>> 
>>>> Hi Alan,
>>>> 
>>>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>>>> 
>>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Hi Shalin,
>>>> 
>>>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>>>> 
>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>> 
>>>> Hi Alan,
>>>> 
>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>>> 
>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>>> 
>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>> 
>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>> 
>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>> 
>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>>>> 
>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>> 
>>>> Cassandra
>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>>>> 
>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>> 
>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>> 
>>>> 
>>>> On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>>>> 
>>>> Hey Alan,
>>>> 
>>>> I just committed a minor inconsequential bugfix
>>>> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>> realize I was cutting it so close to your work on cutting RC1, but
>>>> from commits I see you made this morning preparing for the RC I
>>>> suspect I cut things _very_ close and just missed it.
>>>> 
>>>> Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>> problems for you on the release end.  I'm happy to do whatever's
>>>> easiest for you regarding that commit.  It'd be nice to have it
>>>> included in 8.0, but it's not imperative by any means if I've already
>>>> missed the first RC, or it's easier for you to omit from potential
>>>> subsequent RCs.  Let me know if there's anything you'd like me to do
>>>> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>> go back and update CHANGES.txt I think.
>>>> 
>>>> Sorry again for the potential complication.  I hate to be "that guy".
>>>> Thanks for stepping up and handling the release.
>>>> 
>>>> Best,
>>>> 
>>>> Jason
>>>> 
>>>> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>> I'll be more careful next time ;).
>>>> 
>>>> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>> 
>>>> Jim
>>>> 
>>>> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>> 
>>>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>> 
>>>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>> 
>>>> Cassandra
>>>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>>>> 
>>>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>> 
>>>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>> 
>>>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>>>> 
>>>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>> 
>>>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>> 
>>>> 
>>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>>> 
>>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>> 
>>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>> There's a "master-deprecations" branch as well.
>>>> 
>>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>> 
>>>> ~ David
>>>> 
>>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>> 
>>>> 
>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>> no issues so far.
>>>> 
>>>> Kevin Risden
>>>> 
>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>> 
>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>> 
>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>> 
>>>> - Nick
>>>> 
>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>> 
>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> Hey Jim,
>>>> 
>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>> 
>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>> 
>>>> Kevin Risden <kr...@apache.org> wrote:
>>>> 
>>>> 
>>>> Jim,
>>>> 
>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>> currently under review.
>>>> 
>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>> feel this should make it into 8.0 or not.
>>>> 
>>>> Kevin Risden
>>>> 
>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>> 
>>>> 
>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>> 
>>>> 
>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> Hi,
>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>> 
>>>> No new features may be committed to the branch.
>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>> 
>>>> 
>>>> Thanks,
>>>> Jim
>>>> 
>>>> 
>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> sure, thanks Jim!
>>>> 
>>>> Tommaso
>>>> 
>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>> <ji...@gmail.com> ha scritto:
>>>> 
>>>> 
>>>> Go ahead Tommaso the branch is not created yet.
>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>> early next week. Would that work for you ?
>>>> 
>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>> 
>>>> Regards,
>>>> Tommaso
>>>> 
>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>> <jp...@gmail.com> ha scritto:
>>>> 
>>>> 
>>>> Hi Noble,
>>>> 
>>>> No it hasn't created yet.
>>>> 
>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Is the branch already cut for 8.0? which is it?
>>>> 
>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>> 
>>>> 
>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>> I will work on some documentation for it this week -- SOLR-13129
>>>> 
>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>> 
>>>> 
>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>> I'll try to take a look next week.
>>>> 
>>>> --
>>>> Jan Høydahl, search solution architect
>>>> Cominvent AS - www.cominvent.com
>>>> 
>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>> 
>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>> 
>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>> 
>>>> 
>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>> 
>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>> call it a blocker and delay the release for it since this isn't a new
>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>> maybe this is something that could get fixed before we build a RC?
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>> 
>>>> 
>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>> 
>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> 
>>>> 
>>>> Cool,
>>>> 
>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>> 
>>>> Uwe
>>>> 
>>>> -----
>>>> Uwe Schindler
>>>> Achterdiek 19, D-28357 Bremen
>>>> http://www.thetaphi.de
>>>> eMail: uwe@thetaphi.de
>>>> 
>>>> -----Original Message-----
>>>> From: Adrien Grand <jp...@gmail.com>
>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>> Subject: Re: Lucene/Solr 8.0
>>>> 
>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>> 
>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>> wrote:
>>>> 
>>>> 
>>>> Hi,
>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>> 
>>>> already created so we can start the process anytime now. Unless there are
>>>> objections I'd like to start the feature freeze next week in order to build the
>>>> first candidate the week after.
>>>> 
>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>> 
>>>> the question now is whether we are ok to start the release process or if there
>>>> are any blockers left ;).
>>>> 
>>>> 
>>>> 
>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>> 
>>>> a écrit :
>>>> 
>>>> 
>>>> I’ve started to work through the various deprecations on the new master
>>>> 
>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>> several of them, as it’s not entirely clear what to do.
>>>> 
>>>> 
>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>> 
>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>> done there.  We can then create individual JIRA issues for any changes that
>>>> are more involved than just deleting code.
>>>> 
>>>> 
>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>> 
>>>> where there’s a lot of code I’m unfamiliar with.
>>>> 
>>>> 
>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>> 
>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>> for now.
>>>> 
>>>> 
>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>> 
>>>> later today.
>>>> 
>>>> 
>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>> 
>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>> the jenkins jobs enabled for a while.
>>>> 
>>>> 
>>>> Uwe
>>>> 
>>>> -----
>>>> Uwe Schindler
>>>> Achterdiek 19, D-28357 Bremen
>>>> http://www.thetaphi.de
>>>> eMail: uwe@thetaphi.de
>>>> 
>>>> From: Alan Woodward <ro...@gmail.com>
>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>> To: dev@lucene.apache.org
>>>> Subject: Re: Lucene/Solr 8.0
>>>> 
>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>> 
>>>> from master, and am in the process of updating the master branch to version
>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>> back-ported to branch_8x from master.
>>>> 
>>>> 
>>>> This is not intended as a feature freeze, as I know there are still some
>>>> 
>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>> removing as much deprecated code as possible, and give us an idea of any
>>>> replacement work that needs to be done.
>>>> 
>>>> 
>>>> 
>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> January.
>>>> 
>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>> 
>>>> on nested-documents we are waiting to get our hands on.
>>>> 
>>>> Any idea when Solr 8 would be out ?
>>>> 
>>>> Thx
>>>> SG
>>>> 
>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> 
>>>> <da...@gmail.com> wrote:
>>>> 
>>>> 
>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>> 
>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>> 
>>>> click here:
>>>> 
>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> 
>>>> 
>>>> Thru the end of the month, I intend to work on those issues not yet
>>>> 
>>>> assigned.
>>>> 
>>>> 
>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> +1
>>>> 
>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>> 
>>>> <ro...@gmail.com> wrote:
>>>> 
>>>> 
>>>> Hi all,
>>>> 
>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>> 
>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>> branch this week - say Wednesday?  Then we should have some time to
>>>> clean up the master branch and uncover anything that still needs to be done
>>>> on 8.0 before we start the release process next year.
>>>> 
>>>> 
>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>> 
>>>> wrote:
>>>> 
>>>> 
>>>> 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
>>>> 
>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>> 
>>>> 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
>>>> 
>>>> <da...@gmail.com> a écrit :
>>>> 
>>>> 
>>>> +1 to a 7.6 —lots of stuff in there
>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>> 
>>>> <nk...@gmail.com> 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
>>>> 
>>>> <ca...@gmail.com> 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
>>>> 
>>>> <ji...@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
>>>> 
>>>> <ca...@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
>>>> 
>>>> <ji...@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
>>>> 
>>>> <ca...@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
>>>> 
>>>> <er...@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
>>>> 
>>>> <da...@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
>>>> 
>>>> <ji...@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%3DBlocke
>>>> r%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
>>>> 
>>>> <jp...@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
>>>> 
>>>> <jp...@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%3DBlocke
>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>> 
>>>> 
>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>> 
>>>> <ji...@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
>>>> 
>>>> <er...@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
>>>> 
>>>> <ca...@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
>>>> 
>>>> <ji...@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
>>>> 
>>>> <da...@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 --
>>>> 
>>>> &g
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Sincerely yours
>>>> Mikhail Khludnev
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> -----------------------------------------------------
>>>> Noble Paul
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> Adrien
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> 
> 
> 
> --
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

+1 David The highlights section is embarrassing indeed, we should call
for action earlier in the future like the ReleaseTodo on the wiki
suggests[1].
I don't think it is not the only problem though. In the couple
releases that I managed, I felt like the production of release notes
was one the most unpleasant parts of the process due to the fact that
not many people tend to help. It would be nice if we could figure out
a way to encourage collaboration of more committers on the production
of release notes. Or maybe we should stop doing this at release time,
and use the same approach as MIGRATE.txt and ask contributors to
document highlights at the same time as they push a change that is
worth highlighting?

[1] https://wiki.apache.org/lucene-java/ReleaseTodo#Produce_Release_Notes


On Thu, Mar 14, 2019 at 2:34 PM David Smiley <da...@gmail.com> wrote:
>
> The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> That would not have been embarrassing.
> Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> that is a juncture in which the features are frozen and there's plenty of time to update.
> Last night I saw the call to action but it was woefully too late for me to help.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>>
>> I organized existing items of the Lucene release notes into sections
>> and added a new item about FeatureField,
>> LongPoint#newDistanceFeatureQuery and
>> LatLonPoint#newDistanceFeatureQuery.
>>
>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > Jim and I have created wiki pages for the 8.0 release highlights here:
>> > https://wiki.apache.org/solr/ReleaseNote80
>> > https://wiki.apache.org/lucene-java/ReleaseNote80
>> >
>> > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
>> >
>> >
>> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>> >
>> > I'm committing them,
>> > Thanks Ishan
>> >
>> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Awesome, thank you Ishan!
>> >
>> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?
>> >
>> > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>> >
>> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>> >
>> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> >
>> > Thank you, Alan. Give me an hour.
>> >
>> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>> >
>> >
>> > OK, let’s do an RC2.  When do you think you can have a fix in?
>> >
>> > Mikhail, will you be able to get your fix in soon as well?
>> >
>> >
>> >
>> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>> >
>> >
>> >
>> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>> >
>> > Hi Alan,
>> >
>> > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>> >
>> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Hi Shalin,
>> >
>> > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>> >
>> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>> >
>> > Hi Alan,
>> >
>> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>> >
>> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>> >
>> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>> >
>> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>> >
>> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>> >
>> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>> >
>> > Cassandra
>> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>> >
>> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>> >
>> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>> >
>> >
>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>> >
>> > Hey Alan,
>> >
>> > I just committed a minor inconsequential bugfix
>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>> > realize I was cutting it so close to your work on cutting RC1, but
>> > from commits I see you made this morning preparing for the RC I
>> > suspect I cut things _very_ close and just missed it.
>> >
>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>> > problems for you on the release end.  I'm happy to do whatever's
>> > easiest for you regarding that commit.  It'd be nice to have it
>> > included in 8.0, but it's not imperative by any means if I've already
>> > missed the first RC, or it's easier for you to omit from potential
>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>> > go back and update CHANGES.txt I think.
>> >
>> > Sorry again for the potential complication.  I hate to be "that guy".
>> > Thanks for stepping up and handling the release.
>> >
>> > Best,
>> >
>> > Jason
>> >
>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>> > I'll be more careful next time ;).
>> >
>> > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>> >
>> > Jim
>> >
>> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>> >
>> >
>> > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>> >
>> > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>> >
>> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>> >
>> > Cassandra
>> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>> >
>> > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>> >
>> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>> >
>> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>> >
>> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>> >
>> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>> >
>> >
>> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>> >
>> > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>> >
>> > https://issues.apache.org/jira/browse/SOLR-13138
>> > https://issues.apache.org/jira/browse/LUCENE-8638
>> > There's a "master-deprecations" branch as well.
>> >
>> > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>> >
>> > ~ David
>> >
>> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> > I'm keeping any eye on the builds this weekend but all indications are
>> > no issues so far.
>> >
>> > Kevin Risden
>> >
>> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Nick, this change seems to be causing test failures. Can you have a look?
>> >
>> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>> >
>> >
>> > Thank you Jim. LUCENE-8669 has been merged.
>> >
>> > - Nick
>> >
>> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>> > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>> >
>> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>> >
>> >
>> > Hey Jim,
>> >
>> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> >
>> > On Wed, Jan 30, 2019 at 1:07 PM
>> >
>> > Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > Jim,
>> >
>> > Since 7.7 needs to be released before 8.0 does that leave time to get
>> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> > currently under review.
>> >
>> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> > feel this should make it into 8.0 or not.
>> >
>> > Kevin Risden
>> >
>> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> >
>> >
>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>> >
>> >
>> > Hi,
>> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>> > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>> >
>> > No new features may be committed to the branch.
>> > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>> > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>> > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>> >
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>> >
>> >
>> > sure, thanks Jim!
>> >
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > <ji...@gmail.com> ha scritto:
>> >
>> >
>> > Go ahead Tommaso the branch is not created yet.
>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>> > early next week. Would that work for you ?
>> >
>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>> >
>> >
>> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >
>> > Regards,
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > <jp...@gmail.com> ha scritto:
>> >
>> >
>> > Hi Noble,
>> >
>> > No it hasn't created yet.
>> >
>> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>> >
>> >
>> > Is the branch already cut for 8.0? which is it?
>> >
>> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>> >
>> >
>> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>> > I will work on some documentation for it this week -- SOLR-13129
>> >
>> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>> >
>> >
>> > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> > I'll try to take a look next week.
>> >
>> > --
>> > Jan Høydahl, search solution architect
>> > Cominvent AS - www.cominvent.com
>> >
>> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>> >
>> > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>> >
>> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>> >
>> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Releasing a new major is very challenging on its own, I'd rather not
>> > call it a blocker and delay the release for it since this isn't a new
>> > regression in 8.0: it looks like a problem that has affected Solr
>> > since at least 6.3? I'm not familiar with the UI code at all, but
>> > maybe this is something that could get fixed before we build a RC?
>> >
>> >
>> >
>> >
>> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>> >
>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> >
>> > Cool,
>> >
>> > I am working on giving my best release time guess as possible on the FOSDEM conference!
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > -----Original Message-----
>> > From: Adrien Grand <jp...@gmail.com>
>> > Sent: Thursday, January 24, 2019 5:33 PM
>> > To: Lucene Dev <de...@lucene.apache.org>
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> >
>> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>> > wrote:
>> >
>> >
>> > Hi,
>> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> >
>> > already created so we can start the process anytime now. Unless there are
>> > objections I'd like to start the feature freeze next week in order to build the
>> > first candidate the week after.
>> >
>> > We'll also need a 7.7 release but I think we can handle both with Alan so
>> >
>> > the question now is whether we are ok to start the release process or if there
>> > are any blockers left ;).
>> >
>> >
>> >
>> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>> >
>> > a écrit :
>> >
>> >
>> > I’ve started to work through the various deprecations on the new master
>> >
>> > branch.  There are a lot of them, and I’m going to need some assistance for
>> > several of them, as it’s not entirely clear what to do.
>> >
>> >
>> > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> >
>> > with lists of the deprecations that need to be removed in each one.  I’ll create
>> > a shared branch on gitbox to work against, and push the changes I’ve already
>> > done there.  We can then create individual JIRA issues for any changes that
>> > are more involved than just deleting code.
>> >
>> >
>> > All assistance gratefully received, particularly for the Solr deprecations
>> >
>> > where there’s a lot of code I’m unfamiliar with.
>> >
>> >
>> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> >
>> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> > for now.
>> >
>> >
>> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > I will start and add the branch_8x jobs to Jenkins once I have some time
>> >
>> > later today.
>> >
>> >
>> > The question: How to proceed with branch_7x? Should we stop using it
>> >
>> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> > the jenkins jobs enabled for a while.
>> >
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > From: Alan Woodward <ro...@gmail.com>
>> > Sent: Monday, January 7, 2019 11:30 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> >
>> > from master, and am in the process of updating the master branch to version
>> > 9.  New commits that should be included in the 8.0 release should also be
>> > back-ported to branch_8x from master.
>> >
>> >
>> > This is not intended as a feature freeze, as I know there are still some
>> >
>> > things being worked on for 8.0; however, it should let us clean up master by
>> > removing as much deprecated code as possible, and give us an idea of any
>> > replacement work that needs to be done.
>> >
>> >
>> >
>> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > January.
>> >
>> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > It would be nice to see Solr 8 in January soon as there is an enhancement
>> >
>> > on nested-documents we are waiting to get our hands on.
>> >
>> > Any idea when Solr 8 would be out ?
>> >
>> > Thx
>> > SG
>> >
>> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >
>> > <da...@gmail.com> wrote:
>> >
>> >
>> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> >
>> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> >
>> >  click here:
>> >
>> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >
>> >
>> > Thru the end of the month, I intend to work on those issues not yet
>> >
>> > assigned.
>> >
>> >
>> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > +1
>> >
>> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >
>> > <ro...@gmail.com> wrote:
>> >
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> >
>> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> > branch this week - say Wednesday?  Then we should have some time to
>> > clean up the master branch and uncover anything that still needs to be done
>> > on 8.0 before we start the release process next year.
>> >
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > 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
>> >
>> > <er...@gmail.com> 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 <ji...@gmail.com>
>> >
>> > 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
>> >
>> > <da...@gmail.com> a écrit :
>> >
>> >
>> > +1 to a 7.6 —lots of stuff in there
>> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >
>> > <nk...@gmail.com> 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
>> >
>> > <ca...@gmail.com> 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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <er...@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
>> >
>> > <da...@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
>> >
>> > <ji...@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%3DBlocke
>> > r%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
>> >
>> > <jp...@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
>> >
>> > <jp...@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%3DBlocke
>> > r%20and%20resolution%20%3D%20Unresolved%20
>> >
>> >
>> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> >
>> > <ji...@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
>> >
>> > <er...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <da...@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 --
>> >
>> > &g
>> >
>> >
>> >
>> >
>> > --
>> > Sincerely yours
>> > Mikhail Khludnev
>> >
>> >
>> >
>> >
>> >
>> > --
>> > -----------------------------------------------------
>> > Noble Paul
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>


--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Fwd: Lucene/Solr 8.0

[Kevin Risden <kr...@apache.org>]

The docker hub stuff took a while since Solr 8 should have made it simpler
but didn't completely. Some of the details are here:

https://github.com/docker-solr/docker-solr/issues/196

It looks like the README or Description didn't get updated even though the
latest version is correct:

https://hub.docker.com/_/solr

Kevin Risden


On Fri, May 3, 2019 at 2:06 AM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> Hi Jason,
> I now see docker hub synced up and is finally serving 8.0.0. This
> happened, as per docker hub, "3 days ago".
> Not sure why this delay (perhaps due to the security breach at docker
> hub?).
> Thanks for looking into this.
> Regards,
> Ishan
>
> On Fri, May 3, 2019 at 4:22 AM Jason Gerlowski <ge...@gmail.com>
> wrote:
> >
> > Are you sure Ishan?  I just did a "docker pull solr" and it looks like
> > I'm getting 8.0.  Here's what I tried: https://pastebin.com/uPwCammc
> >
> > From the commit history here, maybe this is a recent change though?
> > https://github.com/docker-solr/docker-solr
> >
> > Anyway, if you retry and still see 7.7.1, let me know and we can
> > figure things out from there.
> >
> > On Thu, May 2, 2019 at 5:05 PM Ishan Chattopadhyaya
> > <ic...@gmail.com> wrote:
> > >
> > > What should be done to get 8.0 version added to Docker Hub [0]?
> > > Would this need to be done by Martijn Koster at Lucidworks? If so, can
> > > someone please request him to take a look?
> > > Or is this something that even we (@ Apache) can do too?
> > >
> > > [0] - https://hub.docker.com/_/solr/
> > >
> > > On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
> > > <ic...@gmail.com> wrote:
> > > >
> > > > On a different note, I realized 2 days back that the solr:latest on
> > > > docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> > > > image on docker hub?
> > > >
> > > > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <
> casstargett@gmail.com> wrote:
> > > > >
> > > > > I have a number of changes in a local branch for the 8.0 Ref Guide
> page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t
> intended to push my branch, but I could if it helps. I also have a bunch of
> unfinished content I started about nested documents, but tearing apart the
> CHANGES.txt to figure out what is new and how that impacts upgrades is
> incredibly painful and time-consuming, and I don’t have a ton of time these
> days. This is why the 8.0 Ref Guide isn’t out yet.
> > > > >
> > > > > Tangentially, I feel like we need to work something else out about
> Wiki release notes (and, remember, wiki.apache.org is going away really
> soon now) and the Ref Guide. It’s odd to me that one person decides how to
> present what’s new in the Wiki release notes, and someone else decides how
> to present a whole other set of content about the same set of features for
> the Ref Guide. Usually I skip the what’s new part for the minor releases,
> but for major ones, there needs to be a comprehensive “here’s what’s new
> and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the
> major version process now.
> > > > >
> > > > > Anyway, let me know if you want to see what I have so far, and
> I’ll try to find some time to push it or make a patch.
> > > > > On Apr 30, 2019, 8:00 AM -0500, David Smiley <
> david.w.smiley@gmail.com>, wrote:
> > > > >
> > > > > Hi Dat,
> > > > >
> > > > > I plan to update Solr's release notes for 8.0 retroactively.
> https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs;
> I wrote this well over a month ago.  Can you please enhance the part on
> HTTP2 to be more informative?  For example... what *benefit* does HTTP2
> bring to internode communication?  I know you benchmarked things.  Maybe
> mention the road to full HTTP2 continues into 8.x?
> > > > >
> > > > > I'm sending this to the dev list so really anyone else can help
> like list other major features... though I think maybe it's just these two.
> > > > >
> > > > > ~ David Smiley
> > > > > Apache Lucene/Solr Search Developer
> > > > > http://www.linkedin.com/in/davidwsmiley
> > > > >
> > > > > ---------- Forwarded message ---------
> > > > > From: David Smiley <da...@gmail.com>
> > > > > Date: Thu, Mar 14, 2019 at 9:34 AM
> > > > > Subject: Re: Lucene/Solr 8.0
> > > > > To: Solr/Lucene Dev <de...@lucene.apache.org>
> > > > >
> > > > >
> > > > > The Solr highlights section of the announcement is severely
> incomplete as to appear embarrassing.
> > > > > In the absence of time/effort to fix it should have simply been
> omitted; the CHANGES.txt has details.
> > > > > That would not have been embarrassing.
> > > > > Maybe next time we could have a call to action about the release
> highlights that coincides with the creation of the release branch;
> > > > > that is a juncture in which the features are frozen and there's
> plenty of time to update.
> > > > > Last night I saw the call to action but it was woefully too late
> for me to help.
> > > > >
> > > > > ~ David Smiley
> > > > > Apache Lucene/Solr Search Developer
> > > > > http://www.linkedin.com/in/davidwsmiley
> > > > >
> > > > >
> > > > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com>
> wrote:
> > > > >>
> > > > >> I organized existing items of the Lucene release notes into
> sections
> > > > >> and added a new item about FeatureField,
> > > > >> LongPoint#newDistanceFeatureQuery and
> > > > >> LatLonPoint#newDistanceFeatureQuery.
> > > > >>
> > > > >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> > Jim and I have created wiki pages for the 8.0 release
> highlights here:
> > > > >> > https://wiki.apache.org/solr/ReleaseNote80
> > > > >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> > > > >> >
> > > > >> > Feel free to edit and improve them - the Solr one in particular
> could do with some beefing up.
> > > > >> >
> > > > >> >
> > > > >> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com>
> wrote:
> > > > >> >
> > > > >> > I'm committing them,
> > > > >> > Thanks Ishan
> > > > >> >
> > > > >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Awesome, thank you Ishan!
> > > > >> >
> > > > >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> > > > >> >
> > > > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> > > > >> >
> > > > >> > I can volunteer for 7.7.1. I'll start as soon as both these
> issues are committed.
> > > > >> >
> > > > >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > We have two Solr issues that are serious enough to warrant a
> 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our
> backwards-compatibility guarantees, we should do this release before we
> restart the 8.0.0 process.
> > > > >> >
> > > > >> > Would anyone like to volunteer to be release manager for
> 7.7.1?  Ideally we would get this done quickly so that I can continue
> releasing 8.0.0.
> > > > >> >
> > > > >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org>
> wrote:
> > > > >> >
> > > > >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <
> mkhl@apache.org> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Thank you, Alan. Give me an hour.
> > > > >> >
> > > > >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > > > >> >
> > > > >> >
> > > > >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> > > > >> >
> > > > >> > Mikhail, will you be able to get your fix in soon as well?
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Nope. Don't wait for SOLR-13126, it turns to be more
> complicated.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > > > >> >
> > > > >> > Hi Alan,
> > > > >> >
> > > > >> > There is a work-around which is to change the default to using
> legacy assignment using cluster properties. But I don't like the idea of
> releasing something that we know is broken and asking everyone to set a
> cluster property to workaround it. I'd rather just rollback the commits
> that caused the problem and then release 8.0
> > > > >> >
> > > > >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Hi Shalin,
> > > > >> >
> > > > >> > I'm not familiar with this bit of code - is there a workaround
> available?  ie a way of using a different replica placement strategy when
> creating a collection?  If there is, I'd be tempted to continue with the
> vote as is and then do an immediate 8.0.1 release once you have things
> fixed, particularly if we’re going to require a 7.7.1 as well.
> > > > >> >
> > > > >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > > > >> >
> > > > >> > Hi Alan,
> > > > >> >
> > > > >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that
> should be a blocker for 8.0 and might require a bug fix 7.7.1 release as
> well. In the interest of time, I propose rolling back SOLR-12739 which
> caused these issues. We can re-introduce it with proper fixes for the
> related issues in 8.1.
> > > > >> >
> > > > >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > The release candidate has already been built and voting is in
> progress, so it’s missed the boat unless there’s a respin.  It does look
> like a nasty bug though, so if you have a fix then feel free too commit it
> to the 8_0 branch in case we do an 8.0.1 release.
> > > > >> >
> > > > >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org>
> wrote:
> > > > >> >
> > > > >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for
> 8_0 ?
> > > > >> >
> > > > >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I have no problem with bug-fixes and ref-guide changes on the
> 8_0 branch.
> > > > >> >
> > > > >> > On 13 Feb 2019, at 22:25, Cassandra Targett <
> casstargett@gmail.com> wrote:
> > > > >> >
> > > > >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is
> closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref
> Guide at all since there’s a lot of editing yet to be done for it.
> > > > >> >
> > > > >> > Cassandra
> > > > >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <
> david.w.smiley@gmail.com>, wrote:
> > > > >> >
> > > > >> > I've been shepherding
> https://issues.apache.org/jira/browse/SOLR-13129 which only touches the
> Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's
> committed after the 8.0 for the code?  I could avoid touching CHANGES.txt
> if that helps (it'd be of dubious value to users browsing the change list
> any way).
> > > > >> >
> > > > >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Thanks for letting me know Jason.  Your commit will have missed
> the cut, yes, but I don’t think it matters that much.  It will get picked
> up in a respin or in any subsequent bug-fix release, and if RC1 passes the
> vote then we can just alter CHANGES.txt
> > > > >> >
> > > > >> >
> > > > >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <
> gerlowskija@gmail.com> wrote:
> > > > >> >
> > > > >> > Hey Alan,
> > > > >> >
> > > > >> > I just committed a minor inconsequential bugfix
> > > > >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I
> didn't
> > > > >> > realize I was cutting it so close to your work on cutting RC1,
> but
> > > > >> > from commits I see you made this morning preparing for the RC I
> > > > >> > suspect I cut things _very_ close and just missed it.
> > > > >> >
> > > > >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > > > >> > problems for you on the release end.  I'm happy to do whatever's
> > > > >> > easiest for you regarding that commit.  It'd be nice to have it
> > > > >> > included in 8.0, but it's not imperative by any means if I've
> already
> > > > >> > missed the first RC, or it's easier for you to omit from
> potential
> > > > >> > subsequent RCs.  Let me know if there's anything you'd like me
> to do
> > > > >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll
> need to
> > > > >> > go back and update CHANGES.txt I think.
> > > > >> >
> > > > >> > Sorry again for the potential complication.  I hate to be "that
> guy".
> > > > >> > Thanks for stepping up and handling the release.
> > > > >> >
> > > > >> > Best,
> > > > >> >
> > > > >> > Jason
> > > > >> >
> > > > >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Thanks for fixing Cassandra and sorry for the noise. I did this
> too many times in the past so I just mechanically changed the redirect
> without thinking of when or if the ref guide was also released.
> > > > >> > I'll be more careful next time ;).
> > > > >> >
> > > > >> > On another note, now that 7.7 is out and that we're preparing
> the release for 8.0 what do you think of removing/nuking the 7x branch.
> This was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> > > > >> >
> > > > >> > Jim
> > > > >> >
> > > > >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
> casstargett@gmail.com> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > I’d like to remind RMs that when finishing up a release, we
> can’t just do a blanket find/replace in .htaccess to update the version. If
> we’re not going to coordinate binary releases with Ref Guide releases, we
> need to be careful not to change the redirects unless that version’s Ref
> Guide release is also imminent.
> > > > >> >
> > > > >> > This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > > > >> >
> > > > >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide
> so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
> else needs to maybe take care of it), but all non-version specific Ref
> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
> fix, but we have an easy way to avoid routing people to dead links.
> > > > >> >
> > > > >> > Cassandra
> > > > >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <
> romseygeek@gmail.com>, wrote:
> > > > >> >
> > > > >> > Once 7.7 is out the door, we should get on with releasing 8.0.
> I volunteer to be the manager for this round.  My current plan is to build
> a release candidate early next week, as soon as the 7.7 release has been
> announced.
> > > > >> >
> > > > >> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
> wrote:
> > > > >> >
> > > > >> > It is a shame, I agree, but some of this stuff has been
> deprecated since 3.6, so another release cycle won’t hurt :). We should
> prioritise cleaning this stuff up once 8.0 is out of the door though.
> > > > >> >
> > > > >> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
> wrote:
> > > > >> >
> > > > >> > Okay.  I suppose the issue is that it's simply too late in the
> 8.0 cycle to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> > > > >> >
> > > > >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Not quite - the plan is to remove things entirely in 9.0, but
> we may need to back port some extra deprecations to 8x.  We don’t
> necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in
> 9 without any problems.  I opened the issues to ensure that we didn’t keep
> carrying deprecated code through any further releases.
> > > > >> >
> > > > >> >
> > > > >> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
> wrote:
> > > > >> >
> > > > >> > I want to ensure people are aware of two issues "Remove
> deprecated code in master" that Alan filed:
> > > > >> >
> > > > >> > https://issues.apache.org/jira/browse/SOLR-13138
> > > > >> > https://issues.apache.org/jira/browse/LUCENE-8638
> > > > >> > There's a "master-deprecations" branch as well.
> > > > >> >
> > > > >> > Although both issues are marked "master (9.0)", I think the
> intent is actually 8.0 so that we are finally rid of the deprecated code?
> > > > >> >
> > > > >> > ~ David
> > > > >> >
> > > > >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
> 8.0.
> > > > >> > I'm keeping any eye on the builds this weekend but all
> indications are
> > > > >> > no issues so far.
> > > > >> >
> > > > >> > Kevin Risden
> > > > >> >
> > > > >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Nick, this change seems to be causing test failures. Can you
> have a look?
> > > > >> >
> > > > >> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > > > >> >
> > > > >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <
> nknize@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Thank you Jim. LUCENE-8669 has been merged.
> > > > >> >
> > > > >> > - Nick
> > > > >> >
> > > > >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll
> start the first RC when your patch is merged.
> > > > >> > Kevin, this looks like a big change so I am not sure if it's a
> good idea to rush this in for 8.0. Would it be safer to target another
> version in order to take some time to ensure that it's not breaking
> anything ? I guess that your concern is that a change like this should
> happen in a major version but I wonder if it's worth the risk. I don't know
> this part of the code and the implications of such a change so I let you
> decide what we should do here but let's not delay the release if we realize
> that this change requires more than a few days to be merged.
> > > > >> >
> > > > >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com>
> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > Hey Jim,
> > > > >> >
> > > > >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669
> along with a pretty straightforward patch. This is a critical one that I
> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > > > >> >
> > > > >> > On Wed, Jan 30, 2019 at 1:07 PM
> > > > >> >
> > > > >> > Kevin Risden <kr...@apache.org> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Jim,
> > > > >> >
> > > > >> > Since 7.7 needs to be released before 8.0 does that leave time
> to get
> > > > >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and
> it is
> > > > >> > currently under review.
> > > > >> >
> > > > >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
> others
> > > > >> > feel this should make it into 8.0 or not.
> > > > >> >
> > > > >> > Kevin Risden
> > > > >> >
> > > > >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I had to revert the version bump for 8.0 (8.1) on branch_8x
> because we don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > > > >> > Since we want to release 7.7 first I created the Jenkins job
> for this version only and will build the first candidate for this version
> later this week if there are no objection.
> > > > >> > I'll restore the version bump for 8.0 when 7.7 is out.
> > > > >> >
> > > > >> >
> > > > >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
> jim.ferenczi@gmail.com> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > Hi,
> > > > >> > Hearing no objection I created the branches for 8.0 and 7.7.
> I'll now create the Jenkins tasks for these versions, Uwe can you also add
> them to the Policeman's Jenkins job ?
> > > > >> > This also means that the feature freeze phase has started for
> both versions (7.7 and 8.0):
> > > > >> >
> > > > >> > No new features may be committed to the branch.
> > > > >> > Documentation patches, build patches and serious bug fixes may
> be committed to the branch. However, you should submit all patches you want
> to commit to Jira first to give others the chance to review and possibly
> vote against the patch. Keep in mind that it is our main intention to keep
> the branch as stable as possible.
> > > > >> > All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> > > > >> > Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> > > > >> > Only Jira issues with Fix version "X.Y" and priority "Blocker"
> will delay a release candidate build.
> > > > >> >
> > > > >> >
> > > > >> > Thanks,
> > > > >> > Jim
> > > > >> >
> > > > >> >
> > > > >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > sure, thanks Jim!
> > > > >> >
> > > > >> > Tommaso
> > > > >> >
> > > > >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > > > >> > <ji...@gmail.com> ha scritto:
> > > > >> >
> > > > >> >
> > > > >> > Go ahead Tommaso the branch is not created yet.
> > > > >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
> wednesday and to announce the feature freeze the same day.
> > > > >> > For blocker issues that are still open this leaves another week
> to work on a patch and we can update the status at the end of the week in
> order to decide if we can start the first build candidate
> > > > >> > early next week. Would that work for you ?
> > > > >> >
> > > > >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> > > > >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > > > >> >
> > > > >> > Regards,
> > > > >> > Tommaso
> > > > >> >
> > > > >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > > > >> > <jp...@gmail.com> ha scritto:
> > > > >> >
> > > > >> >
> > > > >> > Hi Noble,
> > > > >> >
> > > > >> > No it hasn't created yet.
> > > > >> >
> > > > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
> noble.paul@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Is the branch already cut for 8.0? which is it?
> > > > >> >
> > > > >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > > > >> > I will work on some documentation for it this week -- SOLR-13129
> > > > >> >
> > > > >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
> jan.asf@cominvent.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I don't think it is critical for this to be a blocker for 8.0.
> If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > > >> > I think we should simply remove the buffering feature in the UI
> and replace it with an error message popup or something.
> > > > >> > I'll try to take a look next week.
> > > > >> >
> > > > >> > --
> > > > >> > Jan Høydahl, search solution architect
> > > > >> > Cominvent AS - www.cominvent.com
> > > > >> >
> > > > >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> > > > >> >
> > > > >> > I think the UI is an important Solr feature. As long as there
> is a reasonable time horizon for the issue being resolved I'm +1 on making
> it a blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> > > > >> >
> > > > >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > It looks like someone tried to make it a blocker once before...
> And it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> > > > >> >
> > > > >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Releasing a new major is very challenging on its own, I'd
> rather not
> > > > >> > call it a blocker and delay the release for it since this isn't
> a new
> > > > >> > regression in 8.0: it looks like a problem that has affected
> Solr
> > > > >> > since at least 6.3? I'm not familiar with the UI code at all,
> but
> > > > >> > maybe this is something that could get fixed before we build a
> RC?
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > > > >> >
> > > > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Cool,
> > > > >> >
> > > > >> > I am working on giving my best release time guess as possible
> on the FOSDEM conference!
> > > > >> >
> > > > >> > Uwe
> > > > >> >
> > > > >> > -----
> > > > >> > Uwe Schindler
> > > > >> > Achterdiek 19, D-28357 Bremen
> > > > >> > http://www.thetaphi.de
> > > > >> > eMail: uwe@thetaphi.de
> > > > >> >
> > > > >> > -----Original Message-----
> > > > >> > From: Adrien Grand <jp...@gmail.com>
> > > > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > > > >> > To: Lucene Dev <de...@lucene.apache.org>
> > > > >> > Subject: Re: Lucene/Solr 8.0
> > > > >> >
> > > > >> > +1 to release 7.7 and 8.0 in a row starting on the week of
> February 4th.
> > > > >> >
> > > > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > Hi,
> > > > >> > As we agreed some time ago I'd like to start on releasing 8.0.
> The branch is
> > > > >> >
> > > > >> > already created so we can start the process anytime now. Unless
> there are
> > > > >> > objections I'd like to start the feature freeze next week in
> order to build the
> > > > >> > first candidate the week after.
> > > > >> >
> > > > >> > We'll also need a 7.7 release but I think we can handle both
> with Alan so
> > > > >> >
> > > > >> > the question now is whether we are ok to start the release
> process or if there
> > > > >> > are any blockers left ;).
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
> romseygeek@gmail.com>
> > > > >> >
> > > > >> > a écrit :
> > > > >> >
> > > > >> >
> > > > >> > I’ve started to work through the various deprecations on the
> new master
> > > > >> >
> > > > >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> > > > >> > several of them, as it’s not entirely clear what to do.
> > > > >> >
> > > > >> >
> > > > >> > I’ll open two overarching issues in JIRA, one for lucene and
> one for Solr,
> > > > >> >
> > > > >> > with lists of the deprecations that need to be removed in each
> one.  I’ll create
> > > > >> > a shared branch on gitbox to work against, and push the changes
> I’ve already
> > > > >> > done there.  We can then create individual JIRA issues for any
> changes that
> > > > >> > are more involved than just deleting code.
> > > > >> >
> > > > >> >
> > > > >> > All assistance gratefully received, particularly for the Solr
> deprecations
> > > > >> >
> > > > >> > where there’s a lot of code I’m unfamiliar with.
> > > > >> >
> > > > >> >
> > > > >> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > I think the current plan is to do a 7.7 release at the same
> time as 8.0, to
> > > > >> >
> > > > >> > handle any last-minute deprecations etc.  So let’s keep those
> jobs enabled
> > > > >> > for now.
> > > > >> >
> > > > >> >
> > > > >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > > > >> >
> > > > >> > Hi,
> > > > >> >
> > > > >> > I will start and add the branch_8x jobs to Jenkins once I have
> some time
> > > > >> >
> > > > >> > later today.
> > > > >> >
> > > > >> >
> > > > >> > The question: How to proceed with branch_7x? Should we stop
> using it
> > > > >> >
> > > > >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> > > > >> > are we planning to one more Lucene/Solr 7.7? In the latter case
> I would keep
> > > > >> > the jenkins jobs enabled for a while.
> > > > >> >
> > > > >> >
> > > > >> > Uwe
> > > > >> >
> > > > >> > -----
> > > > >> > Uwe Schindler
> > > > >> > Achterdiek 19, D-28357 Bremen
> > > > >> > http://www.thetaphi.de
> > > > >> > eMail: uwe@thetaphi.de
> > > > >> >
> > > > >> > From: Alan Woodward <ro...@gmail.com>
> > > > >> > Sent: Monday, January 7, 2019 11:30 AM
> > > > >> > To: dev@lucene.apache.org
> > > > >> > Subject: Re: Lucene/Solr 8.0
> > > > >> >
> > > > >> > OK, Christmas caught up with me a bit… I’ve just created a
> branch for 8x
> > > > >> >
> > > > >> > from master, and am in the process of updating the master
> branch to version
> > > > >> > 9.  New commits that should be included in the 8.0 release
> should also be
> > > > >> > back-ported to branch_8x from master.
> > > > >> >
> > > > >> >
> > > > >> > This is not intended as a feature freeze, as I know there are
> still some
> > > > >> >
> > > > >> > things being worked on for 8.0; however, it should let us clean
> up master by
> > > > >> > removing as much deprecated code as possible, and give us an
> idea of any
> > > > >> > replacement work that needs to be done.
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > January.
> > > > >> >
> > > > >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > It would be nice to see Solr 8 in January soon as there is an
> enhancement
> > > > >> >
> > > > >> > on nested-documents we are waiting to get our hands on.
> > > > >> >
> > > > >> > Any idea when Solr 8 would be out ?
> > > > >> >
> > > > >> > Thx
> > > > >> > SG
> > > > >> >
> > > > >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > > >> >
> > > > >> > <da...@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > I see 10 JIRA issues matching this filter:   project in (SOLR,
> LUCENE) AND
> > > > >> >
> > > > >> > priority = Blocker and status = open and fixVersion = "master
> (8.0)"
> > > > >> >
> > > > >> >  click here:
> > > > >> >
> > > > >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > > >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > > >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > > >> >
> > > > >> >
> > > > >> > Thru the end of the month, I intend to work on those issues not
> yet
> > > > >> >
> > > > >> > assigned.
> > > > >> >
> > > > >> >
> > > > >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com
> >
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > +1
> > > > >> >
> > > > >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > > >> >
> > > > >> > <ro...@gmail.com> wrote:
> > > > >> >
> > > > >> >
> > > > >> > Hi all,
> > > > >> >
> > > > >> > Now that 7.6 is out of the door (thanks Nick!) we should think
> about
> > > > >> >
> > > > >> > cutting the 8.0 branch and moving master to 9.0.  I’ll
> volunteer to create the
> > > > >> > branch this week - say Wednesday?  Then we should have some
> time to
> > > > >> > clean up the master branch and uncover anything that still
> needs to be done
> > > > >> > on 8.0 before we start the release process next year.
> > > > >> >
> > > > >> >
> > > > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> > > > >> >
> > > > >> > wrote:
> > > > >> >
> > > > >> >
> > > > >> > 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
> > > > >> >
> > > > >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> > > > >> >
> > > > >> > 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
> > > > >> >
> > > > >> > <da...@gmail.com> a écrit :
> > > > >> >
> > > > >> >
> > > > >> > +1 to a 7.6 —lots of stuff in there
> > > > >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > > >> >
> > > > >> > <nk...@gmail.com> 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
> > > > >> >
> > > > >> > <ca...@gmail.com> 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
> > > > >> >
> > > > >> > <ji...@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
> > > > >> >
> > > > >> > <ca...@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
> > > > >> >
> > > > >> > <ji...@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
> > > > >> >
> > > > >> > <ca...@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
> > > > >> >
> > > > >> > <er...@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
> > > > >> >
> > > > >> > <da...@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
> > > > >> >
> > > > >> > <ji...@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%3DBlocke
> > > > >> > r%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
> > > > >> >
> > > > >> > <jp...@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
> > > > >> >
> > > > >> > <jp...@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%3DBlocke
> > > > >> > r%20and%20resolution%20%3D%20Unresolved%20
> > > > >> >
> > > > >> >
> > > > >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > > > >> >
> > > > >> > <ji...@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
> > > > >> >
> > > > >> > <er...@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
> > > > >> >
> > > > >> > <ca...@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
> > > > >> >
> > > > >> > <ji...@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
> > > > >> >
> > > > >> > <da...@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 --
> > > > >> >
> > > > >> > &g
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > Sincerely yours
> > > > >> > Mikhail Khludnev
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> >
> > > > >> > --
> > > > >> > -----------------------------------------------------
> > > > >> > Noble Paul
> > > > >> >
> > > > >> >
> ---------------------------------------------------------------------
> > > > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >> >
> > > > >> >
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Adrien
> > > > >>
> > > > >>
> ---------------------------------------------------------------------
> > > > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >>
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Fwd: Lucene/Solr 8.0

[Ishan Chattopadhyaya <ic...@gmail.com>]

Hi Jason,
I now see docker hub synced up and is finally serving 8.0.0. This
happened, as per docker hub, "3 days ago".
Not sure why this delay (perhaps due to the security breach at docker hub?).
Thanks for looking into this.
Regards,
Ishan

On Fri, May 3, 2019 at 4:22 AM Jason Gerlowski <ge...@gmail.com> wrote:
>
> Are you sure Ishan?  I just did a "docker pull solr" and it looks like
> I'm getting 8.0.  Here's what I tried: https://pastebin.com/uPwCammc
>
> From the commit history here, maybe this is a recent change though?
> https://github.com/docker-solr/docker-solr
>
> Anyway, if you retry and still see 7.7.1, let me know and we can
> figure things out from there.
>
> On Thu, May 2, 2019 at 5:05 PM Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> >
> > What should be done to get 8.0 version added to Docker Hub [0]?
> > Would this need to be done by Martijn Koster at Lucidworks? If so, can
> > someone please request him to take a look?
> > Or is this something that even we (@ Apache) can do too?
> >
> > [0] - https://hub.docker.com/_/solr/
> >
> > On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
> > <ic...@gmail.com> wrote:
> > >
> > > On a different note, I realized 2 days back that the solr:latest on
> > > docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> > > image on docker hub?
> > >
> > > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <ca...@gmail.com> wrote:
> > > >
> > > > I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
> > > >
> > > > Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now.
> > > >
> > > > Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch.
> > > > On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>, wrote:
> > > >
> > > > Hi Dat,
> > > >
> > > > I plan to update Solr's release notes for 8.0 retroactively.   https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I wrote this well over a month ago.  Can you please enhance the part on HTTP2 to be more informative?  For example... what *benefit* does HTTP2 bring to internode communication?  I know you benchmarked things.  Maybe mention the road to full HTTP2 continues into 8.x?
> > > >
> > > > I'm sending this to the dev list so really anyone else can help like list other major features... though I think maybe it's just these two.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > > >
> > > > ---------- Forwarded message ---------
> > > > From: David Smiley <da...@gmail.com>
> > > > Date: Thu, Mar 14, 2019 at 9:34 AM
> > > > Subject: Re: Lucene/Solr 8.0
> > > > To: Solr/Lucene Dev <de...@lucene.apache.org>
> > > >
> > > >
> > > > The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> > > > In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> > > > That would not have been embarrassing.
> > > > Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> > > > that is a juncture in which the features are frozen and there's plenty of time to update.
> > > > Last night I saw the call to action but it was woefully too late for me to help.
> > > >
> > > > ~ David Smiley
> > > > Apache Lucene/Solr Search Developer
> > > > http://www.linkedin.com/in/davidwsmiley
> > > >
> > > >
> > > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
> > > >>
> > > >> I organized existing items of the Lucene release notes into sections
> > > >> and added a new item about FeatureField,
> > > >> LongPoint#newDistanceFeatureQuery and
> > > >> LatLonPoint#newDistanceFeatureQuery.
> > > >>
> > > >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> > Jim and I have created wiki pages for the 8.0 release highlights here:
> > > >> > https://wiki.apache.org/solr/ReleaseNote80
> > > >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> > > >> >
> > > >> > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
> > > >> >
> > > >> >
> > > >> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> > > >> >
> > > >> > I'm committing them,
> > > >> > Thanks Ishan
> > > >> >
> > > >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Awesome, thank you Ishan!
> > > >> >
> > > >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> > > >> >
> > > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> > > >> >
> > > >> > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
> > > >> >
> > > >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
> > > >> >
> > > >> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
> > > >> >
> > > >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> > > >> >
> > > >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
> > > >> >
> > > >> >
> > > >> > Thank you, Alan. Give me an hour.
> > > >> >
> > > >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > > >> >
> > > >> >
> > > >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> > > >> >
> > > >> > Mikhail, will you be able to get your fix in soon as well?
> > > >> >
> > > >> >
> > > >> >
> > > >> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > > >> >
> > > >> > Hi Alan,
> > > >> >
> > > >> > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> > > >> >
> > > >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Hi Shalin,
> > > >> >
> > > >> > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> > > >> >
> > > >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > > >> >
> > > >> > Hi Alan,
> > > >> >
> > > >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
> > > >> >
> > > >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
> > > >> >
> > > >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> > > >> >
> > > >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> > > >> >
> > > >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> > > >> >
> > > >> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
> > > >> >
> > > >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
> > > >> >
> > > >> > Cassandra
> > > >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
> > > >> >
> > > >> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
> > > >> >
> > > >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
> > > >> >
> > > >> >
> > > >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> > > >> >
> > > >> > Hey Alan,
> > > >> >
> > > >> > I just committed a minor inconsequential bugfix
> > > >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > > >> > realize I was cutting it so close to your work on cutting RC1, but
> > > >> > from commits I see you made this morning preparing for the RC I
> > > >> > suspect I cut things _very_ close and just missed it.
> > > >> >
> > > >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > > >> > problems for you on the release end.  I'm happy to do whatever's
> > > >> > easiest for you regarding that commit.  It'd be nice to have it
> > > >> > included in 8.0, but it's not imperative by any means if I've already
> > > >> > missed the first RC, or it's easier for you to omit from potential
> > > >> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > > >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > > >> > go back and update CHANGES.txt I think.
> > > >> >
> > > >> > Sorry again for the potential complication.  I hate to be "that guy".
> > > >> > Thanks for stepping up and handling the release.
> > > >> >
> > > >> > Best,
> > > >> >
> > > >> > Jason
> > > >> >
> > > >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> > > >> > I'll be more careful next time ;).
> > > >> >
> > > >> > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
> > > >> >
> > > >> > Jim
> > > >> >
> > > >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
> > > >> >
> > > >> > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > > >> >
> > > >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
> > > >> >
> > > >> > Cassandra
> > > >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> > > >> >
> > > >> > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
> > > >> >
> > > >> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> > > >> >
> > > >> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> > > >> >
> > > >> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> > > >> >
> > > >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> > > >> >
> > > >> >
> > > >> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> > > >> >
> > > >> > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> > > >> >
> > > >> > https://issues.apache.org/jira/browse/SOLR-13138
> > > >> > https://issues.apache.org/jira/browse/LUCENE-8638
> > > >> > There's a "master-deprecations" branch as well.
> > > >> >
> > > >> > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> > > >> >
> > > >> > ~ David
> > > >> >
> > > >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> > > >> >
> > > >> >
> > > >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > > >> > I'm keeping any eye on the builds this weekend but all indications are
> > > >> > no issues so far.
> > > >> >
> > > >> > Kevin Risden
> > > >> >
> > > >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Nick, this change seems to be causing test failures. Can you have a look?
> > > >> >
> > > >> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > > >> >
> > > >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Thank you Jim. LUCENE-8669 has been merged.
> > > >> >
> > > >> > - Nick
> > > >> >
> > > >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > > >> > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > > >> >
> > > >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > Hey Jim,
> > > >> >
> > > >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > > >> >
> > > >> > On Wed, Jan 30, 2019 at 1:07 PM
> > > >> >
> > > >> > Kevin Risden <kr...@apache.org> wrote:
> > > >> >
> > > >> >
> > > >> > Jim,
> > > >> >
> > > >> > Since 7.7 needs to be released before 8.0 does that leave time to get
> > > >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > > >> > currently under review.
> > > >> >
> > > >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > > >> > feel this should make it into 8.0 or not.
> > > >> >
> > > >> > Kevin Risden
> > > >> >
> > > >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> > > >> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > > >> > I'll restore the version bump for 8.0 when 7.7 is out.
> > > >> >
> > > >> >
> > > >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > Hi,
> > > >> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > > >> > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > > >> >
> > > >> > No new features may be committed to the branch.
> > > >> > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > > >> > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > > >> > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > > >> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > > >> >
> > > >> >
> > > >> > Thanks,
> > > >> > Jim
> > > >> >
> > > >> >
> > > >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > sure, thanks Jim!
> > > >> >
> > > >> > Tommaso
> > > >> >
> > > >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > > >> > <ji...@gmail.com> ha scritto:
> > > >> >
> > > >> >
> > > >> > Go ahead Tommaso the branch is not created yet.
> > > >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > > >> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > > >> > early next week. Would that work for you ?
> > > >> >
> > > >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > > >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > > >> >
> > > >> > Regards,
> > > >> > Tommaso
> > > >> >
> > > >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > > >> > <jp...@gmail.com> ha scritto:
> > > >> >
> > > >> >
> > > >> > Hi Noble,
> > > >> >
> > > >> > No it hasn't created yet.
> > > >> >
> > > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Is the branch already cut for 8.0? which is it?
> > > >> >
> > > >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > > >> > I will work on some documentation for it this week -- SOLR-13129
> > > >> >
> > > >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > > >> >
> > > >> >
> > > >> > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > >> > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > > >> > I'll try to take a look next week.
> > > >> >
> > > >> > --
> > > >> > Jan Høydahl, search solution architect
> > > >> > Cominvent AS - www.cominvent.com
> > > >> >
> > > >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > > >> >
> > > >> > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > > >> >
> > > >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > > >> >
> > > >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Releasing a new major is very challenging on its own, I'd rather not
> > > >> > call it a blocker and delay the release for it since this isn't a new
> > > >> > regression in 8.0: it looks like a problem that has affected Solr
> > > >> > since at least 6.3? I'm not familiar with the UI code at all, but
> > > >> > maybe this is something that could get fixed before we build a RC?
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > > >> >
> > > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > > >> >
> > > >> >
> > > >> > Cool,
> > > >> >
> > > >> > I am working on giving my best release time guess as possible on the FOSDEM conference!
> > > >> >
> > > >> > Uwe
> > > >> >
> > > >> > -----
> > > >> > Uwe Schindler
> > > >> > Achterdiek 19, D-28357 Bremen
> > > >> > http://www.thetaphi.de
> > > >> > eMail: uwe@thetaphi.de
> > > >> >
> > > >> > -----Original Message-----
> > > >> > From: Adrien Grand <jp...@gmail.com>
> > > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > > >> > To: Lucene Dev <de...@lucene.apache.org>
> > > >> > Subject: Re: Lucene/Solr 8.0
> > > >> >
> > > >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > > >> >
> > > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > Hi,
> > > >> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > > >> >
> > > >> > already created so we can start the process anytime now. Unless there are
> > > >> > objections I'd like to start the feature freeze next week in order to build the
> > > >> > first candidate the week after.
> > > >> >
> > > >> > We'll also need a 7.7 release but I think we can handle both with Alan so
> > > >> >
> > > >> > the question now is whether we are ok to start the release process or if there
> > > >> > are any blockers left ;).
> > > >> >
> > > >> >
> > > >> >
> > > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > > >> >
> > > >> > a écrit :
> > > >> >
> > > >> >
> > > >> > I’ve started to work through the various deprecations on the new master
> > > >> >
> > > >> > branch.  There are a lot of them, and I’m going to need some assistance for
> > > >> > several of them, as it’s not entirely clear what to do.
> > > >> >
> > > >> >
> > > >> > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > > >> >
> > > >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> > > >> > a shared branch on gitbox to work against, and push the changes I’ve already
> > > >> > done there.  We can then create individual JIRA issues for any changes that
> > > >> > are more involved than just deleting code.
> > > >> >
> > > >> >
> > > >> > All assistance gratefully received, particularly for the Solr deprecations
> > > >> >
> > > >> > where there’s a lot of code I’m unfamiliar with.
> > > >> >
> > > >> >
> > > >> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > > >> >
> > > >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > > >> > for now.
> > > >> >
> > > >> >
> > > >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > > >> >
> > > >> > Hi,
> > > >> >
> > > >> > I will start and add the branch_8x jobs to Jenkins once I have some time
> > > >> >
> > > >> > later today.
> > > >> >
> > > >> >
> > > >> > The question: How to proceed with branch_7x? Should we stop using it
> > > >> >
> > > >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > > >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > > >> > the jenkins jobs enabled for a while.
> > > >> >
> > > >> >
> > > >> > Uwe
> > > >> >
> > > >> > -----
> > > >> > Uwe Schindler
> > > >> > Achterdiek 19, D-28357 Bremen
> > > >> > http://www.thetaphi.de
> > > >> > eMail: uwe@thetaphi.de
> > > >> >
> > > >> > From: Alan Woodward <ro...@gmail.com>
> > > >> > Sent: Monday, January 7, 2019 11:30 AM
> > > >> > To: dev@lucene.apache.org
> > > >> > Subject: Re: Lucene/Solr 8.0
> > > >> >
> > > >> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > > >> >
> > > >> > from master, and am in the process of updating the master branch to version
> > > >> > 9.  New commits that should be included in the 8.0 release should also be
> > > >> > back-ported to branch_8x from master.
> > > >> >
> > > >> >
> > > >> > This is not intended as a feature freeze, as I know there are still some
> > > >> >
> > > >> > things being worked on for 8.0; however, it should let us clean up master by
> > > >> > removing as much deprecated code as possible, and give us an idea of any
> > > >> > replacement work that needs to be done.
> > > >> >
> > > >> >
> > > >> >
> > > >> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > January.
> > > >> >
> > > >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > It would be nice to see Solr 8 in January soon as there is an enhancement
> > > >> >
> > > >> > on nested-documents we are waiting to get our hands on.
> > > >> >
> > > >> > Any idea when Solr 8 would be out ?
> > > >> >
> > > >> > Thx
> > > >> > SG
> > > >> >
> > > >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > >> >
> > > >> > <da...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > > >> >
> > > >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > > >> >
> > > >> >  click here:
> > > >> >
> > > >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > >> >
> > > >> >
> > > >> > Thru the end of the month, I intend to work on those issues not yet
> > > >> >
> > > >> > assigned.
> > > >> >
> > > >> >
> > > >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > +1
> > > >> >
> > > >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > >> >
> > > >> > <ro...@gmail.com> wrote:
> > > >> >
> > > >> >
> > > >> > Hi all,
> > > >> >
> > > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > > >> >
> > > >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > > >> > branch this week - say Wednesday?  Then we should have some time to
> > > >> > clean up the master branch and uncover anything that still needs to be done
> > > >> > on 8.0 before we start the release process next year.
> > > >> >
> > > >> >
> > > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > > >> >
> > > >> > wrote:
> > > >> >
> > > >> >
> > > >> > 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
> > > >> >
> > > >> > <er...@gmail.com> 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 <ji...@gmail.com>
> > > >> >
> > > >> > 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
> > > >> >
> > > >> > <da...@gmail.com> a écrit :
> > > >> >
> > > >> >
> > > >> > +1 to a 7.6 —lots of stuff in there
> > > >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > >> >
> > > >> > <nk...@gmail.com> 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
> > > >> >
> > > >> > <ca...@gmail.com> 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
> > > >> >
> > > >> > <ji...@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
> > > >> >
> > > >> > <ca...@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
> > > >> >
> > > >> > <ji...@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
> > > >> >
> > > >> > <ca...@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
> > > >> >
> > > >> > <er...@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
> > > >> >
> > > >> > <da...@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
> > > >> >
> > > >> > <ji...@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%3DBlocke
> > > >> > r%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
> > > >> >
> > > >> > <jp...@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
> > > >> >
> > > >> > <jp...@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%3DBlocke
> > > >> > r%20and%20resolution%20%3D%20Unresolved%20
> > > >> >
> > > >> >
> > > >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > > >> >
> > > >> > <ji...@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
> > > >> >
> > > >> > <er...@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
> > > >> >
> > > >> > <ca...@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
> > > >> >
> > > >> > <ji...@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
> > > >> >
> > > >> > <da...@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 --
> > > >> >
> > > >> > &g
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > Sincerely yours
> > > >> > Mikhail Khludnev
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> >
> > > >> > --
> > > >> > -----------------------------------------------------
> > > >> > Noble Paul
> > > >> >
> > > >> > ---------------------------------------------------------------------
> > > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >> >
> > > >> >
> > > >>
> > > >>
> > > >> --
> > > >> Adrien
> > > >>
> > > >> ---------------------------------------------------------------------
> > > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Fwd: Lucene/Solr 8.0

[Jason Gerlowski <ge...@gmail.com>]

Are you sure Ishan?  I just did a "docker pull solr" and it looks like
I'm getting 8.0.  Here's what I tried: https://pastebin.com/uPwCammc

From the commit history here, maybe this is a recent change though?
https://github.com/docker-solr/docker-solr

Anyway, if you retry and still see 7.7.1, let me know and we can
figure things out from there.

On Thu, May 2, 2019 at 5:05 PM Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> What should be done to get 8.0 version added to Docker Hub [0]?
> Would this need to be done by Martijn Koster at Lucidworks? If so, can
> someone please request him to take a look?
> Or is this something that even we (@ Apache) can do too?
>
> [0] - https://hub.docker.com/_/solr/
>
> On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> >
> > On a different note, I realized 2 days back that the solr:latest on
> > docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> > image on docker hub?
> >
> > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <ca...@gmail.com> wrote:
> > >
> > > I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
> > >
> > > Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now.
> > >
> > > Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch.
> > > On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>, wrote:
> > >
> > > Hi Dat,
> > >
> > > I plan to update Solr's release notes for 8.0 retroactively.   https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I wrote this well over a month ago.  Can you please enhance the part on HTTP2 to be more informative?  For example... what *benefit* does HTTP2 bring to internode communication?  I know you benchmarked things.  Maybe mention the road to full HTTP2 continues into 8.x?
> > >
> > > I'm sending this to the dev list so really anyone else can help like list other major features... though I think maybe it's just these two.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > > ---------- Forwarded message ---------
> > > From: David Smiley <da...@gmail.com>
> > > Date: Thu, Mar 14, 2019 at 9:34 AM
> > > Subject: Re: Lucene/Solr 8.0
> > > To: Solr/Lucene Dev <de...@lucene.apache.org>
> > >
> > >
> > > The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> > > In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> > > That would not have been embarrassing.
> > > Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> > > that is a juncture in which the features are frozen and there's plenty of time to update.
> > > Last night I saw the call to action but it was woefully too late for me to help.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
> > >>
> > >> I organized existing items of the Lucene release notes into sections
> > >> and added a new item about FeatureField,
> > >> LongPoint#newDistanceFeatureQuery and
> > >> LatLonPoint#newDistanceFeatureQuery.
> > >>
> > >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> > Jim and I have created wiki pages for the 8.0 release highlights here:
> > >> > https://wiki.apache.org/solr/ReleaseNote80
> > >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> > >> >
> > >> > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
> > >> >
> > >> >
> > >> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> > >> >
> > >> > I'm committing them,
> > >> > Thanks Ishan
> > >> >
> > >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Awesome, thank you Ishan!
> > >> >
> > >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> > >> >
> > >> > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
> > >> >
> > >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
> > >> >
> > >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> > >> >
> > >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
> > >> >
> > >> >
> > >> > Thank you, Alan. Give me an hour.
> > >> >
> > >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > >> >
> > >> >
> > >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> > >> >
> > >> > Mikhail, will you be able to get your fix in soon as well?
> > >> >
> > >> >
> > >> >
> > >> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> > >> >
> > >> >
> > >> >
> > >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> > >> >
> > >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Hi Shalin,
> > >> >
> > >> > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> > >> >
> > >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
> > >> >
> > >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
> > >> >
> > >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> > >> >
> > >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> > >> >
> > >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> > >> >
> > >> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
> > >> >
> > >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
> > >> >
> > >> > Cassandra
> > >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
> > >> >
> > >> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
> > >> >
> > >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
> > >> >
> > >> >
> > >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> > >> >
> > >> > Hey Alan,
> > >> >
> > >> > I just committed a minor inconsequential bugfix
> > >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > >> > realize I was cutting it so close to your work on cutting RC1, but
> > >> > from commits I see you made this morning preparing for the RC I
> > >> > suspect I cut things _very_ close and just missed it.
> > >> >
> > >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > >> > problems for you on the release end.  I'm happy to do whatever's
> > >> > easiest for you regarding that commit.  It'd be nice to have it
> > >> > included in 8.0, but it's not imperative by any means if I've already
> > >> > missed the first RC, or it's easier for you to omit from potential
> > >> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > >> > go back and update CHANGES.txt I think.
> > >> >
> > >> > Sorry again for the potential complication.  I hate to be "that guy".
> > >> > Thanks for stepping up and handling the release.
> > >> >
> > >> > Best,
> > >> >
> > >> > Jason
> > >> >
> > >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> > >> > I'll be more careful next time ;).
> > >> >
> > >> > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
> > >> >
> > >> > Jim
> > >> >
> > >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
> > >> >
> > >> > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > >> >
> > >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
> > >> >
> > >> > Cassandra
> > >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> > >> >
> > >> > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
> > >> >
> > >> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> > >> >
> > >> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> > >> >
> > >> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> > >> >
> > >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> > >> >
> > >> >
> > >> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> > >> >
> > >> > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> > >> >
> > >> > https://issues.apache.org/jira/browse/SOLR-13138
> > >> > https://issues.apache.org/jira/browse/LUCENE-8638
> > >> > There's a "master-deprecations" branch as well.
> > >> >
> > >> > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> > >> >
> > >> > ~ David
> > >> >
> > >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> > >> >
> > >> >
> > >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > >> > I'm keeping any eye on the builds this weekend but all indications are
> > >> > no issues so far.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Nick, this change seems to be causing test failures. Can you have a look?
> > >> >
> > >> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > >> >
> > >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thank you Jim. LUCENE-8669 has been merged.
> > >> >
> > >> > - Nick
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > >> > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > >> >
> > >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > Hey Jim,
> > >> >
> > >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:07 PM
> > >> >
> > >> > Kevin Risden <kr...@apache.org> wrote:
> > >> >
> > >> >
> > >> > Jim,
> > >> >
> > >> > Since 7.7 needs to be released before 8.0 does that leave time to get
> > >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > >> > currently under review.
> > >> >
> > >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > >> > feel this should make it into 8.0 or not.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> > >> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > >> > I'll restore the version bump for 8.0 when 7.7 is out.
> > >> >
> > >> >
> > >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > Hi,
> > >> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > >> > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > >> >
> > >> > No new features may be committed to the branch.
> > >> > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > >> > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > >> > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > >> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Jim
> > >> >
> > >> >
> > >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > sure, thanks Jim!
> > >> >
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > >> > <ji...@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Go ahead Tommaso the branch is not created yet.
> > >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > >> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > >> > early next week. Would that work for you ?
> > >> >
> > >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > >> >
> > >> > Regards,
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > >> > <jp...@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Hi Noble,
> > >> >
> > >> > No it hasn't created yet.
> > >> >
> > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Is the branch already cut for 8.0? which is it?
> > >> >
> > >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > >> > I will work on some documentation for it this week -- SOLR-13129
> > >> >
> > >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > >> >
> > >> >
> > >> > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > >> > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > >> > I'll try to take a look next week.
> > >> >
> > >> > --
> > >> > Jan Høydahl, search solution architect
> > >> > Cominvent AS - www.cominvent.com
> > >> >
> > >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > >> >
> > >> > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > >> >
> > >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > >> >
> > >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Releasing a new major is very challenging on its own, I'd rather not
> > >> > call it a blocker and delay the release for it since this isn't a new
> > >> > regression in 8.0: it looks like a problem that has affected Solr
> > >> > since at least 6.3? I'm not familiar with the UI code at all, but
> > >> > maybe this is something that could get fixed before we build a RC?
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > >> >
> > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > >> >
> > >> >
> > >> > Cool,
> > >> >
> > >> > I am working on giving my best release time guess as possible on the FOSDEM conference!
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > -----Original Message-----
> > >> > From: Adrien Grand <jp...@gmail.com>
> > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >> > To: Lucene Dev <de...@lucene.apache.org>
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > >> >
> > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > >> > wrote:
> > >> >
> > >> >
> > >> > Hi,
> > >> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > >> >
> > >> > already created so we can start the process anytime now. Unless there are
> > >> > objections I'd like to start the feature freeze next week in order to build the
> > >> > first candidate the week after.
> > >> >
> > >> > We'll also need a 7.7 release but I think we can handle both with Alan so
> > >> >
> > >> > the question now is whether we are ok to start the release process or if there
> > >> > are any blockers left ;).
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > >> >
> > >> > a écrit :
> > >> >
> > >> >
> > >> > I’ve started to work through the various deprecations on the new master
> > >> >
> > >> > branch.  There are a lot of them, and I’m going to need some assistance for
> > >> > several of them, as it’s not entirely clear what to do.
> > >> >
> > >> >
> > >> > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > >> >
> > >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> > >> > a shared branch on gitbox to work against, and push the changes I’ve already
> > >> > done there.  We can then create individual JIRA issues for any changes that
> > >> > are more involved than just deleting code.
> > >> >
> > >> >
> > >> > All assistance gratefully received, particularly for the Solr deprecations
> > >> >
> > >> > where there’s a lot of code I’m unfamiliar with.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > >> >
> > >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > >> > for now.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I will start and add the branch_8x jobs to Jenkins once I have some time
> > >> >
> > >> > later today.
> > >> >
> > >> >
> > >> > The question: How to proceed with branch_7x? Should we stop using it
> > >> >
> > >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > >> > the jenkins jobs enabled for a while.
> > >> >
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > From: Alan Woodward <ro...@gmail.com>
> > >> > Sent: Monday, January 7, 2019 11:30 AM
> > >> > To: dev@lucene.apache.org
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > >> >
> > >> > from master, and am in the process of updating the master branch to version
> > >> > 9.  New commits that should be included in the 8.0 release should also be
> > >> > back-ported to branch_8x from master.
> > >> >
> > >> >
> > >> > This is not intended as a feature freeze, as I know there are still some
> > >> >
> > >> > things being worked on for 8.0; however, it should let us clean up master by
> > >> > removing as much deprecated code as possible, and give us an idea of any
> > >> > replacement work that needs to be done.
> > >> >
> > >> >
> > >> >
> > >> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > January.
> > >> >
> > >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > It would be nice to see Solr 8 in January soon as there is an enhancement
> > >> >
> > >> > on nested-documents we are waiting to get our hands on.
> > >> >
> > >> > Any idea when Solr 8 would be out ?
> > >> >
> > >> > Thx
> > >> > SG
> > >> >
> > >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >> >
> > >> > <da...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > >> >
> > >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >> >
> > >> >  click here:
> > >> >
> > >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >> >
> > >> >
> > >> > Thru the end of the month, I intend to work on those issues not yet
> > >> >
> > >> > assigned.
> > >> >
> > >> >
> > >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > +1
> > >> >
> > >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > >> >
> > >> > <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Hi all,
> > >> >
> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > >> >
> > >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > >> > branch this week - say Wednesday?  Then we should have some time to
> > >> > clean up the master branch and uncover anything that still needs to be done
> > >> > on 8.0 before we start the release process next year.
> > >> >
> > >> >
> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > 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
> > >> >
> > >> > <er...@gmail.com> 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 <ji...@gmail.com>
> > >> >
> > >> > 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
> > >> >
> > >> > <da...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > +1 to a 7.6 —lots of stuff in there
> > >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > >> >
> > >> > <nk...@gmail.com> 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
> > >> >
> > >> > <ca...@gmail.com> 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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <er...@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
> > >> >
> > >> > <da...@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
> > >> >
> > >> > <ji...@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%3DBlocke
> > >> > r%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
> > >> >
> > >> > <jp...@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
> > >> >
> > >> > <jp...@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%3DBlocke
> > >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >> >
> > >> >
> > >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <er...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <da...@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 --
> > >> >
> > >> > &g
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sincerely yours
> > >> > Mikhail Khludnev
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > -----------------------------------------------------
> > >> > Noble Paul
> > >> >
> > >> > ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Adrien
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Fwd: Lucene/Solr 8.0

[Đạt Cao Mạnh <ca...@gmail.com>]

Hi David,

I agree with Cassandra about using ref-guide for expressing our idea and
our plan for a major version. But I also make some minor change to the wiki
page about what we are gainning on switching to HTTP/2.

On Thu, May 2, 2019 at 10:04 PM Ishan Chattopadhyaya <
ichattopadhyaya@gmail.com> wrote:

> What should be done to get 8.0 version added to Docker Hub [0]?
> Would this need to be done by Martijn Koster at Lucidworks? If so, can
> someone please request him to take a look?
> Or is this something that even we (@ Apache) can do too?
>
> [0] - https://hub.docker.com/_/solr/
>
> On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
> <ic...@gmail.com> wrote:
> >
> > On a different note, I realized 2 days back that the solr:latest on
> > docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> > image on docker hub?
> >
> > On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <ca...@gmail.com>
> wrote:
> > >
> > > I have a number of changes in a local branch for the 8.0 Ref Guide
> page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t
> intended to push my branch, but I could if it helps. I also have a bunch of
> unfinished content I started about nested documents, but tearing apart the
> CHANGES.txt to figure out what is new and how that impacts upgrades is
> incredibly painful and time-consuming, and I don’t have a ton of time these
> days. This is why the 8.0 Ref Guide isn’t out yet.
> > >
> > > Tangentially, I feel like we need to work something else out about
> Wiki release notes (and, remember, wiki.apache.org is going away really
> soon now) and the Ref Guide. It’s odd to me that one person decides how to
> present what’s new in the Wiki release notes, and someone else decides how
> to present a whole other set of content about the same set of features for
> the Ref Guide. Usually I skip the what’s new part for the minor releases,
> but for major ones, there needs to be a comprehensive “here’s what’s new
> and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the
> major version process now.
> > >
> > > Anyway, let me know if you want to see what I have so far, and I’ll
> try to find some time to push it or make a patch.
> > > On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>,
> wrote:
> > >
> > > Hi Dat,
> > >
> > > I plan to update Solr's release notes for 8.0 retroactively.
> https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs;
> I wrote this well over a month ago.  Can you please enhance the part on
> HTTP2 to be more informative?  For example... what *benefit* does HTTP2
> bring to internode communication?  I know you benchmarked things.  Maybe
> mention the road to full HTTP2 continues into 8.x?
> > >
> > > I'm sending this to the dev list so really anyone else can help like
> list other major features... though I think maybe it's just these two.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > > ---------- Forwarded message ---------
> > > From: David Smiley <da...@gmail.com>
> > > Date: Thu, Mar 14, 2019 at 9:34 AM
> > > Subject: Re: Lucene/Solr 8.0
> > > To: Solr/Lucene Dev <de...@lucene.apache.org>
> > >
> > >
> > > The Solr highlights section of the announcement is severely incomplete
> as to appear embarrassing.
> > > In the absence of time/effort to fix it should have simply been
> omitted; the CHANGES.txt has details.
> > > That would not have been embarrassing.
> > > Maybe next time we could have a call to action about the release
> highlights that coincides with the creation of the release branch;
> > > that is a juncture in which the features are frozen and there's plenty
> of time to update.
> > > Last night I saw the call to action but it was woefully too late for
> me to help.
> > >
> > > ~ David Smiley
> > > Apache Lucene/Solr Search Developer
> > > http://www.linkedin.com/in/davidwsmiley
> > >
> > >
> > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com>
> wrote:
> > >>
> > >> I organized existing items of the Lucene release notes into sections
> > >> and added a new item about FeatureField,
> > >> LongPoint#newDistanceFeatureQuery and
> > >> LatLonPoint#newDistanceFeatureQuery.
> > >>
> > >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> > Jim and I have created wiki pages for the 8.0 release highlights
> here:
> > >> > https://wiki.apache.org/solr/ReleaseNote80
> > >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> > >> >
> > >> > Feel free to edit and improve them - the Solr one in particular
> could do with some beefing up.
> > >> >
> > >> >
> > >> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> > >> >
> > >> > I'm committing them,
> > >> > Thanks Ishan
> > >> >
> > >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Awesome, thank you Ishan!
> > >> >
> > >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> > >> >
> > >> > I can volunteer for 7.7.1. I'll start as soon as both these issues
> are committed.
> > >> >
> > >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
> > >> >
> > >> > Would anyone like to volunteer to be release manager for 7.7.1?
> Ideally we would get this done quickly so that I can continue releasing
> 8.0.0.
> > >> >
> > >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> > >> >
> > >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org>
> wrote:
> > >> >
> > >> >
> > >> > Thank you, Alan. Give me an hour.
> > >> >
> > >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > >> >
> > >> >
> > >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> > >> >
> > >> > Mikhail, will you be able to get your fix in soon as well?
> > >> >
> > >> >
> > >> >
> > >> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> > >> >
> > >> >
> > >> >
> > >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > There is a work-around which is to change the default to using
> legacy assignment using cluster properties. But I don't like the idea of
> releasing something that we know is broken and asking everyone to set a
> cluster property to workaround it. I'd rather just rollback the commits
> that caused the problem and then release 8.0
> > >> >
> > >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Hi Shalin,
> > >> >
> > >> > I'm not familiar with this bit of code - is there a workaround
> available?  ie a way of using a different replica placement strategy when
> creating a collection?  If there is, I'd be tempted to continue with the
> vote as is and then do an immediate 8.0.1 release once you have things
> fixed, particularly if we’re going to require a 7.7.1 as well.
> > >> >
> > >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <
> shalinmangar@gmail.com> wrote:
> > >> >
> > >> > Hi Alan,
> > >> >
> > >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should
> be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In
> the interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
> > >> >
> > >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > The release candidate has already been built and voting is in
> progress, so it’s missed the boat unless there’s a respin.  It does look
> like a nasty bug though, so if you have a fix then feel free too commit it
> to the 8_0 branch in case we do an 8.0.1 release.
> > >> >
> > >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> > >> >
> > >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> > >> >
> > >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I have no problem with bug-fixes and ref-guide changes on the 8_0
> branch.
> > >> >
> > >> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
> wrote:
> > >> >
> > >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed
> even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at
> all since there’s a lot of editing yet to be done for it.
> > >> >
> > >> > Cassandra
> > >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <
> david.w.smiley@gmail.com>, wrote:
> > >> >
> > >> > I've been shepherding
> https://issues.apache.org/jira/browse/SOLR-13129 which only touches the
> Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's
> committed after the 8.0 for the code?  I could avoid touching CHANGES.txt
> if that helps (it'd be of dubious value to users browsing the change list
> any way).
> > >> >
> > >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <
> romseygeek@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for letting me know Jason.  Your commit will have missed the
> cut, yes, but I don’t think it matters that much.  It will get picked up in
> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
> > >> >
> > >> >
> > >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
> wrote:
> > >> >
> > >> > Hey Alan,
> > >> >
> > >> > I just committed a minor inconsequential bugfix
> > >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > >> > realize I was cutting it so close to your work on cutting RC1, but
> > >> > from commits I see you made this morning preparing for the RC I
> > >> > suspect I cut things _very_ close and just missed it.
> > >> >
> > >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > >> > problems for you on the release end.  I'm happy to do whatever's
> > >> > easiest for you regarding that commit.  It'd be nice to have it
> > >> > included in 8.0, but it's not imperative by any means if I've
> already
> > >> > missed the first RC, or it's easier for you to omit from potential
> > >> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > >> > go back and update CHANGES.txt I think.
> > >> >
> > >> > Sorry again for the potential complication.  I hate to be "that
> guy".
> > >> > Thanks for stepping up and handling the release.
> > >> >
> > >> > Best,
> > >> >
> > >> > Jason
> > >> >
> > >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Thanks for fixing Cassandra and sorry for the noise. I did this too
> many times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> > >> > I'll be more careful next time ;).
> > >> >
> > >> > On another note, now that 7.7 is out and that we're preparing the
> release for 8.0 what do you think of removing/nuking the 7x branch. This
> was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> > >> >
> > >> > Jim
> > >> >
> > >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
> casstargett@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I’d like to remind RMs that when finishing up a release, we can’t
> just do a blanket find/replace in .htaccess to update the version. If we’re
> not going to coordinate binary releases with Ref Guide releases, we need to
> be careful not to change the redirects unless that version’s Ref Guide
> release is also imminent.
> > >> >
> > >> > This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > >> >
> > >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so
> it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
> else needs to maybe take care of it), but all non-version specific Ref
> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
> fix, but we have an easy way to avoid routing people to dead links.
> > >> >
> > >> > Cassandra
> > >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
> > >> >
> > >> > Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
> > >> >
> > >> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> > It is a shame, I agree, but some of this stuff has been deprecated
> since 3.6, so another release cycle won’t hurt :). We should prioritise
> cleaning this stuff up once 8.0 is out of the door though.
> > >> >
> > >> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
> wrote:
> > >> >
> > >> > Okay.  I suppose the issue is that it's simply too late in the 8.0
> cycle to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> > >> >
> > >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Not quite - the plan is to remove things entirely in 9.0, but we
> may need to back port some extra deprecations to 8x.  We don’t necessarily
> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
> any problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
> > >> >
> > >> >
> > >> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
> wrote:
> > >> >
> > >> > I want to ensure people are aware of two issues "Remove deprecated
> code in master" that Alan filed:
> > >> >
> > >> > https://issues.apache.org/jira/browse/SOLR-13138
> > >> > https://issues.apache.org/jira/browse/LUCENE-8638
> > >> > There's a "master-deprecations" branch as well.
> > >> >
> > >> > Although both issues are marked "master (9.0)", I think the intent
> is actually 8.0 so that we are finally rid of the deprecated code?
> > >> >
> > >> > ~ David
> > >> >
> > >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
> wrote:
> > >> >
> > >> >
> > >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > >> > I'm keeping any eye on the builds this weekend but all indications
> are
> > >> > no issues so far.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Nick, this change seems to be causing test failures. Can you have a
> look?
> > >> >
> > >> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > >> >
> > >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Thank you Jim. LUCENE-8669 has been merged.
> > >> >
> > >> > - Nick
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start
> the first RC when your patch is merged.
> > >> > Kevin, this looks like a big change so I am not sure if it's a good
> idea to rush this in for 8.0. Would it be safer to target another version
> in order to take some time to ensure that it's not breaking anything ? I
> guess that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
> > >> >
> > >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
> écrit :
> > >> >
> > >> >
> > >> > Hey Jim,
> > >> >
> > >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669
> along with a pretty straightforward patch. This is a critical one that I
> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > >> >
> > >> > On Wed, Jan 30, 2019 at 1:07 PM
> > >> >
> > >> > Kevin Risden <kr...@apache.org> wrote:
> > >> >
> > >> >
> > >> > Jim,
> > >> >
> > >> > Since 7.7 needs to be released before 8.0 does that leave time to
> get
> > >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > >> > currently under review.
> > >> >
> > >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
> others
> > >> > feel this should make it into 8.0 or not.
> > >> >
> > >> > Kevin Risden
> > >> >
> > >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I had to revert the version bump for 8.0 (8.1) on branch_8x because
> we don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > >> > Since we want to release 7.7 first I created the Jenkins job for
> this version only and will build the first candidate for this version later
> this week if there are no objection.
> > >> > I'll restore the version bump for 8.0 when 7.7 is out.
> > >> >
> > >> >
> > >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com>
> a écrit :
> > >> >
> > >> >
> > >> > Hi,
> > >> > Hearing no objection I created the branches for 8.0 and 7.7. I'll
> now create the Jenkins tasks for these versions, Uwe can you also add them
> to the Policeman's Jenkins job ?
> > >> > This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
> > >> >
> > >> > No new features may be committed to the branch.
> > >> > Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > >> > All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> > >> > Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> > >> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will
> delay a release candidate build.
> > >> >
> > >> >
> > >> > Thanks,
> > >> > Jim
> > >> >
> > >> >
> > >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > sure, thanks Jim!
> > >> >
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > >> > <ji...@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Go ahead Tommaso the branch is not created yet.
> > >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
> wednesday and to announce the feature freeze the same day.
> > >> > For blocker issues that are still open this leaves another week to
> work on a patch and we can update the status at the end of the week in
> order to decide if we can start the first build candidate
> > >> > early next week. Would that work for you ?
> > >> >
> > >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> > >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > >> >
> > >> > Regards,
> > >> > Tommaso
> > >> >
> > >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > >> > <jp...@gmail.com> ha scritto:
> > >> >
> > >> >
> > >> > Hi Noble,
> > >> >
> > >> > No it hasn't created yet.
> > >> >
> > >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Is the branch already cut for 8.0? which is it?
> > >> >
> > >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > >> > I will work on some documentation for it this week -- SOLR-13129
> > >> >
> > >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> > >> >
> > >> >
> > >> > I don't think it is critical for this to be a blocker for 8.0. If
> it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > >> > I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> > >> > I'll try to take a look next week.
> > >> >
> > >> > --
> > >> > Jan Høydahl, search solution architect
> > >> > Cominvent AS - www.cominvent.com
> > >> >
> > >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> > >> >
> > >> > I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> > >> >
> > >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > It looks like someone tried to make it a blocker once before... And
> it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> > >> >
> > >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > Releasing a new major is very challenging on its own, I'd rather not
> > >> > call it a blocker and delay the release for it since this isn't a
> new
> > >> > regression in 8.0: it looks like a problem that has affected Solr
> > >> > since at least 6.3? I'm not familiar with the UI code at all, but
> > >> > maybe this is something that could get fixed before we build a RC?
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com>
> wrote:
> > >> >
> > >> >
> > >> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > >> >
> > >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > >> >
> > >> >
> > >> > Cool,
> > >> >
> > >> > I am working on giving my best release time guess as possible on
> the FOSDEM conference!
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > -----Original Message-----
> > >> > From: Adrien Grand <jp...@gmail.com>
> > >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >> > To: Lucene Dev <de...@lucene.apache.org>
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
> 4th.
> > >> >
> > >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> > >> > wrote:
> > >> >
> > >> >
> > >> > Hi,
> > >> > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> > >> >
> > >> > already created so we can start the process anytime now. Unless
> there are
> > >> > objections I'd like to start the feature freeze next week in order
> to build the
> > >> > first candidate the week after.
> > >> >
> > >> > We'll also need a 7.7 release but I think we can handle both with
> Alan so
> > >> >
> > >> > the question now is whether we are ok to start the release process
> or if there
> > >> > are any blockers left ;).
> > >> >
> > >> >
> > >> >
> > >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > >> >
> > >> > a écrit :
> > >> >
> > >> >
> > >> > I’ve started to work through the various deprecations on the new
> master
> > >> >
> > >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> > >> > several of them, as it’s not entirely clear what to do.
> > >> >
> > >> >
> > >> > I’ll open two overarching issues in JIRA, one for lucene and one
> for Solr,
> > >> >
> > >> > with lists of the deprecations that need to be removed in each
> one.  I’ll create
> > >> > a shared branch on gitbox to work against, and push the changes
> I’ve already
> > >> > done there.  We can then create individual JIRA issues for any
> changes that
> > >> > are more involved than just deleting code.
> > >> >
> > >> >
> > >> > All assistance gratefully received, particularly for the Solr
> deprecations
> > >> >
> > >> > where there’s a lot of code I’m unfamiliar with.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > I think the current plan is to do a 7.7 release at the same time as
> 8.0, to
> > >> >
> > >> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > >> > for now.
> > >> >
> > >> >
> > >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > >> >
> > >> > Hi,
> > >> >
> > >> > I will start and add the branch_8x jobs to Jenkins once I have some
> time
> > >> >
> > >> > later today.
> > >> >
> > >> >
> > >> > The question: How to proceed with branch_7x? Should we stop using it
> > >> >
> > >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> > >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
> would keep
> > >> > the jenkins jobs enabled for a while.
> > >> >
> > >> >
> > >> > Uwe
> > >> >
> > >> > -----
> > >> > Uwe Schindler
> > >> > Achterdiek 19, D-28357 Bremen
> > >> > http://www.thetaphi.de
> > >> > eMail: uwe@thetaphi.de
> > >> >
> > >> > From: Alan Woodward <ro...@gmail.com>
> > >> > Sent: Monday, January 7, 2019 11:30 AM
> > >> > To: dev@lucene.apache.org
> > >> > Subject: Re: Lucene/Solr 8.0
> > >> >
> > >> > OK, Christmas caught up with me a bit… I’ve just created a branch
> for 8x
> > >> >
> > >> > from master, and am in the process of updating the master branch to
> version
> > >> > 9.  New commits that should be included in the 8.0 release should
> also be
> > >> > back-ported to branch_8x from master.
> > >> >
> > >> >
> > >> > This is not intended as a feature freeze, as I know there are still
> some
> > >> >
> > >> > things being worked on for 8.0; however, it should let us clean up
> master by
> > >> > removing as much deprecated code as possible, and give us an idea
> of any
> > >> > replacement work that needs to be done.
> > >> >
> > >> >
> > >> >
> > >> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > January.
> > >> >
> > >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > It would be nice to see Solr 8 in January soon as there is an
> enhancement
> > >> >
> > >> > on nested-documents we are waiting to get our hands on.
> > >> >
> > >> > Any idea when Solr 8 would be out ?
> > >> >
> > >> > Thx
> > >> > SG
> > >> >
> > >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >> >
> > >> > <da...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > I see 10 JIRA issues matching this filter:   project in (SOLR,
> LUCENE) AND
> > >> >
> > >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >> >
> > >> >  click here:
> > >> >
> > >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >> >
> > >> >
> > >> > Thru the end of the month, I intend to work on those issues not yet
> > >> >
> > >> > assigned.
> > >> >
> > >> >
> > >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > +1
> > >> >
> > >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > >> >
> > >> > <ro...@gmail.com> wrote:
> > >> >
> > >> >
> > >> > Hi all,
> > >> >
> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > >> >
> > >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> > >> > branch this week - say Wednesday?  Then we should have some time to
> > >> > clean up the master branch and uncover anything that still needs to
> be done
> > >> > on 8.0 before we start the release process next year.
> > >> >
> > >> >
> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > >> >
> > >> > wrote:
> > >> >
> > >> >
> > >> > 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
> > >> >
> > >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> > >> >
> > >> > 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
> > >> >
> > >> > <da...@gmail.com> a écrit :
> > >> >
> > >> >
> > >> > +1 to a 7.6 —lots of stuff in there
> > >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > >> >
> > >> > <nk...@gmail.com> 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
> > >> >
> > >> > <ca...@gmail.com> 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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <er...@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
> > >> >
> > >> > <da...@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
> > >> >
> > >> > <ji...@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%3DBlocke
> > >> > r%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
> > >> >
> > >> > <jp...@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
> > >> >
> > >> > <jp...@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%3DBlocke
> > >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >> >
> > >> >
> > >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <er...@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
> > >> >
> > >> > <ca...@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
> > >> >
> > >> > <ji...@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
> > >> >
> > >> > <da...@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 --
> > >> >
> > >> > &g
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > Sincerely yours
> > >> > Mikhail Khludnev
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > --
> > >> > -----------------------------------------------------
> > >> > Noble Paul
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >
> > >> >
> > >>
> > >>
> > >> --
> > >> Adrien
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
>


-- 
*Best regards,*
*Cao Mạnh Đạt*


*D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat317@gmail.com
<ca...@gmail.com>*

Re: Fwd: Lucene/Solr 8.0

[Ishan Chattopadhyaya <ic...@gmail.com>]

What should be done to get 8.0 version added to Docker Hub [0]?
Would this need to be done by Martijn Koster at Lucidworks? If so, can
someone please request him to take a look?
Or is this something that even we (@ Apache) can do too?

[0] - https://hub.docker.com/_/solr/

On Tue, Apr 30, 2019 at 9:44 PM Ishan Chattopadhyaya
<ic...@gmail.com> wrote:
>
> On a different note, I realized 2 days back that the solr:latest on
> docker hub points to 7.7.1. What do we need to do to get 8.0 docker
> image on docker hub?
>
> On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <ca...@gmail.com> wrote:
> >
> > I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
> >
> > Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now.
> >
> > Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch.
> > On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>, wrote:
> >
> > Hi Dat,
> >
> > I plan to update Solr's release notes for 8.0 retroactively.   https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I wrote this well over a month ago.  Can you please enhance the part on HTTP2 to be more informative?  For example... what *benefit* does HTTP2 bring to internode communication?  I know you benchmarked things.  Maybe mention the road to full HTTP2 continues into 8.x?
> >
> > I'm sending this to the dev list so really anyone else can help like list other major features... though I think maybe it's just these two.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> > ---------- Forwarded message ---------
> > From: David Smiley <da...@gmail.com>
> > Date: Thu, Mar 14, 2019 at 9:34 AM
> > Subject: Re: Lucene/Solr 8.0
> > To: Solr/Lucene Dev <de...@lucene.apache.org>
> >
> >
> > The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> > In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> > That would not have been embarrassing.
> > Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> > that is a juncture in which the features are frozen and there's plenty of time to update.
> > Last night I saw the call to action but it was woefully too late for me to help.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
> >>
> >> I organized existing items of the Lucene release notes into sections
> >> and added a new item about FeatureField,
> >> LongPoint#newDistanceFeatureQuery and
> >> LatLonPoint#newDistanceFeatureQuery.
> >>
> >> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> > Jim and I have created wiki pages for the 8.0 release highlights here:
> >> > https://wiki.apache.org/solr/ReleaseNote80
> >> > https://wiki.apache.org/lucene-java/ReleaseNote80
> >> >
> >> > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
> >> >
> >> >
> >> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> >> >
> >> > I'm committing them,
> >> > Thanks Ishan
> >> >
> >> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > Awesome, thank you Ishan!
> >> >
> >> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> >> >
> >> > Would anyone like to volunteer to be release manager for 7.7.1?
> >> >
> >> > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
> >> >
> >> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
> >> >
> >> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
> >> >
> >> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> >> >
> >> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
> >> >
> >> >
> >> > Thank you, Alan. Give me an hour.
> >> >
> >> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> >> >
> >> >
> >> > OK, let’s do an RC2.  When do you think you can have a fix in?
> >> >
> >> > Mikhail, will you be able to get your fix in soon as well?
> >> >
> >> >
> >> >
> >> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> >> >
> >> >
> >> >
> >> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> >> >
> >> > Hi Alan,
> >> >
> >> > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> >> >
> >> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > Hi Shalin,
> >> >
> >> > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> >> >
> >> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> >> >
> >> > Hi Alan,
> >> >
> >> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
> >> >
> >> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
> >> >
> >> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> >> >
> >> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> >> >
> >> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> >> >
> >> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
> >> >
> >> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
> >> >
> >> > Cassandra
> >> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
> >> >
> >> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
> >> >
> >> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
> >> >
> >> >
> >> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> >> >
> >> > Hey Alan,
> >> >
> >> > I just committed a minor inconsequential bugfix
> >> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> >> > realize I was cutting it so close to your work on cutting RC1, but
> >> > from commits I see you made this morning preparing for the RC I
> >> > suspect I cut things _very_ close and just missed it.
> >> >
> >> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> >> > problems for you on the release end.  I'm happy to do whatever's
> >> > easiest for you regarding that commit.  It'd be nice to have it
> >> > included in 8.0, but it's not imperative by any means if I've already
> >> > missed the first RC, or it's easier for you to omit from potential
> >> > subsequent RCs.  Let me know if there's anything you'd like me to do
> >> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> >> > go back and update CHANGES.txt I think.
> >> >
> >> > Sorry again for the potential complication.  I hate to be "that guy".
> >> > Thanks for stepping up and handling the release.
> >> >
> >> > Best,
> >> >
> >> > Jason
> >> >
> >> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
> >> >
> >> >
> >> > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> >> > I'll be more careful next time ;).
> >> >
> >> > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
> >> >
> >> > Jim
> >> >
> >> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
> >> >
> >> >
> >> > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
> >> >
> >> > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
> >> >
> >> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
> >> >
> >> > Cassandra
> >> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> >> >
> >> > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
> >> >
> >> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> >> >
> >> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> >> >
> >> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> >> >
> >> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> >> >
> >> >
> >> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> >> >
> >> > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> >> >
> >> > https://issues.apache.org/jira/browse/SOLR-13138
> >> > https://issues.apache.org/jira/browse/LUCENE-8638
> >> > There's a "master-deprecations" branch as well.
> >> >
> >> > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> >> >
> >> > ~ David
> >> >
> >> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> >> >
> >> >
> >> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> >> > I'm keeping any eye on the builds this weekend but all indications are
> >> > no issues so far.
> >> >
> >> > Kevin Risden
> >> >
> >> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> >> >
> >> >
> >> > Nick, this change seems to be causing test failures. Can you have a look?
> >> >
> >> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> >> >
> >> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> >> >
> >> >
> >> > Thank you Jim. LUCENE-8669 has been merged.
> >> >
> >> > - Nick
> >> >
> >> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> >> >
> >> >
> >> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> >> > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> >> >
> >> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> >> >
> >> >
> >> > Hey Jim,
> >> >
> >> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> >> >
> >> > On Wed, Jan 30, 2019 at 1:07 PM
> >> >
> >> > Kevin Risden <kr...@apache.org> wrote:
> >> >
> >> >
> >> > Jim,
> >> >
> >> > Since 7.7 needs to be released before 8.0 does that leave time to get
> >> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> >> > currently under review.
> >> >
> >> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> >> > feel this should make it into 8.0 or not.
> >> >
> >> > Kevin Risden
> >> >
> >> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> >> >
> >> >
> >> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> >> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> >> > I'll restore the version bump for 8.0 when 7.7 is out.
> >> >
> >> >
> >> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> >> >
> >> >
> >> > Hi,
> >> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> >> > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> >> >
> >> > No new features may be committed to the branch.
> >> > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> >> > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> >> > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> >> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> >> >
> >> >
> >> > Thanks,
> >> > Jim
> >> >
> >> >
> >> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> >> >
> >> >
> >> > sure, thanks Jim!
> >> >
> >> > Tommaso
> >> >
> >> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> >> > <ji...@gmail.com> ha scritto:
> >> >
> >> >
> >> > Go ahead Tommaso the branch is not created yet.
> >> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> >> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> >> > early next week. Would that work for you ?
> >> >
> >> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> >> >
> >> >
> >> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> >> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >> >
> >> > Regards,
> >> > Tommaso
> >> >
> >> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> >> > <jp...@gmail.com> ha scritto:
> >> >
> >> >
> >> > Hi Noble,
> >> >
> >> > No it hasn't created yet.
> >> >
> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> >> >
> >> >
> >> > Is the branch already cut for 8.0? which is it?
> >> >
> >> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> >> >
> >> >
> >> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> >> > I will work on some documentation for it this week -- SOLR-13129
> >> >
> >> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> >> >
> >> >
> >> > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> >> > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> >> > I'll try to take a look next week.
> >> >
> >> > --
> >> > Jan Høydahl, search solution architect
> >> > Cominvent AS - www.cominvent.com
> >> >
> >> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> >> >
> >> > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> >> >
> >> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> >> >
> >> >
> >> > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> >> >
> >> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> >> >
> >> >
> >> > Releasing a new major is very challenging on its own, I'd rather not
> >> > call it a blocker and delay the release for it since this isn't a new
> >> > regression in 8.0: it looks like a problem that has affected Solr
> >> > since at least 6.3? I'm not familiar with the UI code at all, but
> >> > maybe this is something that could get fixed before we build a RC?
> >> >
> >> >
> >> >
> >> >
> >> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >> >
> >> >
> >> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> >> >
> >> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >> >
> >> >
> >> > Cool,
> >> >
> >> > I am working on giving my best release time guess as possible on the FOSDEM conference!
> >> >
> >> > Uwe
> >> >
> >> > -----
> >> > Uwe Schindler
> >> > Achterdiek 19, D-28357 Bremen
> >> > http://www.thetaphi.de
> >> > eMail: uwe@thetaphi.de
> >> >
> >> > -----Original Message-----
> >> > From: Adrien Grand <jp...@gmail.com>
> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > To: Lucene Dev <de...@lucene.apache.org>
> >> > Subject: Re: Lucene/Solr 8.0
> >> >
> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >> >
> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> >> > wrote:
> >> >
> >> >
> >> > Hi,
> >> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> >> >
> >> > already created so we can start the process anytime now. Unless there are
> >> > objections I'd like to start the feature freeze next week in order to build the
> >> > first candidate the week after.
> >> >
> >> > We'll also need a 7.7 release but I think we can handle both with Alan so
> >> >
> >> > the question now is whether we are ok to start the release process or if there
> >> > are any blockers left ;).
> >> >
> >> >
> >> >
> >> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >> >
> >> > a écrit :
> >> >
> >> >
> >> > I’ve started to work through the various deprecations on the new master
> >> >
> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> >> > several of them, as it’s not entirely clear what to do.
> >> >
> >> >
> >> > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> >> >
> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> >> > done there.  We can then create individual JIRA issues for any changes that
> >> > are more involved than just deleting code.
> >> >
> >> >
> >> > All assistance gratefully received, particularly for the Solr deprecations
> >> >
> >> > where there’s a lot of code I’m unfamiliar with.
> >> >
> >> >
> >> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >> >
> >> > wrote:
> >> >
> >> >
> >> > I think the current plan is to do a 7.7 release at the same time as 8.0, to
> >> >
> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> >> > for now.
> >> >
> >> >
> >> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >> >
> >> > Hi,
> >> >
> >> > I will start and add the branch_8x jobs to Jenkins once I have some time
> >> >
> >> > later today.
> >> >
> >> >
> >> > The question: How to proceed with branch_7x? Should we stop using it
> >> >
> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> >> > the jenkins jobs enabled for a while.
> >> >
> >> >
> >> > Uwe
> >> >
> >> > -----
> >> > Uwe Schindler
> >> > Achterdiek 19, D-28357 Bremen
> >> > http://www.thetaphi.de
> >> > eMail: uwe@thetaphi.de
> >> >
> >> > From: Alan Woodward <ro...@gmail.com>
> >> > Sent: Monday, January 7, 2019 11:30 AM
> >> > To: dev@lucene.apache.org
> >> > Subject: Re: Lucene/Solr 8.0
> >> >
> >> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >> >
> >> > from master, and am in the process of updating the master branch to version
> >> > 9.  New commits that should be included in the 8.0 release should also be
> >> > back-ported to branch_8x from master.
> >> >
> >> >
> >> > This is not intended as a feature freeze, as I know there are still some
> >> >
> >> > things being worked on for 8.0; however, it should let us clean up master by
> >> > removing as much deprecated code as possible, and give us an idea of any
> >> > replacement work that needs to be done.
> >> >
> >> >
> >> >
> >> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >> >
> >> > wrote:
> >> >
> >> >
> >> > January.
> >> >
> >> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >> >
> >> > wrote:
> >> >
> >> >
> >> > It would be nice to see Solr 8 in January soon as there is an enhancement
> >> >
> >> > on nested-documents we are waiting to get our hands on.
> >> >
> >> > Any idea when Solr 8 would be out ?
> >> >
> >> > Thx
> >> > SG
> >> >
> >> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >> >
> >> > <da...@gmail.com> wrote:
> >> >
> >> >
> >> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> >> >
> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >> >
> >> >  click here:
> >> >
> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >> >
> >> >
> >> > Thru the end of the month, I intend to work on those issues not yet
> >> >
> >> > assigned.
> >> >
> >> >
> >> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >> >
> >> > wrote:
> >> >
> >> >
> >> > +1
> >> >
> >> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >> >
> >> > <ro...@gmail.com> wrote:
> >> >
> >> >
> >> > Hi all,
> >> >
> >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >> >
> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> >> > branch this week - say Wednesday?  Then we should have some time to
> >> > clean up the master branch and uncover anything that still needs to be done
> >> > on 8.0 before we start the release process next year.
> >> >
> >> >
> >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> >> >
> >> > wrote:
> >> >
> >> >
> >> > 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
> >> >
> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> >> >
> >> > 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
> >> >
> >> > <da...@gmail.com> a écrit :
> >> >
> >> >
> >> > +1 to a 7.6 —lots of stuff in there
> >> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >> >
> >> > <nk...@gmail.com> 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
> >> >
> >> > <ca...@gmail.com> 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
> >> >
> >> > <ji...@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
> >> >
> >> > <ca...@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
> >> >
> >> > <ji...@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
> >> >
> >> > <ca...@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
> >> >
> >> > <er...@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
> >> >
> >> > <da...@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
> >> >
> >> > <ji...@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%3DBlocke
> >> > r%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
> >> >
> >> > <jp...@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
> >> >
> >> > <jp...@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%3DBlocke
> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >> >
> >> >
> >> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >> >
> >> > <ji...@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
> >> >
> >> > <er...@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
> >> >
> >> > <ca...@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
> >> >
> >> > <ji...@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
> >> >
> >> > <da...@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 --
> >> >
> >> > &g
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > Sincerely yours
> >> > Mikhail Khludnev
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > --
> >> > -----------------------------------------------------
> >> > Noble Paul
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >> >
> >>
> >>
> >> --
> >> Adrien
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Fwd: Lucene/Solr 8.0

[Ishan Chattopadhyaya <ic...@gmail.com>]

On a different note, I realized 2 days back that the solr:latest on
docker hub points to 7.7.1. What do we need to do to get 8.0 docker
image on docker hub?

On Tue, Apr 30, 2019 at 6:57 PM Cassandra Targett <ca...@gmail.com> wrote:
>
> I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
>
> Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now.
>
> Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch.
> On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>, wrote:
>
> Hi Dat,
>
> I plan to update Solr's release notes for 8.0 retroactively.   https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I wrote this well over a month ago.  Can you please enhance the part on HTTP2 to be more informative?  For example... what *benefit* does HTTP2 bring to internode communication?  I know you benchmarked things.  Maybe mention the road to full HTTP2 continues into 8.x?
>
> I'm sending this to the dev list so really anyone else can help like list other major features... though I think maybe it's just these two.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> ---------- Forwarded message ---------
> From: David Smiley <da...@gmail.com>
> Date: Thu, Mar 14, 2019 at 9:34 AM
> Subject: Re: Lucene/Solr 8.0
> To: Solr/Lucene Dev <de...@lucene.apache.org>
>
>
> The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> That would not have been embarrassing.
> Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> that is a juncture in which the features are frozen and there's plenty of time to update.
> Last night I saw the call to action but it was woefully too late for me to help.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>>
>> I organized existing items of the Lucene release notes into sections
>> and added a new item about FeatureField,
>> LongPoint#newDistanceFeatureQuery and
>> LatLonPoint#newDistanceFeatureQuery.
>>
>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > Jim and I have created wiki pages for the 8.0 release highlights here:
>> > https://wiki.apache.org/solr/ReleaseNote80
>> > https://wiki.apache.org/lucene-java/ReleaseNote80
>> >
>> > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
>> >
>> >
>> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>> >
>> > I'm committing them,
>> > Thanks Ishan
>> >
>> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Awesome, thank you Ishan!
>> >
>> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?
>> >
>> > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>> >
>> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>> >
>> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> >
>> > Thank you, Alan. Give me an hour.
>> >
>> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>> >
>> >
>> > OK, let’s do an RC2.  When do you think you can have a fix in?
>> >
>> > Mikhail, will you be able to get your fix in soon as well?
>> >
>> >
>> >
>> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>> >
>> >
>> >
>> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>> >
>> > Hi Alan,
>> >
>> > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>> >
>> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Hi Shalin,
>> >
>> > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>> >
>> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>> >
>> > Hi Alan,
>> >
>> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>> >
>> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>> >
>> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>> >
>> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>> >
>> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>> >
>> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>> >
>> > Cassandra
>> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>> >
>> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>> >
>> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>> >
>> >
>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>> >
>> > Hey Alan,
>> >
>> > I just committed a minor inconsequential bugfix
>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>> > realize I was cutting it so close to your work on cutting RC1, but
>> > from commits I see you made this morning preparing for the RC I
>> > suspect I cut things _very_ close and just missed it.
>> >
>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>> > problems for you on the release end.  I'm happy to do whatever's
>> > easiest for you regarding that commit.  It'd be nice to have it
>> > included in 8.0, but it's not imperative by any means if I've already
>> > missed the first RC, or it's easier for you to omit from potential
>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>> > go back and update CHANGES.txt I think.
>> >
>> > Sorry again for the potential complication.  I hate to be "that guy".
>> > Thanks for stepping up and handling the release.
>> >
>> > Best,
>> >
>> > Jason
>> >
>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>> > I'll be more careful next time ;).
>> >
>> > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>> >
>> > Jim
>> >
>> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>> >
>> >
>> > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>> >
>> > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>> >
>> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>> >
>> > Cassandra
>> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>> >
>> > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>> >
>> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>> >
>> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>> >
>> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>> >
>> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> >
>> > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>> >
>> >
>> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>> >
>> > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>> >
>> > https://issues.apache.org/jira/browse/SOLR-13138
>> > https://issues.apache.org/jira/browse/LUCENE-8638
>> > There's a "master-deprecations" branch as well.
>> >
>> > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>> >
>> > ~ David
>> >
>> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> > I'm keeping any eye on the builds this weekend but all indications are
>> > no issues so far.
>> >
>> > Kevin Risden
>> >
>> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Nick, this change seems to be causing test failures. Can you have a look?
>> >
>> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>> >
>> >
>> > Thank you Jim. LUCENE-8669 has been merged.
>> >
>> > - Nick
>> >
>> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>> > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>> >
>> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>> >
>> >
>> > Hey Jim,
>> >
>> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> >
>> > On Wed, Jan 30, 2019 at 1:07 PM
>> >
>> > Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > Jim,
>> >
>> > Since 7.7 needs to be released before 8.0 does that leave time to get
>> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> > currently under review.
>> >
>> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> > feel this should make it into 8.0 or not.
>> >
>> > Kevin Risden
>> >
>> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>> >
>> >
>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> >
>> >
>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>> >
>> >
>> > Hi,
>> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>> > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>> >
>> > No new features may be committed to the branch.
>> > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>> > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>> > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>> >
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>> >
>> >
>> > sure, thanks Jim!
>> >
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > <ji...@gmail.com> ha scritto:
>> >
>> >
>> > Go ahead Tommaso the branch is not created yet.
>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>> > early next week. Would that work for you ?
>> >
>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>> >
>> >
>> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >
>> > Regards,
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > <jp...@gmail.com> ha scritto:
>> >
>> >
>> > Hi Noble,
>> >
>> > No it hasn't created yet.
>> >
>> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>> >
>> >
>> > Is the branch already cut for 8.0? which is it?
>> >
>> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>> >
>> >
>> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>> > I will work on some documentation for it this week -- SOLR-13129
>> >
>> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>> >
>> >
>> > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> > I'll try to take a look next week.
>> >
>> > --
>> > Jan Høydahl, search solution architect
>> > Cominvent AS - www.cominvent.com
>> >
>> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>> >
>> > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>> >
>> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>> >
>> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Releasing a new major is very challenging on its own, I'd rather not
>> > call it a blocker and delay the release for it since this isn't a new
>> > regression in 8.0: it looks like a problem that has affected Solr
>> > since at least 6.3? I'm not familiar with the UI code at all, but
>> > maybe this is something that could get fixed before we build a RC?
>> >
>> >
>> >
>> >
>> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>> >
>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> >
>> > Cool,
>> >
>> > I am working on giving my best release time guess as possible on the FOSDEM conference!
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > -----Original Message-----
>> > From: Adrien Grand <jp...@gmail.com>
>> > Sent: Thursday, January 24, 2019 5:33 PM
>> > To: Lucene Dev <de...@lucene.apache.org>
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> >
>> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>> > wrote:
>> >
>> >
>> > Hi,
>> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> >
>> > already created so we can start the process anytime now. Unless there are
>> > objections I'd like to start the feature freeze next week in order to build the
>> > first candidate the week after.
>> >
>> > We'll also need a 7.7 release but I think we can handle both with Alan so
>> >
>> > the question now is whether we are ok to start the release process or if there
>> > are any blockers left ;).
>> >
>> >
>> >
>> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>> >
>> > a écrit :
>> >
>> >
>> > I’ve started to work through the various deprecations on the new master
>> >
>> > branch.  There are a lot of them, and I’m going to need some assistance for
>> > several of them, as it’s not entirely clear what to do.
>> >
>> >
>> > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> >
>> > with lists of the deprecations that need to be removed in each one.  I’ll create
>> > a shared branch on gitbox to work against, and push the changes I’ve already
>> > done there.  We can then create individual JIRA issues for any changes that
>> > are more involved than just deleting code.
>> >
>> >
>> > All assistance gratefully received, particularly for the Solr deprecations
>> >
>> > where there’s a lot of code I’m unfamiliar with.
>> >
>> >
>> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> >
>> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> > for now.
>> >
>> >
>> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > I will start and add the branch_8x jobs to Jenkins once I have some time
>> >
>> > later today.
>> >
>> >
>> > The question: How to proceed with branch_7x? Should we stop using it
>> >
>> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> > the jenkins jobs enabled for a while.
>> >
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > From: Alan Woodward <ro...@gmail.com>
>> > Sent: Monday, January 7, 2019 11:30 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> >
>> > from master, and am in the process of updating the master branch to version
>> > 9.  New commits that should be included in the 8.0 release should also be
>> > back-ported to branch_8x from master.
>> >
>> >
>> > This is not intended as a feature freeze, as I know there are still some
>> >
>> > things being worked on for 8.0; however, it should let us clean up master by
>> > removing as much deprecated code as possible, and give us an idea of any
>> > replacement work that needs to be done.
>> >
>> >
>> >
>> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > January.
>> >
>> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > It would be nice to see Solr 8 in January soon as there is an enhancement
>> >
>> > on nested-documents we are waiting to get our hands on.
>> >
>> > Any idea when Solr 8 would be out ?
>> >
>> > Thx
>> > SG
>> >
>> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >
>> > <da...@gmail.com> wrote:
>> >
>> >
>> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> >
>> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> >
>> >  click here:
>> >
>> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >
>> >
>> > Thru the end of the month, I intend to work on those issues not yet
>> >
>> > assigned.
>> >
>> >
>> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > +1
>> >
>> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >
>> > <ro...@gmail.com> wrote:
>> >
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> >
>> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> > branch this week - say Wednesday?  Then we should have some time to
>> > clean up the master branch and uncover anything that still needs to be done
>> > on 8.0 before we start the release process next year.
>> >
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > 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
>> >
>> > <er...@gmail.com> 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 <ji...@gmail.com>
>> >
>> > 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
>> >
>> > <da...@gmail.com> a écrit :
>> >
>> >
>> > +1 to a 7.6 —lots of stuff in there
>> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >
>> > <nk...@gmail.com> 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
>> >
>> > <ca...@gmail.com> 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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <er...@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
>> >
>> > <da...@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
>> >
>> > <ji...@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%3DBlocke
>> > r%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
>> >
>> > <jp...@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
>> >
>> > <jp...@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%3DBlocke
>> > r%20and%20resolution%20%3D%20Unresolved%20
>> >
>> >
>> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> >
>> > <ji...@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
>> >
>> > <er...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <da...@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 --
>> >
>> > &g
>> >
>> >
>> >
>> >
>> > --
>> > Sincerely yours
>> > Mikhail Khludnev
>> >
>> >
>> >
>> >
>> >
>> > --
>> > -----------------------------------------------------
>> > Noble Paul
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Fwd: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

On Tue, Apr 30, 2019 at 9:27 AM Cassandra Targett <ca...@gmail.com>
wrote:

> I have a number of changes in a local branch for the 8.0 Ref Guide page
> “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended
> to push my branch, but I could if it helps.
>

About 30min ago I updated the release highlights for 8.0 to the Solr
news.html.  I took it off the updated wiki version (thanks to Dat for the
updated HTTP/2 notes).
We could update it further if you/anyone wants but I think it's fine now.
It was not fine before.

I also have a bunch of unfinished content I started about nested documents,
> but tearing apart the CHANGES.txt to figure out what is new and how that
> impacts upgrades is incredibly painful and time-consuming, and I don’t have
> a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.
>

Maybe perfection is the enemy of good-enough here?  Perfection might not be
the right word... I sympathize it's tough to let go of an ideal.
We want Solr and the Ref Guide to be the best it can be yet we only have so
much time to do so.


> Tangentially, I feel like we need to work something else out about Wiki
> release notes (and, remember, wiki.apache.org is going away really soon
> now) and the Ref Guide. It’s odd to me that one person decides how to
> present what’s new in the Wiki release notes, and someone else decides how
> to present a whole other set of content about the same set of features for
> the Ref Guide. Usually I skip the what’s new part for the minor releases,
> but for major ones, there needs to be a comprehensive “here’s what’s new
> and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the
> major version process now.
>

Good point.  Hmmm.  Perhaps then the what's-new should be extracted from
the ref guide and not authored in the wiki?
The wiki could contain a template with a INSERT-HERE for the relevant part
of the ref guide, since this is used as an announcement.
Such a proposal means ensuring every release has its highlights in the ref
guide, not just major ones.
The "major-changes-in-solr-8.adoc" could become simply
"changes-in-solr-8.adoc" with a "Major changes in 8.0" *section/heading*,
and with a separate part enumerating minor releases.
WDYT?  At least then when working on a big issue I might at least add a
place-holder to this page if not an actual highlight note.

As an aside; I wonder what email client you use.  In Gmail web view, your
email doesn't wrap so I have to scroll horizontally, which sucks.

~ David


> Anyway, let me know if you want to see what I have so far, and I’ll try to
> find some time to push it or make a patch.
> On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>,
> wrote:
>
> Hi Dat,
>
> I plan to update Solr's release notes for 8.0 retroactively.
> https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs;
> I wrote this well over a month ago.  Can you please enhance the part on
> HTTP2 to be more informative?  For example... what *benefit* does HTTP2
> bring to internode communication?  I know you benchmarked things.  Maybe
> mention the road to full HTTP2 continues into 8.x?
>
> I'm sending this to the dev list so really anyone else can help like list
> other major features... though I think maybe it's just these two.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> ---------- Forwarded message ---------
> From: David Smiley <da...@gmail.com>
> Date: Thu, Mar 14, 2019 at 9:34 AM
> Subject: Re: Lucene/Solr 8.0
> To: Solr/Lucene Dev <de...@lucene.apache.org>
>
>
> The Solr highlights section of the announcement is severely incomplete as
> to appear embarrassing.
> In the absence of time/effort to fix it should have simply been omitted;
> the CHANGES.txt has details.
> That would not have been embarrassing.
> Maybe next time we could have a call to action about the release
> highlights that coincides with the creation of the release branch;
> that is a juncture in which the features are frozen and there's plenty of
> time to update.
> Last night I saw the call to action but it was woefully too late for me to
> help.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
>
>> I organized existing items of the Lucene release notes into sections
>> and added a new item about FeatureField,
>> LongPoint#newDistanceFeatureQuery and
>> LatLonPoint#newDistanceFeatureQuery.
>>
>> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> > Jim and I have created wiki pages for the 8.0 release highlights here:
>> > https://wiki.apache.org/solr/ReleaseNote80
>> > https://wiki.apache.org/lucene-java/ReleaseNote80
>> >
>> > Feel free to edit and improve them - the Solr one in particular could
>> do with some beefing up.
>> >
>> >
>> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>> >
>> > I'm committing them,
>> > Thanks Ishan
>> >
>> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > Awesome, thank you Ishan!
>> >
>> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
>> ichattopadhyaya@gmail.com> wrote:
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?
>> >
>> > I can volunteer for 7.7.1. I'll start as soon as both these issues are
>> committed.
>> >
>> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > We have two Solr issues that are serious enough to warrant a 7.7.1
>> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
>> guarantees, we should do this release before we restart the 8.0.0 process.
>> >
>> > Would anyone like to volunteer to be release manager for 7.7.1?
>> Ideally we would get this done quickly so that I can continue releasing
>> 8.0.0.
>> >
>> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org>
>> wrote:
>> >
>> >
>> > Thank you, Alan. Give me an hour.
>> >
>> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>> >
>> >
>> > OK, let’s do an RC2.  When do you think you can have a fix in?
>> >
>> > Mikhail, will you be able to get your fix in soon as well?
>> >
>> >
>> >
>> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>> >
>> >
>> >
>> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
>> wrote:
>> >
>> > Hi Alan,
>> >
>> > There is a work-around which is to change the default to using legacy
>> assignment using cluster properties. But I don't like the idea of releasing
>> something that we know is broken and asking everyone to set a cluster
>> property to workaround it. I'd rather just rollback the commits that caused
>> the problem and then release 8.0
>> >
>> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > Hi Shalin,
>> >
>> > I'm not familiar with this bit of code - is there a workaround
>> available?  ie a way of using a different replica placement strategy when
>> creating a collection?  If there is, I'd be tempted to continue with the
>> vote as is and then do an immediate 8.0.1 release once you have things
>> fixed, particularly if we’re going to require a 7.7.1 as well.
>> >
>> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
>> wrote:
>> >
>> > Hi Alan,
>> >
>> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
>> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
>> interest of time, I propose rolling back SOLR-12739 which caused these
>> issues. We can re-introduce it with proper fixes for the related issues in
>> 8.1.
>> >
>> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > The release candidate has already been built and voting is in progress,
>> so it’s missed the boat unless there’s a respin.  It does look like a nasty
>> bug though, so if you have a fix then feel free too commit it to the 8_0
>> branch in case we do an 8.0.1 release.
>> >
>> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>> >
>> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>> >
>> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > I have no problem with bug-fixes and ref-guide changes on the 8_0
>> branch.
>> >
>> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>> wrote:
>> >
>> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
>> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>> since there’s a lot of editing yet to be done for it.
>> >
>> > Cassandra
>> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>> wrote:
>> >
>> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129
>> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include
>> this even if it's committed after the 8.0 for the code?  I could avoid
>> touching CHANGES.txt if that helps (it'd be of dubious value to users
>> browsing the change list any way).
>> >
>> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > Thanks for letting me know Jason.  Your commit will have missed the
>> cut, yes, but I don’t think it matters that much.  It will get picked up in
>> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
>> then we can just alter CHANGES.txt
>> >
>> >
>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>> wrote:
>> >
>> > Hey Alan,
>> >
>> > I just committed a minor inconsequential bugfix
>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>> > realize I was cutting it so close to your work on cutting RC1, but
>> > from commits I see you made this morning preparing for the RC I
>> > suspect I cut things _very_ close and just missed it.
>> >
>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>> > problems for you on the release end.  I'm happy to do whatever's
>> > easiest for you regarding that commit.  It'd be nice to have it
>> > included in 8.0, but it's not imperative by any means if I've already
>> > missed the first RC, or it's easier for you to omit from potential
>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>> > go back and update CHANGES.txt I think.
>> >
>> > Sorry again for the potential complication.  I hate to be "that guy".
>> > Thanks for stepping up and handling the release.
>> >
>> > Best,
>> >
>> > Jason
>> >
>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>> wrote:
>> >
>> >
>> > Thanks for fixing Cassandra and sorry for the noise. I did this too
>> many times in the past so I just mechanically changed the redirect without
>> thinking of when or if the ref guide was also released.
>> > I'll be more careful next time ;).
>> >
>> > On another note, now that 7.7 is out and that we're preparing the
>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>> was already discussed some time ago
>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
>> reached a consensus and we have maybe new options with the move to gitbox.
>> One option discussed in the thread was to remove all files and add a README
>> that says that this branch is dead. I don't know if it's possible but we
>> could also make the branch protected in gitbox in order to avoid new
>> commits. What do you think ? Should we keep this branch and just consider
>> new commits as useless or should we try to "clean up" all Nx branches that
>> are not active anymore (5x, 6x, 7x) ?
>> >
>> > Jim
>> >
>> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com>
>> a écrit :
>> >
>> >
>> > I’d like to remind RMs that when finishing up a release, we can’t just
>> do a blanket find/replace in .htaccess to update the version. If we’re not
>> going to coordinate binary releases with Ref Guide releases, we need to be
>> careful not to change the redirects unless that version’s Ref Guide release
>> is also imminent.
>> >
>> > This is noted in the ReleaseToDo (
>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>> but I’ve seen it occur a little too soon for the past few releases…in those
>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>> >
>> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
>> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
>> needs to maybe take care of it), but all non-version specific Ref Guide
>> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
>> we have an easy way to avoid routing people to dead links.
>> >
>> > Cassandra
>> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>> wrote:
>> >
>> > Once 7.7 is out the door, we should get on with releasing 8.0.  I
>> volunteer to be the manager for this round.  My current plan is to build a
>> release candidate early next week, as soon as the 7.7 release has been
>> announced.
>> >
>> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > It is a shame, I agree, but some of this stuff has been deprecated
>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>> cleaning this stuff up once 8.0 is out of the door though.
>> >
>> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>> >
>> > Okay.  I suppose the issue is that it's simply too late in the 8.0
>> cycle to remove things that have been deprecated in previous releases?
>> solr.LatLonType is one example.  It's a shame to keep around such things
>> further.
>> >
>> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> >
>> > Not quite - the plan is to remove things entirely in 9.0, but we may
>> need to back port some extra deprecations to 8x.  We don’t necessarily need
>> them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
>> problems.  I opened the issues to ensure that we didn’t keep carrying
>> deprecated code through any further releases.
>> >
>> >
>> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>> >
>> > I want to ensure people are aware of two issues "Remove deprecated code
>> in master" that Alan filed:
>> >
>> > https://issues.apache.org/jira/browse/SOLR-13138
>> > https://issues.apache.org/jira/browse/LUCENE-8638
>> > There's a "master-deprecations" branch as well.
>> >
>> > Although both issues are marked "master (9.0)", I think the intent is
>> actually 8.0 so that we are finally rid of the deprecated code?
>> >
>> > ~ David
>> >
>> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> > I'm keeping any eye on the builds this weekend but all indications are
>> > no issues so far.
>> >
>> > Kevin Risden
>> >
>> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Nick, this change seems to be causing test failures. Can you have a
>> look?
>> >
>> > See eg.
>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>> wrote:
>> >
>> >
>> > Thank you Jim. LUCENE-8669 has been merged.
>> >
>> > - Nick
>> >
>> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
>> wrote:
>> >
>> >
>> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
>> first RC when your patch is merged.
>> > Kevin, this looks like a big change so I am not sure if it's a good
>> idea to rush this in for 8.0. Would it be safer to target another version
>> in order to take some time to ensure that it's not breaking anything ? I
>> guess that your concern is that a change like this should happen in a major
>> version but I wonder if it's worth the risk. I don't know this part of the
>> code and the implications of such a change so I let you decide what we
>> should do here but let's not delay the release if we realize that this
>> change requires more than a few days to be merged.
>> >
>> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
>> écrit :
>> >
>> >
>> > Hey Jim,
>> >
>> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along
>> with a pretty straightforward patch. This is a critical one that I think
>> needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> >
>> > On Wed, Jan 30, 2019 at 1:07 PM
>> >
>> > Kevin Risden <kr...@apache.org> wrote:
>> >
>> >
>> > Jim,
>> >
>> > Since 7.7 needs to be released before 8.0 does that leave time to get
>> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> > currently under review.
>> >
>> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> > feel this should make it into 8.0 or not.
>> >
>> > Kevin Risden
>> >
>> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
>> wrote:
>> >
>> >
>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
>> don't handle two concurrent releases in our tests (
>> https://issues.apache.org/jira/browse/LUCENE-8665).
>> > Since we want to release 7.7 first I created the Jenkins job for this
>> version only and will build the first candidate for this version later this
>> week if there are no objection.
>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> >
>> >
>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
>> écrit :
>> >
>> >
>> > Hi,
>> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now
>> create the Jenkins tasks for these versions, Uwe can you also add them to
>> the Policeman's Jenkins job ?
>> > This also means that the feature freeze phase has started for both
>> versions (7.7 and 8.0):
>> >
>> > No new features may be committed to the branch.
>> > Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you want to
>> commit to Jira first to give others the chance to review and possibly vote
>> against the patch. Keep in mind that it is our main intention to keep the
>> branch as stable as possible.
>> > All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into the
>> current release branch.
>> > Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch while
>> the branch feature freeze is in effect, think twice: can't the addition
>> wait a couple more days? Merges of bug fixes into the branch may become
>> more difficult.
>> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will
>> delay a release candidate build.
>> >
>> >
>> > Thanks,
>> > Jim
>> >
>> >
>> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >
>> >
>> > sure, thanks Jim!
>> >
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > <ji...@gmail.com> ha scritto:
>> >
>> >
>> > Go ahead Tommaso the branch is not created yet.
>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
>> and to announce the feature freeze the same day.
>> > For blocker issues that are still open this leaves another week to work
>> on a patch and we can update the status at the end of the week in order to
>> decide if we can start the first build candidate
>> > early next week. Would that work for you ?
>> >
>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >
>> >
>> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >
>> > Regards,
>> > Tommaso
>> >
>> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > <jp...@gmail.com> ha scritto:
>> >
>> >
>> > Hi Noble,
>> >
>> > No it hasn't created yet.
>> >
>> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
>> wrote:
>> >
>> >
>> > Is the branch already cut for 8.0? which is it?
>> >
>> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com>
>> wrote:
>> >
>> >
>> > I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> > I will work on some documentation for it this week -- SOLR-13129
>> >
>> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com>
>> wrote:
>> >
>> >
>> > I don't think it is critical for this to be a blocker for 8.0. If it
>> gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> > I think we should simply remove the buffering feature in the UI and
>> replace it with an error message popup or something.
>> > I'll try to take a look next week.
>> >
>> > --
>> > Jan Høydahl, search solution architect
>> > Cominvent AS - www.cominvent.com
>> >
>> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> >
>> > I think the UI is an important Solr feature. As long as there is a
>> reasonable time horizon for the issue being resolved I'm +1 on making it a
>> blocker. I'm not familiar enough with the UI code to help either
>> unfortunately.
>> >
>> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > It looks like someone tried to make it a blocker once before... And
>> it's actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it rather than browsing away or closing the
>> window, not knowing that it's silently pumping out requests after showing
>> an error... would completely hose a node, and until they tracked down the
>> source of the requests, (hope he didn't go home) it would be impossible to
>> resolve...
>> >
>> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> >
>> > Releasing a new major is very challenging on its own, I'd rather not
>> > call it a blocker and delay the release for it since this isn't a new
>> > regression in 8.0: it looks like a problem that has affected Solr
>> > since at least 6.3? I'm not familiar with the UI code at all, but
>> > maybe this is something that could get fixed before we build a RC?
>> >
>> >
>> >
>> >
>> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>> >
>> >
>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> >
>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> >
>> > Cool,
>> >
>> > I am working on giving my best release time guess as possible on the
>> FOSDEM conference!
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > -----Original Message-----
>> > From: Adrien Grand <jp...@gmail.com>
>> > Sent: Thursday, January 24, 2019 5:33 PM
>> > To: Lucene Dev <de...@lucene.apache.org>
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> >
>> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>> > wrote:
>> >
>> >
>> > Hi,
>> > As we agreed some time ago I'd like to start on releasing 8.0. The
>> branch is
>> >
>> > already created so we can start the process anytime now. Unless there
>> are
>> > objections I'd like to start the feature freeze next week in order to
>> build the
>> > first candidate the week after.
>> >
>> > We'll also need a 7.7 release but I think we can handle both with Alan
>> so
>> >
>> > the question now is whether we are ok to start the release process or
>> if there
>> > are any blockers left ;).
>> >
>> >
>> >
>> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>> >
>> > a écrit :
>> >
>> >
>> > I’ve started to work through the various deprecations on the new master
>> >
>> > branch.  There are a lot of them, and I’m going to need some assistance
>> for
>> > several of them, as it’s not entirely clear what to do.
>> >
>> >
>> > I’ll open two overarching issues in JIRA, one for lucene and one for
>> Solr,
>> >
>> > with lists of the deprecations that need to be removed in each one.
>> I’ll create
>> > a shared branch on gitbox to work against, and push the changes I’ve
>> already
>> > done there.  We can then create individual JIRA issues for any changes
>> that
>> > are more involved than just deleting code.
>> >
>> >
>> > All assistance gratefully received, particularly for the Solr
>> deprecations
>> >
>> > where there’s a lot of code I’m unfamiliar with.
>> >
>> >
>> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > I think the current plan is to do a 7.7 release at the same time as
>> 8.0, to
>> >
>> > handle any last-minute deprecations etc.  So let’s keep those jobs
>> enabled
>> > for now.
>> >
>> >
>> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> >
>> > Hi,
>> >
>> > I will start and add the branch_8x jobs to Jenkins once I have some time
>> >
>> > later today.
>> >
>> >
>> > The question: How to proceed with branch_7x? Should we stop using it
>> >
>> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes),
>> or
>> > are we planning to one more Lucene/Solr 7.7? In the latter case I would
>> keep
>> > the jenkins jobs enabled for a while.
>> >
>> >
>> > Uwe
>> >
>> > -----
>> > Uwe Schindler
>> > Achterdiek 19, D-28357 Bremen
>> > http://www.thetaphi.de
>> > eMail: uwe@thetaphi.de
>> >
>> > From: Alan Woodward <ro...@gmail.com>
>> > Sent: Monday, January 7, 2019 11:30 AM
>> > To: dev@lucene.apache.org
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> >
>> > from master, and am in the process of updating the master branch to
>> version
>> > 9.  New commits that should be included in the 8.0 release should also
>> be
>> > back-ported to branch_8x from master.
>> >
>> >
>> > This is not intended as a feature freeze, as I know there are still some
>> >
>> > things being worked on for 8.0; however, it should let us clean up
>> master by
>> > removing as much deprecated code as possible, and give us an idea of any
>> > replacement work that needs to be done.
>> >
>> >
>> >
>> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > January.
>> >
>> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > It would be nice to see Solr 8 in January soon as there is an
>> enhancement
>> >
>> > on nested-documents we are waiting to get our hands on.
>> >
>> > Any idea when Solr 8 would be out ?
>> >
>> > Thx
>> > SG
>> >
>> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >
>> > <da...@gmail.com> wrote:
>> >
>> >
>> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE)
>> AND
>> >
>> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> >
>> >  click here:
>> >
>> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >
>> >
>> > Thru the end of the month, I intend to work on those issues not yet
>> >
>> > assigned.
>> >
>> >
>> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > +1
>> >
>> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >
>> > <ro...@gmail.com> wrote:
>> >
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> >
>> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
>> create the
>> > branch this week - say Wednesday?  Then we should have some time to
>> > clean up the master branch and uncover anything that still needs to be
>> done
>> > on 8.0 before we start the release process next year.
>> >
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> >
>> > wrote:
>> >
>> >
>> > 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
>> >
>> > <er...@gmail.com> 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 <ji...@gmail.com>
>> >
>> > 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
>> >
>> > <da...@gmail.com> a écrit :
>> >
>> >
>> > +1 to a 7.6 —lots of stuff in there
>> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >
>> > <nk...@gmail.com> 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
>> >
>> > <ca...@gmail.com> 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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <ca...@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
>> >
>> > <er...@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
>> >
>> > <da...@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
>> >
>> > <ji...@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%3DBlocke
>> > r%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
>> >
>> > <jp...@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
>> >
>> > <jp...@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%3DBlocke
>> > r%20and%20resolution%20%3D%20Unresolved%20
>> >
>> >
>> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> >
>> > <ji...@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
>> >
>> > <er...@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
>> >
>> > <ca...@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
>> >
>> > <ji...@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
>> >
>> > <da...@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 --
>> >
>> > &g
>> >
>> >
>> >
>> >
>> > --
>> > Sincerely yours
>> > Mikhail Khludnev
>> >
>> >
>> >
>> >
>> >
>> > --
>> > -----------------------------------------------------
>> > Noble Paul
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Re: Fwd: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

I have a number of changes in a local branch for the 8.0 Ref Guide page “Major Changes in Solr 8” about HTTP/2 which might help. I hadn’t intended to push my branch, but I could if it helps. I also have a bunch of unfinished content I started about nested documents, but tearing apart the CHANGES.txt to figure out what is new and how that impacts upgrades is incredibly painful and time-consuming, and I don’t have a ton of time these days. This is why the 8.0 Ref Guide isn’t out yet.

Tangentially, I feel like we need to work something else out about Wiki release notes (and, remember, wiki.apache.org is going away really soon now) and the Ref Guide. It’s odd to me that one person decides how to present what’s new in the Wiki release notes, and someone else decides how to present a whole other set of content about the same set of features for the Ref Guide. Usually I skip the what’s new part for the minor releases, but for major ones, there needs to be a comprehensive “here’s what’s new and what’s changed” - we’ve done it for 5->6 and 6->7, it’s part of the major version process now.

Anyway, let me know if you want to see what I have so far, and I’ll try to find some time to push it or make a patch.
On Apr 30, 2019, 8:00 AM -0500, David Smiley <da...@gmail.com>, wrote:
> Hi Dat,
>
> I plan to update Solr's release notes for 8.0 retroactively.   https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I wrote this well over a month ago.  Can you please enhance the part on HTTP2 to be more informative?  For example... what *benefit* does HTTP2 bring to internode communication?  I know you benchmarked things.  Maybe mention the road to full HTTP2 continues into 8.x?
>
> I'm sending this to the dev list so really anyone else can help like list other major features... though I think maybe it's just these two.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
> ---------- Forwarded message ---------
> > From: David Smiley <da...@gmail.com>
> > Date: Thu, Mar 14, 2019 at 9:34 AM
> > Subject: Re: Lucene/Solr 8.0
> > To: Solr/Lucene Dev <de...@lucene.apache.org>
> >
> >
> > The Solr highlights section of the announcement is severely incomplete as to appear embarrassing.
> > In the absence of time/effort to fix it should have simply been omitted; the CHANGES.txt has details.
> > That would not have been embarrassing.
> > Maybe next time we could have a call to action about the release highlights that coincides with the creation of the release branch;
> > that is a juncture in which the features are frozen and there's plenty of time to update.
> > Last night I saw the call to action but it was woefully too late for me to help.
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > > On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:
> > > > I organized existing items of the Lucene release notes into sections
> > > > and added a new item about FeatureField,
> > > > LongPoint#newDistanceFeatureQuery and
> > > > LatLonPoint#newDistanceFeatureQuery.
> > > >
> > > > On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > > Jim and I have created wiki pages for the 8.0 release highlights here:
> > > > > https://wiki.apache.org/solr/ReleaseNote80
> > > > > https://wiki.apache.org/lucene-java/ReleaseNote80
> > > > >
> > > > > Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
> > > > >
> > > > >
> > > > > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> > > > >
> > > > > I'm committing them,
> > > > > Thanks Ishan
> > > > >
> > > > > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Awesome, thank you Ishan!
> > > > >
> > > > > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> > > > >
> > > > > Would anyone like to volunteer to be release manager for 7.7.1?
> > > > >
> > > > > I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
> > > > >
> > > > > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
> > > > >
> > > > > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
> > > > >
> > > > > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> > > > >
> > > > > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
> > > > >
> > > > >
> > > > > Thank you, Alan. Give me an hour.
> > > > >
> > > > > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> > > > >
> > > > >
> > > > > OK, let’s do an RC2.  When do you think you can have a fix in?
> > > > >
> > > > > Mikhail, will you be able to get your fix in soon as well?
> > > > >
> > > > >
> > > > >
> > > > > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> > > > >
> > > > >
> > > > >
> > > > > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > > > >
> > > > > Hi Alan,
> > > > >
> > > > > There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> > > > >
> > > > > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Hi Shalin,
> > > > >
> > > > > I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> > > > >
> > > > > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> > > > >
> > > > > Hi Alan,
> > > > >
> > > > > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
> > > > >
> > > > > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
> > > > >
> > > > > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> > > > >
> > > > > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> > > > >
> > > > > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> > > > >
> > > > > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
> > > > >
> > > > > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
> > > > >
> > > > > Cassandra
> > > > > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
> > > > >
> > > > > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
> > > > >
> > > > > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
> > > > >
> > > > >
> > > > > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> > > > >
> > > > > Hey Alan,
> > > > >
> > > > > I just committed a minor inconsequential bugfix
> > > > > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > > > > realize I was cutting it so close to your work on cutting RC1, but
> > > > > from commits I see you made this morning preparing for the RC I
> > > > > suspect I cut things _very_ close and just missed it.
> > > > >
> > > > > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > > > > problems for you on the release end.  I'm happy to do whatever's
> > > > > easiest for you regarding that commit.  It'd be nice to have it
> > > > > included in 8.0, but it's not imperative by any means if I've already
> > > > > missed the first RC, or it's easier for you to omit from potential
> > > > > subsequent RCs.  Let me know if there's anything you'd like me to do
> > > > > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > > > > go back and update CHANGES.txt I think.
> > > > >
> > > > > Sorry again for the potential complication.  I hate to be "that guy".
> > > > > Thanks for stepping up and handling the release.
> > > > >
> > > > > Best,
> > > > >
> > > > > Jason
> > > > >
> > > > > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> > > > > I'll be more careful next time ;).
> > > > >
> > > > > On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
> > > > >
> > > > > Jim
> > > > >
> > > > > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
> > > > >
> > > > > This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > > > >
> > > > > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
> > > > >
> > > > > Cassandra
> > > > > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> > > > >
> > > > > Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
> > > > >
> > > > > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> > > > >
> > > > > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> > > > >
> > > > > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> > > > >
> > > > > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> > > > >
> > > > >
> > > > > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> > > > >
> > > > > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> > > > >
> > > > > https://issues.apache.org/jira/browse/SOLR-13138
> > > > > https://issues.apache.org/jira/browse/LUCENE-8638
> > > > > There's a "master-deprecations" branch as well.
> > > > >
> > > > > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> > > > >
> > > > > ~ David
> > > > >
> > > > > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> > > > >
> > > > >
> > > > > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > > > > I'm keeping any eye on the builds this weekend but all indications are
> > > > > no issues so far.
> > > > >
> > > > > Kevin Risden
> > > > >
> > > > > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Nick, this change seems to be causing test failures. Can you have a look?
> > > > >
> > > > > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > > > >
> > > > > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Thank you Jim. LUCENE-8669 has been merged.
> > > > >
> > > > > - Nick
> > > > >
> > > > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > > > > Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > > > >
> > > > > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > Hey Jim,
> > > > >
> > > > > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > > > >
> > > > > On Wed, Jan 30, 2019 at 1:07 PM
> > > > >
> > > > > Kevin Risden <kr...@apache.org> wrote:
> > > > >
> > > > >
> > > > > Jim,
> > > > >
> > > > > Since 7.7 needs to be released before 8.0 does that leave time to get
> > > > > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > > > > currently under review.
> > > > >
> > > > > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > > > > feel this should make it into 8.0 or not.
> > > > >
> > > > > Kevin Risden
> > > > >
> > > > > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> > > > > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > > > > I'll restore the version bump for 8.0 when 7.7 is out.
> > > > >
> > > > >
> > > > > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > Hi,
> > > > > Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > > > > This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > > > >
> > > > > No new features may be committed to the branch.
> > > > > Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > > > > All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > > > > Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > > > > Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > > > >
> > > > >
> > > > > Thanks,
> > > > > Jim
> > > > >
> > > > >
> > > > > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > sure, thanks Jim!
> > > > >
> > > > > Tommaso
> > > > >
> > > > > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > > > > <ji...@gmail.com> ha scritto:
> > > > >
> > > > >
> > > > > Go ahead Tommaso the branch is not created yet.
> > > > > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > > > > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > > > > early next week. Would that work for you ?
> > > > >
> > > > > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > > > > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > > > >
> > > > > Regards,
> > > > > Tommaso
> > > > >
> > > > > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > > > > <jp...@gmail.com> ha scritto:
> > > > >
> > > > >
> > > > > Hi Noble,
> > > > >
> > > > > No it hasn't created yet.
> > > > >
> > > > > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Is the branch already cut for 8.0? which is it?
> > > > >
> > > > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > > > > I will work on some documentation for it this week -- SOLR-13129
> > > > >
> > > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > > > >
> > > > >
> > > > > I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > > > I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > > > > I'll try to take a look next week.
> > > > >
> > > > > --
> > > > > Jan Høydahl, search solution architect
> > > > > Cominvent AS - www.cominvent.com
> > > > >
> > > > > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > > > >
> > > > > I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > > > >
> > > > > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > > > >
> > > > > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Releasing a new major is very challenging on its own, I'd rather not
> > > > > call it a blocker and delay the release for it since this isn't a new
> > > > > regression in 8.0: it looks like a problem that has affected Solr
> > > > > since at least 6.3? I'm not familiar with the UI code at all, but
> > > > > maybe this is something that could get fixed before we build a RC?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > > > >
> > > > > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > > > >
> > > > >
> > > > > Cool,
> > > > >
> > > > > I am working on giving my best release time guess as possible on the FOSDEM conference!
> > > > >
> > > > > Uwe
> > > > >
> > > > > -----
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > http://www.thetaphi.de
> > > > > eMail: uwe@thetaphi.de
> > > > >
> > > > > -----Original Message-----
> > > > > From: Adrien Grand <jp...@gmail.com>
> > > > > Sent: Thursday, January 24, 2019 5:33 PM
> > > > > To: Lucene Dev <de...@lucene.apache.org>
> > > > > Subject: Re: Lucene/Solr 8.0
> > > > >
> > > > > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > > > >
> > > > > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > > > > wrote:
> > > > >
> > > > >
> > > > > Hi,
> > > > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > > > >
> > > > > already created so we can start the process anytime now. Unless there are
> > > > > objections I'd like to start the feature freeze next week in order to build the
> > > > > first candidate the week after.
> > > > >
> > > > > We'll also need a 7.7 release but I think we can handle both with Alan so
> > > > >
> > > > > the question now is whether we are ok to start the release process or if there
> > > > > are any blockers left ;).
> > > > >
> > > > >
> > > > >
> > > > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > > > >
> > > > > a écrit :
> > > > >
> > > > >
> > > > > I’ve started to work through the various deprecations on the new master
> > > > >
> > > > > branch.  There are a lot of them, and I’m going to need some assistance for
> > > > > several of them, as it’s not entirely clear what to do.
> > > > >
> > > > >
> > > > > I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > > > >
> > > > > with lists of the deprecations that need to be removed in each one.  I’ll create
> > > > > a shared branch on gitbox to work against, and push the changes I’ve already
> > > > > done there.  We can then create individual JIRA issues for any changes that
> > > > > are more involved than just deleting code.
> > > > >
> > > > >
> > > > > All assistance gratefully received, particularly for the Solr deprecations
> > > > >
> > > > > where there’s a lot of code I’m unfamiliar with.
> > > > >
> > > > >
> > > > > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > > > >
> > > > > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > > > > for now.
> > > > >
> > > > >
> > > > > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > I will start and add the branch_8x jobs to Jenkins once I have some time
> > > > >
> > > > > later today.
> > > > >
> > > > >
> > > > > The question: How to proceed with branch_7x? Should we stop using it
> > > > >
> > > > > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > > > > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > > > > the jenkins jobs enabled for a while.
> > > > >
> > > > >
> > > > > Uwe
> > > > >
> > > > > -----
> > > > > Uwe Schindler
> > > > > Achterdiek 19, D-28357 Bremen
> > > > > http://www.thetaphi.de
> > > > > eMail: uwe@thetaphi.de
> > > > >
> > > > > From: Alan Woodward <ro...@gmail.com>
> > > > > Sent: Monday, January 7, 2019 11:30 AM
> > > > > To: dev@lucene.apache.org
> > > > > Subject: Re: Lucene/Solr 8.0
> > > > >
> > > > > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > > > >
> > > > > from master, and am in the process of updating the master branch to version
> > > > > 9.  New commits that should be included in the 8.0 release should also be
> > > > > back-ported to branch_8x from master.
> > > > >
> > > > >
> > > > > This is not intended as a feature freeze, as I know there are still some
> > > > >
> > > > > things being worked on for 8.0; however, it should let us clean up master by
> > > > > removing as much deprecated code as possible, and give us an idea of any
> > > > > replacement work that needs to be done.
> > > > >
> > > > >
> > > > >
> > > > > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > January.
> > > > >
> > > > > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > It would be nice to see Solr 8 in January soon as there is an enhancement
> > > > >
> > > > > on nested-documents we are waiting to get our hands on.
> > > > >
> > > > > Any idea when Solr 8 would be out ?
> > > > >
> > > > > Thx
> > > > > SG
> > > > >
> > > > > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > > >
> > > > > <da...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > > > >
> > > > > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > > > >
> > > > >  click here:
> > > > >
> > > > > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > > > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > > > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > > >
> > > > >
> > > > > Thru the end of the month, I intend to work on those issues not yet
> > > > >
> > > > > assigned.
> > > > >
> > > > >
> > > > > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > +1
> > > > >
> > > > > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > > >
> > > > > <ro...@gmail.com> wrote:
> > > > >
> > > > >
> > > > > Hi all,
> > > > >
> > > > > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > > > >
> > > > > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > > > > branch this week - say Wednesday?  Then we should have some time to
> > > > > clean up the master branch and uncover anything that still needs to be done
> > > > > on 8.0 before we start the release process next year.
> > > > >
> > > > >
> > > > > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > > > >
> > > > > wrote:
> > > > >
> > > > >
> > > > > 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
> > > > >
> > > > > <er...@gmail.com> 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 <ji...@gmail.com>
> > > > >
> > > > > 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
> > > > >
> > > > > <da...@gmail.com> a écrit :
> > > > >
> > > > >
> > > > > +1 to a 7.6 —lots of stuff in there
> > > > > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > > >
> > > > > <nk...@gmail.com> 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
> > > > >
> > > > > <ca...@gmail.com> 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
> > > > >
> > > > > <ji...@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
> > > > >
> > > > > <ca...@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
> > > > >
> > > > > <ji...@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
> > > > >
> > > > > <ca...@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
> > > > >
> > > > > <er...@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
> > > > >
> > > > > <da...@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
> > > > >
> > > > > <ji...@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%3DBlocke
> > > > > r%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
> > > > >
> > > > > <jp...@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
> > > > >
> > > > > <jp...@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%3DBlocke
> > > > > r%20and%20resolution%20%3D%20Unresolved%20
> > > > >
> > > > >
> > > > > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > > > >
> > > > > <ji...@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
> > > > >
> > > > > <er...@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
> > > > >
> > > > > <ca...@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
> > > > >
> > > > > <ji...@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
> > > > >
> > > > > <da...@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 --
> > > > >
> > > > > &g
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Sincerely yours
> > > > > Mikhail Khludnev
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > -----------------------------------------------------
> > > > > Noble Paul
> > > > >
> > > > > ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Adrien
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >

Fwd: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

Hi Dat,

I plan to update Solr's release notes for 8.0 retroactively.
https://wiki.apache.org/solr/ReleaseNote80 has more info on nested docs; I
wrote this well over a month ago.  Can you please enhance the part on HTTP2
to be more informative?  For example... what *benefit* does HTTP2 bring to
internode communication?  I know you benchmarked things.  Maybe mention the
road to full HTTP2 continues into 8.x?

I'm sending this to the dev list so really anyone else can help like list
other major features... though I think maybe it's just these two.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley

---------- Forwarded message ---------
From: David Smiley <da...@gmail.com>
Date: Thu, Mar 14, 2019 at 9:34 AM
Subject: Re: Lucene/Solr 8.0
To: Solr/Lucene Dev <de...@lucene.apache.org>


The Solr highlights section of the announcement is severely incomplete as
to appear embarrassing.
In the absence of time/effort to fix it should have simply been omitted;
the CHANGES.txt has details.
That would not have been embarrassing.
Maybe next time we could have a call to action about the release highlights
that coincides with the creation of the release branch;
that is a juncture in which the features are frozen and there's plenty of
time to update.
Last night I saw the call to action but it was woefully too late for me to
help.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:

> I organized existing items of the Lucene release notes into sections
> and added a new item about FeatureField,
> LongPoint#newDistanceFeatureQuery and
> LatLonPoint#newDistanceFeatureQuery.
>
> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> > Jim and I have created wiki pages for the 8.0 release highlights here:
> > https://wiki.apache.org/solr/ReleaseNote80
> > https://wiki.apache.org/lucene-java/ReleaseNote80
> >
> > Feel free to edit and improve them - the Solr one in particular could do
> with some beefing up.
> >
> >
> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> >
> > I'm committing them,
> > Thanks Ishan
> >
> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Awesome, thank you Ishan!
> >
> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >
> > Would anyone like to volunteer to be release manager for 7.7.1?
> >
> > I can volunteer for 7.7.1. I'll start as soon as both these issues are
> committed.
> >
> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
> >
> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally
> we would get this done quickly so that I can continue releasing 8.0.0.
> >
> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> >
> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org>
> wrote:
> >
> >
> > Thank you, Alan. Give me an hour.
> >
> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> >
> >
> > OK, let’s do an RC2.  When do you think you can have a fix in?
> >
> > Mikhail, will you be able to get your fix in soon as well?
> >
> >
> >
> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> >
> >
> >
> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
> >
> > Hi Alan,
> >
> > There is a work-around which is to change the default to using legacy
> assignment using cluster properties. But I don't like the idea of releasing
> something that we know is broken and asking everyone to set a cluster
> property to workaround it. I'd rather just rollback the commits that caused
> the problem and then release 8.0
> >
> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Hi Shalin,
> >
> > I'm not familiar with this bit of code - is there a workaround
> available?  ie a way of using a different replica placement strategy when
> creating a collection?  If there is, I'd be tempted to continue with the
> vote as is and then do an immediate 8.0.1 release once you have things
> fixed, particularly if we’re going to require a 7.7.1 as well.
> >
> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
> >
> > Hi Alan,
> >
> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
> interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
> >
> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > The release candidate has already been built and voting is in progress,
> so it’s missed the boat unless there’s a respin.  It does look like a nasty
> bug though, so if you have a fix then feel free too commit it to the 8_0
> branch in case we do an 8.0.1 release.
> >
> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> >
> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> >
> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> >
> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
> wrote:
> >
> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
> since there’s a lot of editing yet to be done for it.
> >
> > Cassandra
> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
> wrote:
> >
> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129
> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include
> this even if it's committed after the 8.0 for the code?  I could avoid
> touching CHANGES.txt if that helps (it'd be of dubious value to users
> browsing the change list any way).
> >
> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Thanks for letting me know Jason.  Your commit will have missed the cut,
> yes, but I don’t think it matters that much.  It will get picked up in a
> respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
> >
> >
> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> >
> > Hey Alan,
> >
> > I just committed a minor inconsequential bugfix
> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > realize I was cutting it so close to your work on cutting RC1, but
> > from commits I see you made this morning preparing for the RC I
> > suspect I cut things _very_ close and just missed it.
> >
> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > problems for you on the release end.  I'm happy to do whatever's
> > easiest for you regarding that commit.  It'd be nice to have it
> > included in 8.0, but it's not imperative by any means if I've already
> > missed the first RC, or it's easier for you to omit from potential
> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > go back and update CHANGES.txt I think.
> >
> > Sorry again for the potential complication.  I hate to be "that guy".
> > Thanks for stepping up and handling the release.
> >
> > Best,
> >
> > Jason
> >
> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > Thanks for fixing Cassandra and sorry for the noise. I did this too many
> times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> > I'll be more careful next time ;).
> >
> > On another note, now that 7.7 is out and that we're preparing the
> release for 8.0 what do you think of removing/nuking the 7x branch. This
> was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> >
> > Jim
> >
> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com>
> a écrit :
> >
> >
> > I’d like to remind RMs that when finishing up a release, we can’t just
> do a blanket find/replace in .htaccess to update the version. If we’re not
> going to coordinate binary releases with Ref Guide releases, we need to be
> careful not to change the redirects unless that version’s Ref Guide release
> is also imminent.
> >
> > This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> >
> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
> needs to maybe take care of it), but all non-version specific Ref Guide
> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
> we have an easy way to avoid routing people to dead links.
> >
> > Cassandra
> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
> >
> > Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
> >
> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> >
> > It is a shame, I agree, but some of this stuff has been deprecated since
> 3.6, so another release cycle won’t hurt :). We should prioritise cleaning
> this stuff up once 8.0 is out of the door though.
> >
> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> >
> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle
> to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> >
> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Not quite - the plan is to remove things entirely in 9.0, but we may
> need to back port some extra deprecations to 8x.  We don’t necessarily need
> them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
> >
> >
> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> >
> > I want to ensure people are aware of two issues "Remove deprecated code
> in master" that Alan filed:
> >
> > https://issues.apache.org/jira/browse/SOLR-13138
> > https://issues.apache.org/jira/browse/LUCENE-8638
> > There's a "master-deprecations" branch as well.
> >
> > Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
> >
> > ~ David
> >
> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> >
> >
> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > I'm keeping any eye on the builds this weekend but all indications are
> > no issues so far.
> >
> > Kevin Risden
> >
> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> >
> >
> > Nick, this change seems to be causing test failures. Can you have a look?
> >
> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> >
> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> >
> >
> > Thank you Jim. LUCENE-8669 has been merged.
> >
> > - Nick
> >
> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
> first RC when your patch is merged.
> > Kevin, this looks like a big change so I am not sure if it's a good idea
> to rush this in for 8.0. Would it be safer to target another version in
> order to take some time to ensure that it's not breaking anything ? I guess
> that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
> >
> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
> écrit :
> >
> >
> > Hey Jim,
> >
> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along
> with a pretty straightforward patch. This is a critical one that I think
> needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> >
> > On Wed, Jan 30, 2019 at 1:07 PM
> >
> > Kevin Risden <kr...@apache.org> wrote:
> >
> >
> > Jim,
> >
> > Since 7.7 needs to be released before 8.0 does that leave time to get
> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > currently under review.
> >
> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > feel this should make it into 8.0 or not.
> >
> > Kevin Risden
> >
> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
> don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > Since we want to release 7.7 first I created the Jenkins job for this
> version only and will build the first candidate for this version later this
> week if there are no objection.
> > I'll restore the version bump for 8.0 when 7.7 is out.
> >
> >
> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
> écrit :
> >
> >
> > Hi,
> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now
> create the Jenkins tasks for these versions, Uwe can you also add them to
> the Policeman's Jenkins job ?
> > This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
> >
> > No new features may be committed to the branch.
> > Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > All patches that are intended for the branch should first be committed
> to the unstable branch, merged into the stable branch, and then into the
> current release branch.
> > Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch while
> the branch feature freeze is in effect, think twice: can't the addition
> wait a couple more days? Merges of bug fixes into the branch may become
> more difficult.
> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will
> delay a release candidate build.
> >
> >
> > Thanks,
> > Jim
> >
> >
> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >
> >
> > sure, thanks Jim!
> >
> > Tommaso
> >
> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > <ji...@gmail.com> ha scritto:
> >
> >
> > Go ahead Tommaso the branch is not created yet.
> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
> and to announce the feature freeze the same day.
> > For blocker issues that are still open this leaves another week to work
> on a patch and we can update the status at the end of the week in order to
> decide if we can start the first build candidate
> > early next week. Would that work for you ?
> >
> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >
> >
> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >
> > Regards,
> > Tommaso
> >
> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > <jp...@gmail.com> ha scritto:
> >
> >
> > Hi Noble,
> >
> > No it hasn't created yet.
> >
> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> >
> >
> > Is the branch already cut for 8.0? which is it?
> >
> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com>
> wrote:
> >
> >
> > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > I will work on some documentation for it this week -- SOLR-13129
> >
> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> >
> > I don't think it is critical for this to be a blocker for 8.0. If it
> gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> > I'll try to take a look next week.
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> >
> > I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> >
> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> >
> >
> > It looks like someone tried to make it a blocker once before... And it's
> actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> >
> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> >
> >
> > Releasing a new major is very challenging on its own, I'd rather not
> > call it a blocker and delay the release for it since this isn't a new
> > regression in 8.0: it looks like a problem that has affected Solr
> > since at least 6.3? I'm not familiar with the UI code at all, but
> > maybe this is something that could get fixed before we build a RC?
> >
> >
> >
> >
> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >
> >
> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >
> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >
> >
> > Cool,
> >
> > I am working on giving my best release time guess as possible on the
> FOSDEM conference!
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > -----Original Message-----
> > From: Adrien Grand <jp...@gmail.com>
> > Sent: Thursday, January 24, 2019 5:33 PM
> > To: Lucene Dev <de...@lucene.apache.org>
> > Subject: Re: Lucene/Solr 8.0
> >
> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >
> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > wrote:
> >
> >
> > Hi,
> > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> >
> > already created so we can start the process anytime now. Unless there are
> > objections I'd like to start the feature freeze next week in order to
> build the
> > first candidate the week after.
> >
> > We'll also need a 7.7 release but I think we can handle both with Alan so
> >
> > the question now is whether we are ok to start the release process or if
> there
> > are any blockers left ;).
> >
> >
> >
> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >
> > a écrit :
> >
> >
> > I’ve started to work through the various deprecations on the new master
> >
> > branch.  There are a lot of them, and I’m going to need some assistance
> for
> > several of them, as it’s not entirely clear what to do.
> >
> >
> > I’ll open two overarching issues in JIRA, one for lucene and one for
> Solr,
> >
> > with lists of the deprecations that need to be removed in each one.
> I’ll create
> > a shared branch on gitbox to work against, and push the changes I’ve
> already
> > done there.  We can then create individual JIRA issues for any changes
> that
> > are more involved than just deleting code.
> >
> >
> > All assistance gratefully received, particularly for the Solr
> deprecations
> >
> > where there’s a lot of code I’m unfamiliar with.
> >
> >
> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >
> > wrote:
> >
> >
> > I think the current plan is to do a 7.7 release at the same time as 8.0,
> to
> >
> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > for now.
> >
> >
> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >
> > Hi,
> >
> > I will start and add the branch_8x jobs to Jenkins once I have some time
> >
> > later today.
> >
> >
> > The question: How to proceed with branch_7x? Should we stop using it
> >
> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > are we planning to one more Lucene/Solr 7.7? In the latter case I would
> keep
> > the jenkins jobs enabled for a while.
> >
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > From: Alan Woodward <ro...@gmail.com>
> > Sent: Monday, January 7, 2019 11:30 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Lucene/Solr 8.0
> >
> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >
> > from master, and am in the process of updating the master branch to
> version
> > 9.  New commits that should be included in the 8.0 release should also be
> > back-ported to branch_8x from master.
> >
> >
> > This is not intended as a feature freeze, as I know there are still some
> >
> > things being worked on for 8.0; however, it should let us clean up
> master by
> > removing as much deprecated code as possible, and give us an idea of any
> > replacement work that needs to be done.
> >
> >
> >
> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >
> > wrote:
> >
> >
> > January.
> >
> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >
> > wrote:
> >
> >
> > It would be nice to see Solr 8 in January soon as there is an enhancement
> >
> > on nested-documents we are waiting to get our hands on.
> >
> > Any idea when Solr 8 would be out ?
> >
> > Thx
> > SG
> >
> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >
> > <da...@gmail.com> wrote:
> >
> >
> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE)
> AND
> >
> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >
> >  click here:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >
> >
> > Thru the end of the month, I intend to work on those issues not yet
> >
> > assigned.
> >
> >
> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >
> > wrote:
> >
> >
> > +1
> >
> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >
> > <ro...@gmail.com> wrote:
> >
> >
> > Hi all,
> >
> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >
> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> > branch this week - say Wednesday?  Then we should have some time to
> > clean up the master branch and uncover anything that still needs to be
> done
> > on 8.0 before we start the release process next year.
> >
> >
> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> >
> > wrote:
> >
> >
> > 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
> >
> > <er...@gmail.com> 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 <ji...@gmail.com>
> >
> > 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
> >
> > <da...@gmail.com> a écrit :
> >
> >
> > +1 to a 7.6 —lots of stuff in there
> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >
> > <nk...@gmail.com> 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
> >
> > <ca...@gmail.com> 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
> >
> > <ji...@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
> >
> > <ca...@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
> >
> > <ji...@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
> >
> > <ca...@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
> >
> > <er...@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
> >
> > <da...@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
> >
> > <ji...@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%3DBlocke
> > r%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
> >
> > <jp...@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
> >
> > <jp...@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%3DBlocke
> > r%20and%20resolution%20%3D%20Unresolved%20
> >
> >
> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >
> > <ji...@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
> >
> > <er...@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
> >
> > <ca...@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
> >
> > <ji...@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
> >
> > <da...@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
> --
> >
> > &g
> >
> >
> >
> >
> > --
> > Sincerely yours
> > Mikhail Khludnev
> >
> >
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

The Solr highlights section of the announcement is severely incomplete as
to appear embarrassing.
In the absence of time/effort to fix it should have simply been omitted;
the CHANGES.txt has details.
That would not have been embarrassing.
Maybe next time we could have a call to action about the release highlights
that coincides with the creation of the release branch;
that is a juncture in which the features are frozen and there's plenty of
time to update.
Last night I saw the call to action but it was woefully too late for me to
help.

~ David Smiley
Apache Lucene/Solr Search Developer
http://www.linkedin.com/in/davidwsmiley


On Wed, Mar 13, 2019 at 10:02 AM Adrien Grand <jp...@gmail.com> wrote:

> I organized existing items of the Lucene release notes into sections
> and added a new item about FeatureField,
> LongPoint#newDistanceFeatureQuery and
> LatLonPoint#newDistanceFeatureQuery.
>
> On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> > Jim and I have created wiki pages for the 8.0 release highlights here:
> > https://wiki.apache.org/solr/ReleaseNote80
> > https://wiki.apache.org/lucene-java/ReleaseNote80
> >
> > Feel free to edit and improve them - the Solr one in particular could do
> with some beefing up.
> >
> >
> > On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
> >
> > I'm committing them,
> > Thanks Ishan
> >
> > On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Awesome, thank you Ishan!
> >
> > On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <
> ichattopadhyaya@gmail.com> wrote:
> >
> > Would anyone like to volunteer to be release manager for 7.7.1?
> >
> > I can volunteer for 7.7.1. I'll start as soon as both these issues are
> committed.
> >
> > On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
> >
> > Would anyone like to volunteer to be release manager for 7.7.1?  Ideally
> we would get this done quickly so that I can continue releasing 8.0.0.
> >
> > On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> >
> > On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org>
> wrote:
> >
> >
> > Thank you, Alan. Give me an hour.
> >
> > чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
> >
> >
> > OK, let’s do an RC2.  When do you think you can have a fix in?
> >
> > Mikhail, will you be able to get your fix in soon as well?
> >
> >
> >
> > Nope. Don't wait for SOLR-13126, it turns to be more complicated.
> >
> >
> >
> > On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
> >
> > Hi Alan,
> >
> > There is a work-around which is to change the default to using legacy
> assignment using cluster properties. But I don't like the idea of releasing
> something that we know is broken and asking everyone to set a cluster
> property to workaround it. I'd rather just rollback the commits that caused
> the problem and then release 8.0
> >
> > On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Hi Shalin,
> >
> > I'm not familiar with this bit of code - is there a workaround
> available?  ie a way of using a different replica placement strategy when
> creating a collection?  If there is, I'd be tempted to continue with the
> vote as is and then do an immediate 8.0.1 release once you have things
> fixed, particularly if we’re going to require a 7.7.1 as well.
> >
> > On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
> >
> > Hi Alan,
> >
> > I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
> interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
> >
> > On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > The release candidate has already been built and voting is in progress,
> so it’s missed the boat unless there’s a respin.  It does look like a nasty
> bug though, so if you have a fix then feel free too commit it to the 8_0
> branch in case we do an 8.0.1 release.
> >
> > On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> >
> > Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
> >
> > On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> >
> > On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
> wrote:
> >
> > I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
> since there’s a lot of editing yet to be done for it.
> >
> > Cassandra
> > On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
> wrote:
> >
> > I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129
> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include
> this even if it's committed after the 8.0 for the code?  I could avoid
> touching CHANGES.txt if that helps (it'd be of dubious value to users
> browsing the change list any way).
> >
> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Thanks for letting me know Jason.  Your commit will have missed the cut,
> yes, but I don’t think it matters that much.  It will get picked up in a
> respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
> >
> >
> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> >
> > Hey Alan,
> >
> > I just committed a minor inconsequential bugfix
> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > realize I was cutting it so close to your work on cutting RC1, but
> > from commits I see you made this morning preparing for the RC I
> > suspect I cut things _very_ close and just missed it.
> >
> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > problems for you on the release end.  I'm happy to do whatever's
> > easiest for you regarding that commit.  It'd be nice to have it
> > included in 8.0, but it's not imperative by any means if I've already
> > missed the first RC, or it's easier for you to omit from potential
> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > go back and update CHANGES.txt I think.
> >
> > Sorry again for the potential complication.  I hate to be "that guy".
> > Thanks for stepping up and handling the release.
> >
> > Best,
> >
> > Jason
> >
> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > Thanks for fixing Cassandra and sorry for the noise. I did this too many
> times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> > I'll be more careful next time ;).
> >
> > On another note, now that 7.7 is out and that we're preparing the
> release for 8.0 what do you think of removing/nuking the 7x branch. This
> was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> >
> > Jim
> >
> > Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com>
> a écrit :
> >
> >
> > I’d like to remind RMs that when finishing up a release, we can’t just
> do a blanket find/replace in .htaccess to update the version. If we’re not
> going to coordinate binary releases with Ref Guide releases, we need to be
> careful not to change the redirects unless that version’s Ref Guide release
> is also imminent.
> >
> > This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> >
> > In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
> needs to maybe take care of it), but all non-version specific Ref Guide
> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
> we have an easy way to avoid routing people to dead links.
> >
> > Cassandra
> > On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
> >
> > Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
> >
> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> >
> > It is a shame, I agree, but some of this stuff has been deprecated since
> 3.6, so another release cycle won’t hurt :). We should prioritise cleaning
> this stuff up once 8.0 is out of the door though.
> >
> > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> >
> > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle
> to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> >
> > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> >
> > Not quite - the plan is to remove things entirely in 9.0, but we may
> need to back port some extra deprecations to 8x.  We don’t necessarily need
> them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
> >
> >
> > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> >
> > I want to ensure people are aware of two issues "Remove deprecated code
> in master" that Alan filed:
> >
> > https://issues.apache.org/jira/browse/SOLR-13138
> > https://issues.apache.org/jira/browse/LUCENE-8638
> > There's a "master-deprecations" branch as well.
> >
> > Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
> >
> > ~ David
> >
> > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> >
> >
> > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > I'm keeping any eye on the builds this weekend but all indications are
> > no issues so far.
> >
> > Kevin Risden
> >
> > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> >
> >
> > Nick, this change seems to be causing test failures. Can you have a look?
> >
> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> >
> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> >
> >
> > Thank you Jim. LUCENE-8669 has been merged.
> >
> > - Nick
> >
> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
> first RC when your patch is merged.
> > Kevin, this looks like a big change so I am not sure if it's a good idea
> to rush this in for 8.0. Would it be safer to target another version in
> order to take some time to ensure that it's not breaking anything ? I guess
> that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
> >
> > Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
> écrit :
> >
> >
> > Hey Jim,
> >
> > I just added https://issues.apache.org/jira/browse/LUCENE-8669 along
> with a pretty straightforward patch. This is a critical one that I think
> needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> >
> > On Wed, Jan 30, 2019 at 1:07 PM
> >
> > Kevin Risden <kr...@apache.org> wrote:
> >
> >
> > Jim,
> >
> > Since 7.7 needs to be released before 8.0 does that leave time to get
> > SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > currently under review.
> >
> > Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > feel this should make it into 8.0 or not.
> >
> > Kevin Risden
> >
> > On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> >
> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
> don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > Since we want to release 7.7 first I created the Jenkins job for this
> version only and will build the first candidate for this version later this
> week if there are no objection.
> > I'll restore the version bump for 8.0 when 7.7 is out.
> >
> >
> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
> écrit :
> >
> >
> > Hi,
> > Hearing no objection I created the branches for 8.0 and 7.7. I'll now
> create the Jenkins tasks for these versions, Uwe can you also add them to
> the Policeman's Jenkins job ?
> > This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
> >
> > No new features may be committed to the branch.
> > Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> > All patches that are intended for the branch should first be committed
> to the unstable branch, merged into the stable branch, and then into the
> current release branch.
> > Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch while
> the branch feature freeze is in effect, think twice: can't the addition
> wait a couple more days? Merges of bug fixes into the branch may become
> more difficult.
> > Only Jira issues with Fix version "X.Y" and priority "Blocker" will
> delay a release candidate build.
> >
> >
> > Thanks,
> > Jim
> >
> >
> > Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >
> >
> > sure, thanks Jim!
> >
> > Tommaso
> >
> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > <ji...@gmail.com> ha scritto:
> >
> >
> > Go ahead Tommaso the branch is not created yet.
> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
> and to announce the feature freeze the same day.
> > For blocker issues that are still open this leaves another week to work
> on a patch and we can update the status at the end of the week in order to
> decide if we can start the first build candidate
> > early next week. Would that work for you ?
> >
> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >
> >
> > I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >
> > Regards,
> > Tommaso
> >
> > Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > <jp...@gmail.com> ha scritto:
> >
> >
> > Hi Noble,
> >
> > No it hasn't created yet.
> >
> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> >
> >
> > Is the branch already cut for 8.0? which is it?
> >
> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com>
> wrote:
> >
> >
> > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > I will work on some documentation for it this week -- SOLR-13129
> >
> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> >
> >
> > I don't think it is critical for this to be a blocker for 8.0. If it
> gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> > I'll try to take a look next week.
> >
> > --
> > Jan Høydahl, search solution architect
> > Cominvent AS - www.cominvent.com
> >
> > 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> >
> > I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> >
> > On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> >
> >
> > It looks like someone tried to make it a blocker once before... And it's
> actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> >
> > On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> >
> >
> > Releasing a new major is very challenging on its own, I'd rather not
> > call it a blocker and delay the release for it since this isn't a new
> > regression in 8.0: it looks like a problem that has affected Solr
> > since at least 6.3? I'm not familiar with the UI code at all, but
> > maybe this is something that could get fixed before we build a RC?
> >
> >
> >
> >
> > On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >
> >
> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >
> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >
> >
> > Cool,
> >
> > I am working on giving my best release time guess as possible on the
> FOSDEM conference!
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > -----Original Message-----
> > From: Adrien Grand <jp...@gmail.com>
> > Sent: Thursday, January 24, 2019 5:33 PM
> > To: Lucene Dev <de...@lucene.apache.org>
> > Subject: Re: Lucene/Solr 8.0
> >
> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >
> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > wrote:
> >
> >
> > Hi,
> > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> >
> > already created so we can start the process anytime now. Unless there are
> > objections I'd like to start the feature freeze next week in order to
> build the
> > first candidate the week after.
> >
> > We'll also need a 7.7 release but I think we can handle both with Alan so
> >
> > the question now is whether we are ok to start the release process or if
> there
> > are any blockers left ;).
> >
> >
> >
> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >
> > a écrit :
> >
> >
> > I’ve started to work through the various deprecations on the new master
> >
> > branch.  There are a lot of them, and I’m going to need some assistance
> for
> > several of them, as it’s not entirely clear what to do.
> >
> >
> > I’ll open two overarching issues in JIRA, one for lucene and one for
> Solr,
> >
> > with lists of the deprecations that need to be removed in each one.
> I’ll create
> > a shared branch on gitbox to work against, and push the changes I’ve
> already
> > done there.  We can then create individual JIRA issues for any changes
> that
> > are more involved than just deleting code.
> >
> >
> > All assistance gratefully received, particularly for the Solr
> deprecations
> >
> > where there’s a lot of code I’m unfamiliar with.
> >
> >
> > On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >
> > wrote:
> >
> >
> > I think the current plan is to do a 7.7 release at the same time as 8.0,
> to
> >
> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > for now.
> >
> >
> > On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >
> > Hi,
> >
> > I will start and add the branch_8x jobs to Jenkins once I have some time
> >
> > later today.
> >
> >
> > The question: How to proceed with branch_7x? Should we stop using it
> >
> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > are we planning to one more Lucene/Solr 7.7? In the latter case I would
> keep
> > the jenkins jobs enabled for a while.
> >
> >
> > Uwe
> >
> > -----
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > http://www.thetaphi.de
> > eMail: uwe@thetaphi.de
> >
> > From: Alan Woodward <ro...@gmail.com>
> > Sent: Monday, January 7, 2019 11:30 AM
> > To: dev@lucene.apache.org
> > Subject: Re: Lucene/Solr 8.0
> >
> > OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >
> > from master, and am in the process of updating the master branch to
> version
> > 9.  New commits that should be included in the 8.0 release should also be
> > back-ported to branch_8x from master.
> >
> >
> > This is not intended as a feature freeze, as I know there are still some
> >
> > things being worked on for 8.0; however, it should let us clean up
> master by
> > removing as much deprecated code as possible, and give us an idea of any
> > replacement work that needs to be done.
> >
> >
> >
> > On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >
> > wrote:
> >
> >
> > January.
> >
> > On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >
> > wrote:
> >
> >
> > It would be nice to see Solr 8 in January soon as there is an enhancement
> >
> > on nested-documents we are waiting to get our hands on.
> >
> > Any idea when Solr 8 would be out ?
> >
> > Thx
> > SG
> >
> > On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >
> > <da...@gmail.com> wrote:
> >
> >
> > I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE)
> AND
> >
> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >
> >  click here:
> >
> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >
> >
> > Thru the end of the month, I intend to work on those issues not yet
> >
> > assigned.
> >
> >
> > On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >
> > wrote:
> >
> >
> > +1
> >
> > On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >
> > <ro...@gmail.com> wrote:
> >
> >
> > Hi all,
> >
> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >
> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> > branch this week - say Wednesday?  Then we should have some time to
> > clean up the master branch and uncover anything that still needs to be
> done
> > on 8.0 before we start the release process next year.
> >
> >
> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> >
> > wrote:
> >
> >
> > 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
> >
> > <er...@gmail.com> 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 <ji...@gmail.com>
> >
> > 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
> >
> > <da...@gmail.com> a écrit :
> >
> >
> > +1 to a 7.6 —lots of stuff in there
> > On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >
> > <nk...@gmail.com> 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
> >
> > <ca...@gmail.com> 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
> >
> > <ji...@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
> >
> > <ca...@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
> >
> > <ji...@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
> >
> > <ca...@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
> >
> > <er...@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
> >
> > <da...@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
> >
> > <ji...@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%3DBlocke
> > r%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
> >
> > <jp...@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
> >
> > <jp...@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%3DBlocke
> > r%20and%20resolution%20%3D%20Unresolved%20
> >
> >
> > Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >
> > <ji...@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
> >
> > <er...@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
> >
> > <ca...@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
> >
> > <ji...@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
> >
> > <da...@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
> --
> >
> > &g
> >
> >
> >
> >
> > --
> > Sincerely yours
> > Mikhail Khludnev
> >
> >
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

I organized existing items of the Lucene release notes into sections
and added a new item about FeatureField,
LongPoint#newDistanceFeatureQuery and
LatLonPoint#newDistanceFeatureQuery.

On Tue, Mar 12, 2019 at 5:54 PM Alan Woodward <ro...@gmail.com> wrote:
>
> Jim and I have created wiki pages for the 8.0 release highlights here:
> https://wiki.apache.org/solr/ReleaseNote80
> https://wiki.apache.org/lucene-java/ReleaseNote80
>
> Feel free to edit and improve them - the Solr one in particular could do with some beefing up.
>
>
> On 20 Feb 2019, at 11:37, Noble Paul <no...@gmail.com> wrote:
>
> I'm committing them,
> Thanks Ishan
>
> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>
>
> Awesome, thank you Ishan!
>
> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>
> Would anyone like to volunteer to be release manager for 7.7.1?
>
> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>
> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>
>
> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>
> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>
> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>
> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>
>
> Thank you, Alan. Give me an hour.
>
> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>
>
> OK, let’s do an RC2.  When do you think you can have a fix in?
>
> Mikhail, will you be able to get your fix in soon as well?
>
>
>
> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>
>
>
> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>
> Hi Alan,
>
> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>
> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>
>
> Hi Shalin,
>
> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>
> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>
> Hi Alan,
>
> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>
> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>
>
> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>
> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>
> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>
> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>
>
> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>
> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>
> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>
> Cassandra
> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>
> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>
> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>
>
> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>
>
> On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>
> Hey Alan,
>
> I just committed a minor inconsequential bugfix
> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> realize I was cutting it so close to your work on cutting RC1, but
> from commits I see you made this morning preparing for the RC I
> suspect I cut things _very_ close and just missed it.
>
> Hopefully my ill-timed commit to branch_8_0 doesn't create any
> problems for you on the release end.  I'm happy to do whatever's
> easiest for you regarding that commit.  It'd be nice to have it
> included in 8.0, but it's not imperative by any means if I've already
> missed the first RC, or it's easier for you to omit from potential
> subsequent RCs.  Let me know if there's anything you'd like me to do
> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> go back and update CHANGES.txt I think.
>
> Sorry again for the potential complication.  I hate to be "that guy".
> Thanks for stepping up and handling the release.
>
> Best,
>
> Jason
>
> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>
>
> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> I'll be more careful next time ;).
>
> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>
> Jim
>
> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>
>
> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>
> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>
> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>
> Cassandra
> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>
> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>
> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>
> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>
> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>
> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>
> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>
>
> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>
>
> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>
> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>
> https://issues.apache.org/jira/browse/SOLR-13138
> https://issues.apache.org/jira/browse/LUCENE-8638
> There's a "master-deprecations" branch as well.
>
> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>
> ~ David
>
> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>
>
> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> I'm keeping any eye on the builds this weekend but all indications are
> no issues so far.
>
> Kevin Risden
>
> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>
>
> Nick, this change seems to be causing test failures. Can you have a look?
>
> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>
> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>
>
> Thank you Jim. LUCENE-8669 has been merged.
>
> - Nick
>
> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>
>
> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>
> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>
>
> Hey Jim,
>
> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>
> On Wed, Jan 30, 2019 at 1:07 PM
>
> Kevin Risden <kr...@apache.org> wrote:
>
>
> Jim,
>
> Since 7.7 needs to be released before 8.0 does that leave time to get
> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> currently under review.
>
> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> feel this should make it into 8.0 or not.
>
> Kevin Risden
>
> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>
>
> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> I'll restore the version bump for 8.0 when 7.7 is out.
>
>
> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>
>
> Hi,
> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>
> No new features may be committed to the branch.
> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>
>
> Thanks,
> Jim
>
>
> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>
>
> sure, thanks Jim!
>
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> <ji...@gmail.com> ha scritto:
>
>
> Go ahead Tommaso the branch is not created yet.
> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> early next week. Would that work for you ?
>
> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>
>
> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>
> Regards,
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> <jp...@gmail.com> ha scritto:
>
>
> Hi Noble,
>
> No it hasn't created yet.
>
> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>
>
> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> I will work on some documentation for it this week -- SOLR-13129
>
> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>
>
> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> I'll try to take a look next week.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>
> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>
> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>
>
> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>
> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>
>
> Releasing a new major is very challenging on its own, I'd rather not
> call it a blocker and delay the release for it since this isn't a new
> regression in 8.0: it looks like a problem that has affected Solr
> since at least 6.3? I'm not familiar with the UI code at all, but
> maybe this is something that could get fixed before we build a RC?
>
>
>
>
> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>
>
> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>
> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>
>
> Cool,
>
> I am working on giving my best release time guess as possible on the FOSDEM conference!
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> -----Original Message-----
> From: Adrien Grand <jp...@gmail.com>
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev <de...@lucene.apache.org>
> Subject: Re: Lucene/Solr 8.0
>
> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>
> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> wrote:
>
>
> Hi,
> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>
> already created so we can start the process anytime now. Unless there are
> objections I'd like to start the feature freeze next week in order to build the
> first candidate the week after.
>
> We'll also need a 7.7 release but I think we can handle both with Alan so
>
> the question now is whether we are ok to start the release process or if there
> are any blockers left ;).
>
>
>
> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>
> a écrit :
>
>
> I’ve started to work through the various deprecations on the new master
>
> branch.  There are a lot of them, and I’m going to need some assistance for
> several of them, as it’s not entirely clear what to do.
>
>
> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>
> with lists of the deprecations that need to be removed in each one.  I’ll create
> a shared branch on gitbox to work against, and push the changes I’ve already
> done there.  We can then create individual JIRA issues for any changes that
> are more involved than just deleting code.
>
>
> All assistance gratefully received, particularly for the Solr deprecations
>
> where there’s a lot of code I’m unfamiliar with.
>
>
> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>
> wrote:
>
>
> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>
> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> for now.
>
>
> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi,
>
> I will start and add the branch_8x jobs to Jenkins once I have some time
>
> later today.
>
>
> The question: How to proceed with branch_7x? Should we stop using it
>
> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> the jenkins jobs enabled for a while.
>
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> From: Alan Woodward <ro...@gmail.com>
> Sent: Monday, January 7, 2019 11:30 AM
> To: dev@lucene.apache.org
> Subject: Re: Lucene/Solr 8.0
>
> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>
> from master, and am in the process of updating the master branch to version
> 9.  New commits that should be included in the 8.0 release should also be
> back-ported to branch_8x from master.
>
>
> This is not intended as a feature freeze, as I know there are still some
>
> things being worked on for 8.0; however, it should let us clean up master by
> removing as much deprecated code as possible, and give us an idea of any
> replacement work that needs to be done.
>
>
>
> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>
> wrote:
>
>
> January.
>
> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>
> wrote:
>
>
> It would be nice to see Solr 8 in January soon as there is an enhancement
>
> on nested-documents we are waiting to get our hands on.
>
> Any idea when Solr 8 would be out ?
>
> Thx
> SG
>
> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>
> <da...@gmail.com> wrote:
>
>
> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>
> priority = Blocker and status = open and fixVersion = "master (8.0)"
>
>  click here:
>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>
>
> Thru the end of the month, I intend to work on those issues not yet
>
> assigned.
>
>
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>
> wrote:
>
>
> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>
> <ro...@gmail.com> wrote:
>
>
> Hi all,
>
> Now that 7.6 is out of the door (thanks Nick!) we should think about
>
> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> branch this week - say Wednesday?  Then we should have some time to
> clean up the master branch and uncover anything that still needs to be done
> on 8.0 before we start the release process next year.
>
>
> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>
> wrote:
>
>
> 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
>
> <er...@gmail.com> 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 <ji...@gmail.com>
>
> 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
>
> <da...@gmail.com> a écrit :
>
>
> +1 to a 7.6 —lots of stuff in there
> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>
> <nk...@gmail.com> 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
>
> <ca...@gmail.com> 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
>
> <ji...@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
>
> <ca...@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
>
> <ji...@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
>
> <ca...@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
>
> <er...@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
>
> <da...@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
>
> <ji...@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%3DBlocke
> r%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
>
> <jp...@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
>
> <jp...@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%3DBlocke
> r%20and%20resolution%20%3D%20Unresolved%20
>
>
> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>
> <ji...@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
>
> <er...@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
>
> <ca...@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
>
> <ji...@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
>
> <da...@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 --
>
> &g
>
>
>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>


-- 
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Jim and I have created wiki pages for the 8.0 release highlights here:
https://wiki.apache.org/solr/ReleaseNote80 <https://wiki.apache.org/solr/ReleaseNote80>
https://wiki.apache.org/lucene-java/ReleaseNote80 <https://wiki.apache.org/lucene-java/ReleaseNote80>

Feel free to edit and improve them - the Solr one in particular could do with some beefing up.


> On 20 Feb 2019, at 11:37, Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
> 
> I'm committing them,
> Thanks Ishan
> 
> On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Awesome, thank you Ishan!
>> 
>> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ichattopadhyaya@gmail.com <ma...@gmail.com>> wrote:
>> 
>>> Would anyone like to volunteer to be release manager for 7.7.1?
>> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>> 
>> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>>> 
>>> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>>> 
>>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>> 
>>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>>> 
>>>> Thank you, Alan. Give me an hour.
>>>> 
>>>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com <ma...@gmail.com>:
>>>>> 
>>>>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>>>> 
>>>>> Mikhail, will you be able to get your fix in soon as well?
>>> 
>>> 
>>> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>>> 
>>>>> 
>>>>> 
>>>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>>>>> 
>>>>> Hi Alan,
>>>>> 
>>>>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>>>>> 
>>>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>> Hi Shalin,
>>>>>> 
>>>>>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>>>>>> 
>>>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>> Hi Alan,
>>>>>> 
>>>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>>>>> 
>>>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> 
>>>>>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>>>>>> 
>>>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>>>>>> 
>>>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ?
>>>>>>> 
>>>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>>>>>> 
>>>>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>> 
>>>>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>>>>>> 
>>>>>>>> Cassandra
>>>>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>>>>>> 
>>>>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>>>>> 
>>>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>> 
>>>>>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>> 
>>>>>>>>>> Hey Alan,
>>>>>>>>>> 
>>>>>>>>>> I just committed a minor inconsequential bugfix
>>>>>>>>>> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>>>>>> realize I was cutting it so close to your work on cutting RC1, but
>>>>>>>>>> from commits I see you made this morning preparing for the RC I
>>>>>>>>>> suspect I cut things _very_ close and just missed it.
>>>>>>>>>> 
>>>>>>>>>> Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>>>>>> problems for you on the release end.  I'm happy to do whatever's
>>>>>>>>>> easiest for you regarding that commit.  It'd be nice to have it
>>>>>>>>>> included in 8.0, but it's not imperative by any means if I've already
>>>>>>>>>> missed the first RC, or it's easier for you to omit from potential
>>>>>>>>>> subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>>>>>> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>>>>>> go back and update CHANGES.txt I think.
>>>>>>>>>> 
>>>>>>>>>> Sorry again for the potential complication.  I hate to be "that guy".
>>>>>>>>>> Thanks for stepping up and handling the release.
>>>>>>>>>> 
>>>>>>>>>> Best,
>>>>>>>>>> 
>>>>>>>>>> Jason
>>>>>>>>>> 
>>>>>>>>>> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>>>>>>>> I'll be more careful next time ;).
>>>>>>>>>>> 
>>>>>>>>>>> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>>>>>>>> 
>>>>>>>>>>> Jim
>>>>>>>>>>> 
>>>>>>>>>>> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>>>>>>> 
>>>>>>>>>>>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>>>>>>>>> 
>>>>>>>>>>>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>>>>>>>> 
>>>>>>>>>>>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>>>>>>>>> 
>>>>>>>>>>>> Cassandra
>>>>>>>>>>>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>>>>>>>> 
>>>>>>>>>>>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>>>>>>>>>> There's a "master-deprecations" branch as well.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>>>>>>>>> 
>>>>>>>>>>>>> ~ David
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>>>>>>>>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>>>>>>>>>>> no issues so far.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Kevin Risden
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> - Nick
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>>>>>>>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Hey Jim,
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>>>>>>>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Jim,
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>>>>>>>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>>>>>>>>>>>>>>> currently under review.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>>>>>>>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> Kevin Risden
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>>>>>>>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>>>>>>>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>>>>>>>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> No new features may be committed to the branch.
>>>>>>>>>>>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>>>>>>>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>>>>>>>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>>>>>>>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>>>>>>> Jim
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> sure, thanks Jim!
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Tommaso
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>>>>>>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>>>>>>>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>>>>>>>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>>>>>>>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>>>>>>>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>>>>>> Tommaso
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>>>>>>>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Hi Noble,
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>>>>>>>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>  click here:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <da...@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 --
>>>>>>>>>>>>>>>>>>>>> &g
>>> 
>>> 
>>> 
>>> --
>>> Sincerely yours
>>> Mikhail Khludnev
>>> 
>>> 
>> 
> 
> 
> -- 
> -----------------------------------------------------
> Noble Paul
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> 

Re: Lucene/Solr 8.0

[Noble Paul <no...@gmail.com>]

I'm committing them,
Thanks Ishan

On Wed, Feb 20, 2019 at 8:38 PM Alan Woodward <ro...@gmail.com> wrote:
>
> Awesome, thank you Ishan!
>
> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
>
> > Would anyone like to volunteer to be release manager for 7.7.1?
> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
>
> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:
>>
>> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
>>
>> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
>>
>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>>
>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>>>
>>> Thank you, Alan. Give me an hour.
>>>
>>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>>>>
>>>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>>>
>>>> Mikhail, will you be able to get your fix in soon as well?
>>
>>
>> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>>
>>>>
>>>>
>>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>>
>>>> Hi Alan,
>>>>
>>>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>>>>
>>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>
>>>>> Hi Shalin,
>>>>>
>>>>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>>>>>
>>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
>>>>>
>>>>> Hi Alan,
>>>>>
>>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>>>>
>>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:
>>>>>>
>>>>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>>>>>
>>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>>>>
>>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>>>>
>>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>>>
>>>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>>>>>
>>>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>>>>>>>
>>>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>>>>>
>>>>>>> Cassandra
>>>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>>>>>>>
>>>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>>>>
>>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>>>>
>>>>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>>>>>
>>>>>>>>
>>>>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
>>>>>>>> >
>>>>>>>> > Hey Alan,
>>>>>>>> >
>>>>>>>> > I just committed a minor inconsequential bugfix
>>>>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>>>>> > from commits I see you made this morning preparing for the RC I
>>>>>>>> > suspect I cut things _very_ close and just missed it.
>>>>>>>> >
>>>>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>>>> > go back and update CHANGES.txt I think.
>>>>>>>> >
>>>>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>>>>> > Thanks for stepping up and handling the release.
>>>>>>>> >
>>>>>>>> > Best,
>>>>>>>> >
>>>>>>>> > Jason
>>>>>>>> >
>>>>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>> >>
>>>>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>>>>> >> I'll be more careful next time ;).
>>>>>>>> >>
>>>>>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>>>>> >>
>>>>>>>> >> Jim
>>>>>>>> >>
>>>>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>>>>>>>> >>>
>>>>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>>>>> >>>
>>>>>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>>>> >>>
>>>>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>>>>> >>>
>>>>>>>> >>> Cassandra
>>>>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>>>>>>>> >>>
>>>>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>>>>> >>>
>>>>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>>>>>>> >>>
>>>>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>>>> >>>
>>>>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>>>>>>>> >>>
>>>>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>>>>> >>>
>>>>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>>>>>>> >>>>
>>>>>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>>>>> >>>>
>>>>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>>>>> >>>>
>>>>>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>>>> >>>>
>>>>>>>> >>>> ~ David
>>>>>>>> >>>>
>>>>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>>>>>> >>>>>
>>>>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>>>>> >>>>> no issues so far.
>>>>>>>> >>>>>
>>>>>>>> >>>>> Kevin Risden
>>>>>>>> >>>>>
>>>>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> - Nick
>>>>>>>> >>>>>>>
>>>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>>>> >>>>>>>>
>>>>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>>>>>> >>>>>>>>>
>>>>>>>> >>>>>>>>> Hey Jim,
>>>>>>>> >>>>>>>>>
>>>>>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>>>> >>>>>>>>>
>>>>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>>>> >>>>>>>>>>
>>>>>>>> >>>>>>>>>> Jim,
>>>>>>>> >>>>>>>>>>
>>>>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>>>> >>>>>>>>>> currently under review.
>>>>>>>> >>>>>>>>>>
>>>>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>>>> >>>>>>>>>>
>>>>>>>> >>>>>>>>>> Kevin Risden
>>>>>>>> >>>>>>>>>>
>>>>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>
>>>>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>>>> >>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>
>>>>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>> Hi,
>>>>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>> Thanks,
>>>>>>>> >>>>>>>>>>>> Jim
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>>>>> >>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>>>> >>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>> >>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>>>> >>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>> Regards,
>>>>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>>>>> >>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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 --
>>>>>>>> >>>>>>>>>>>>&g
>>
>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>>
>>
>


-- 
-----------------------------------------------------
Noble Paul

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Awesome, thank you Ishan!

> On 20 Feb 2019, at 09:15, Ishan Chattopadhyaya <ic...@gmail.com> wrote:
> 
> > Would anyone like to volunteer to be release manager for 7.7.1?  
> I can volunteer for 7.7.1. I'll start as soon as both these issues are committed.
> 
> On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.
> 
> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.
> 
>> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>> 
>> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>> Thank you, Alan. Give me an hour. 
>> 
>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com <ma...@gmail.com>:
>> OK, let’s do an RC2.  When do you think you can have a fix in?
>> 
>> Mikhail, will you be able to get your fix in soon as well?
>> 
>> Nope. Don't wait for SOLR-13126, it turns to be more complicated. 
>>  
>> 
>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> Hi Alan,
>>> 
>>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>>> 
>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> Hi Shalin,
>>> 
>>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>>> 
>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>>>> 
>>>> Hi Alan,
>>>> 
>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>>> 
>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>>> 
>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>>>> 
>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
>>>>> 
>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>>> 
>>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>>>> 
>>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>>>> 
>>>>>> Cassandra
>>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>>>> 
>>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>>>> 
>>>>>>> 
>>>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >
>>>>>>> > Hey Alan,
>>>>>>> >
>>>>>>> > I just committed a minor inconsequential bugfix
>>>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>>>> > from commits I see you made this morning preparing for the RC I
>>>>>>> > suspect I cut things _very_ close and just missed it.
>>>>>>> >
>>>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>>> > go back and update CHANGES.txt I think.
>>>>>>> >
>>>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>>>> > Thanks for stepping up and handling the release.
>>>>>>> >
>>>>>>> > Best,
>>>>>>> >
>>>>>>> > Jason
>>>>>>> >
>>>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>
>>>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>>>> >> I'll be more careful next time ;).
>>>>>>> >>
>>>>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>>>> >>
>>>>>>> >> Jim
>>>>>>> >>
>>>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>
>>>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>>>> >>>
>>>>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>>> >>>
>>>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>>>> >>>
>>>>>>> >>> Cassandra
>>>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>>>>> >>>
>>>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>>>> >>>
>>>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>
>>>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>>> >>>
>>>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>
>>>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>>>> >>>
>>>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>>>> >>>>
>>>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>>>> >>>>
>>>>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>>> >>>>
>>>>>>> >>>> ~ David
>>>>>>> >>>>
>>>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>>>> >>>>> no issues so far.
>>>>>>> >>>>>
>>>>>>> >>>>> Kevin Risden
>>>>>>> >>>>>
>>>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>>> >>>>>>
>>>>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>>>>>> >>>>>>
>>>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> - Nick
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> Hey Jim,
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Jim,
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>>> >>>>>>>>>> currently under review.
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Kevin Risden
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Thanks,
>>>>>>> >>>>>>>>>>>> Jim
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> Regards,
>>>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 --
>>>>>>> >>>>>>>>>>>>&g
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev
> 

Re: Lucene/Solr 8.0

[Ishan Chattopadhyaya <ic...@gmail.com>]

> Would anyone like to volunteer to be release manager for 7.7.1?
I can volunteer for 7.7.1. I'll start as soon as both these issues are
committed.

On Tue, Feb 19, 2019 at 9:18 PM Alan Woodward <ro...@gmail.com> wrote:

> We have two Solr issues that are serious enough to warrant a 7.7.1
> release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility
> guarantees, we should do this release before we restart the 8.0.0 process.
>
> Would anyone like to volunteer to be release manager for 7.7.1?  Ideally
> we would get this done quickly so that I can continue releasing 8.0.0.
>
> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
>
> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:
>
>> Thank you, Alan. Give me an hour.
>>
>> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>>
>>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>>
>>> Mikhail, will you be able to get your fix in soon as well?
>>>
>>
> Nope. Don't wait for SOLR-13126, it turns to be more complicated.
>
>
>>
>>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
>>> wrote:
>>>
>>> Hi Alan,
>>>
>>> There is a work-around which is to change the default to using legacy
>>> assignment using cluster properties. But I don't like the idea of releasing
>>> something that we know is broken and asking everyone to set a cluster
>>> property to workaround it. I'd rather just rollback the commits that caused
>>> the problem and then release 8.0
>>>
>>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>>
>>>> Hi Shalin,
>>>>
>>>> I'm not familiar with this bit of code - is there a workaround
>>>> available?  ie a way of using a different replica placement strategy when
>>>> creating a collection?  If there is, I'd be tempted to continue with the
>>>> vote as is and then do an immediate 8.0.1 release once you have things
>>>> fixed, particularly if we’re going to require a 7.7.1 as well.
>>>>
>>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
>>>> wrote:
>>>>
>>>> Hi Alan,
>>>>
>>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
>>>> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
>>>> interest of time, I propose rolling back SOLR-12739 which caused these
>>>> issues. We can re-introduce it with proper fixes for the related issues in
>>>> 8.1.
>>>>
>>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> The release candidate has already been built and voting is in
>>>>> progress, so it’s missed the boat unless there’s a respin.  It does look
>>>>> like a nasty bug though, so if you have a fix then feel free too commit it
>>>>> to the 8_0 branch in case we do an 8.0.1 release.
>>>>>
>>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>>>
>>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>>>
>>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0
>>>>>> branch.
>>>>>>
>>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed
>>>>>> even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at
>>>>>> all since there’s a lot of editing yet to be done for it.
>>>>>>
>>>>>> Cassandra
>>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <
>>>>>> david.w.smiley@gmail.com>, wrote:
>>>>>>
>>>>>> I've been shepherding
>>>>>> https://issues.apache.org/jira/browse/SOLR-13129 which only touches
>>>>>> the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's
>>>>>> committed after the 8.0 for the code?  I could avoid touching CHANGES.txt
>>>>>> if that helps (it'd be of dubious value to users browsing the change list
>>>>>> any way).
>>>>>>
>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for letting me know Jason.  Your commit will have missed the
>>>>>>> cut, yes, but I don’t think it matters that much.  It will get picked up in
>>>>>>> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>>>>>> then we can just alter CHANGES.txt
>>>>>>>
>>>>>>>
>>>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Hey Alan,
>>>>>>> >
>>>>>>> > I just committed a minor inconsequential bugfix
>>>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>>>> > from commits I see you made this morning preparing for the RC I
>>>>>>> > suspect I cut things _very_ close and just missed it.
>>>>>>> >
>>>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>>>> > included in 8.0, but it's not imperative by any means if I've
>>>>>>> already
>>>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to
>>>>>>> do
>>>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need
>>>>>>> to
>>>>>>> > go back and update CHANGES.txt I think.
>>>>>>> >
>>>>>>> > Sorry again for the potential complication.  I hate to be "that
>>>>>>> guy".
>>>>>>> > Thanks for stepping up and handling the release.
>>>>>>> >
>>>>>>> > Best,
>>>>>>> >
>>>>>>> > Jason
>>>>>>> >
>>>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <
>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>> >>
>>>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this
>>>>>>> too many times in the past so I just mechanically changed the redirect
>>>>>>> without thinking of when or if the ref guide was also released.
>>>>>>> >> I'll be more careful next time ;).
>>>>>>> >>
>>>>>>> >> On another note, now that 7.7 is out and that we're preparing the
>>>>>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>>>>>> was already discussed some time ago
>>>>>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think
>>>>>>> that we reached a consensus and we have maybe new options with the move to
>>>>>>> gitbox. One option discussed in the thread was to remove all files and add
>>>>>>> a README that says that this branch is dead. I don't know if it's possible
>>>>>>> but we could also make the branch protected in gitbox in order to avoid new
>>>>>>> commits. What do you think ? Should we keep this branch and just consider
>>>>>>> new commits as useless or should we try to "clean up" all Nx branches that
>>>>>>> are not active anymore (5x, 6x, 7x) ?
>>>>>>> >>
>>>>>>> >> Jim
>>>>>>> >>
>>>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>>>>>> casstargett@gmail.com> a écrit :
>>>>>>> >>>
>>>>>>> >>> I’d like to remind RMs that when finishing up a release, we
>>>>>>> can’t just do a blanket find/replace in .htaccess to update the version. If
>>>>>>> we’re not going to coordinate binary releases with Ref Guide releases, we
>>>>>>> need to be careful not to change the redirects unless that version’s Ref
>>>>>>> Guide release is also imminent.
>>>>>>> >>>
>>>>>>> >>> This is noted in the ReleaseToDo (
>>>>>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>>>>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>>>>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>>> >>>
>>>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide
>>>>>>> so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
>>>>>>> else needs to maybe take care of it), but all non-version specific Ref
>>>>>>> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
>>>>>>> fix, but we have an easy way to avoid routing people to dead links.
>>>>>>> >>>
>>>>>>> >>> Cassandra
>>>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <
>>>>>>> romseygeek@gmail.com>, wrote:
>>>>>>> >>>
>>>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.
>>>>>>> I volunteer to be the manager for this round.  My current plan is to build
>>>>>>> a release candidate early next week, as soon as the 7.7 release has been
>>>>>>> announced.
>>>>>>> >>>
>>>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> It is a shame, I agree, but some of this stuff has been
>>>>>>> deprecated since 3.6, so another release cycle won’t hurt :). We should
>>>>>>> prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>>> >>>
>>>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>
>>>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the
>>>>>>> 8.0 cycle to remove things that have been deprecated in previous releases?
>>>>>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>>>>>> further.
>>>>>>> >>>
>>>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <
>>>>>>> romseygeek@gmail.com> wrote:
>>>>>>> >>>>
>>>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but
>>>>>>> we may need to back port some extra deprecations to 8x.  We don’t
>>>>>>> necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in
>>>>>>> 9 without any problems.  I opened the issues to ensure that we didn’t keep
>>>>>>> carrying deprecated code through any further releases.
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>>
>>>>>>> >>>> I want to ensure people are aware of two issues "Remove
>>>>>>> deprecated code in master" that Alan filed:
>>>>>>> >>>>
>>>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>>>> >>>>
>>>>>>> >>>> Although both issues are marked "master (9.0)", I think the
>>>>>>> intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>>> >>>>
>>>>>>> >>>> ~ David
>>>>>>> >>>>
>>>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>>>>>> wrote:
>>>>>>> >>>>>
>>>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x,
>>>>>>> and 8.0.
>>>>>>> >>>>> I'm keeping any eye on the builds this weekend but all
>>>>>>> indications are
>>>>>>> >>>>> no issues so far.
>>>>>>> >>>>>
>>>>>>> >>>>> Kevin Risden
>>>>>>> >>>>>
>>>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>>>>>> wrote:
>>>>>>> >>>>>>
>>>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you
>>>>>>> have a look?
>>>>>>> >>>>>>
>>>>>>> >>>>>> See eg.
>>>>>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console
>>>>>>> .
>>>>>>> >>>>>>
>>>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <
>>>>>>> nknize@gmail.com> wrote:
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> - Nick
>>>>>>> >>>>>>>
>>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>>>>>> start the first RC when your patch is merged.
>>>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if
>>>>>>> it's a good idea to rush this in for 8.0. Would it be safer to target
>>>>>>> another version in order to take some time to ensure that it's not breaking
>>>>>>> anything ? I guess that your concern is that a change like this should
>>>>>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>>>>>> this part of the code and the implications of such a change so I let you
>>>>>>> decide what we should do here but let's not delay the release if we realize
>>>>>>> that this change requires more than a few days to be merged.
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <
>>>>>>> nknize@gmail.com> a écrit :
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> Hey Jim,
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> I just added
>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8669 along with a
>>>>>>> pretty straightforward patch. This is a critical one that I think needs to
>>>>>>> be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Jim,
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>>>>>> time to get
>>>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR
>>>>>>> updated and it is
>>>>>>> >>>>>>>>>> currently under review.
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm
>>>>>>> curious if others
>>>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> Kevin Risden
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on
>>>>>>> branch_8x because we don't handle two concurrent releases in our tests (
>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins
>>>>>>> job for this version only and will build the first candidate for this
>>>>>>> version later this week if there are no objection.
>>>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>>>>>> jim.ferenczi@gmail.com> a écrit :
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>>>>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>>>>>> add them to the Policeman's Jenkins job ?
>>>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has
>>>>>>> started for both versions (7.7 and 8.0):
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug
>>>>>>> fixes may be committed to the branch. However, you should submit all
>>>>>>> patches you want to commit to Jira first to give others the chance to
>>>>>>> review and possibly vote against the patch. Keep in mind that it is our
>>>>>>> main intention to keep the branch as stable as possible.
>>>>>>> >>>>>>>>>>>> All patches that are intended for the branch should
>>>>>>> first be committed to the unstable branch, merged into the stable branch,
>>>>>>> and then into the current release branch.
>>>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may
>>>>>>> continue as usual. However, if you plan to commit a big change to the
>>>>>>> unstable branch while the branch feature freeze is in effect, think twice:
>>>>>>> can't the addition wait a couple more days? Merges of bug fixes into the
>>>>>>> branch may become more difficult.
>>>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>>>>>> "Blocker" will delay a release candidate build.
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Thanks,
>>>>>>> >>>>>>>>>>>> Jim
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>>>>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>>>>>> another week to work on a patch and we can update the status at the end of
>>>>>>> the week in order to decide if we can start the first build candidate
>>>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> I'd like to backport
>>>>>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>>>>>> still time.
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> Regards,
>>>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>>>>>> noble.paul@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>>>>>> david.w.smiley@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>>>>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as
>>>>>>> 8.0 blocker) that I feel pretty good about.  This provides a key part of
>>>>>>> the nested document support.
>>>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this
>>>>>>> week -- SOLR-13129
>>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>>>>>> jan.asf@cominvent.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>>>>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>>>>>> ooold bug.
>>>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>>>>>> feature in the UI and replace it with an error message popup or something.
>>>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández
>>>>>>> Löbbe <to...@gmail.com>:
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As
>>>>>>> long as there is a reasonable time horizon for the issue being resolved I'm
>>>>>>> +1 on making it a blocker. I'm not familiar enough with the UI code to help
>>>>>>> either unfortunately.
>>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>>>>>> gus.heck@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a
>>>>>>> blocker once before... And it's actually
>>>>>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>>>>>>  a duplicate of an earlier issue (
>>>>>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>>>>>> question of whether or not overall quality has a bearing on the decision to
>>>>>>> release. As it turns out the screen shot I posted to the issue is less than
>>>>>>> half of the shards that eventually got created since there was an
>>>>>>> outstanding queue of requests still processing at the time. I'm now having
>>>>>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>>>>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>>>>>> or less makes it impossible to recommend the use of the admin UI for
>>>>>>> anything other than read only observation of the cluster. Now imagine
>>>>>>> someone leaves a browser window open and forgets about it rather than
>>>>>>> browsing away or closing the window, not knowing that it's silently pumping
>>>>>>> out requests after showing an error... would completely hose a node, and
>>>>>>> until they tracked down the source of the requests, (hope he didn't go
>>>>>>> home) it would be impossible to resolve...
>>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>>>>>> jpountz@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on
>>>>>>> its own, I'd rather not
>>>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>>>>>> since this isn't a new
>>>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem
>>>>>>> that has affected Solr
>>>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the
>>>>>>> UI code at all, but
>>>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>>>>>> before we build a RC?
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>>>>>> gus.heck@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>>>>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to
>>>>>>> block 8.0. I just got burned by it a second time.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler
>>>>>>> <uw...@thetaphi.de> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>>>>>> guess as possible on the FOSDEM conference!
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting
>>>>>>> on the week of February 4th.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim
>>>>>>> ferenczi <ji...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to
>>>>>>> start on releasing 8.0. The branch is
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>>>>>> anytime now. Unless there are
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature
>>>>>>> freeze next week in order to build the
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think
>>>>>>> we can handle both with Alan so
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to
>>>>>>> start the release process or if there
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan
>>>>>>> Woodward <ro...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>>>>>> deprecations on the new master
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m
>>>>>>> going to need some assistance for
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>>>>>> what to do.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA,
>>>>>>> one for lucene and one for Solr,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to
>>>>>>> be removed in each one.  I’ll create
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against,
>>>>>>> and push the changes I’ve already
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual
>>>>>>> JIRA issues for any changes that
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>>>>>> particularly for the Solr deprecations
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar
>>>>>>> with.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>>>>>> romseygeek@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>>>>>> release at the same time as 8.0, to
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.
>>>>>>> So let’s keep those jobs enabled
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>>>>>> uwe@thetaphi.de> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs
>>>>>>> to Jenkins once I have some time
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with
>>>>>>> branch_7x? Should we stop using it
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>>>>>> branch_7_6 only for bugfixes), or
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr
>>>>>>> 7.7? In the latter case I would keep
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com
>>>>>>> >
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit…
>>>>>>> I’ve just created a branch for 8x
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of
>>>>>>> updating the master branch to version
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in
>>>>>>> the 8.0 release should also be
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze,
>>>>>>> as I know there are still some
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>>>>>> should let us clean up master by
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as
>>>>>>> possible, and give us an idea of any
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>>>>>> david.w.smiley@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>>>>>> sg.online.email@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>>>>>> soon as there is an enhancement
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get
>>>>>>> our hands on.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David
>>>>>>> Smiley
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this
>>>>>>> filter:   project in (SOLR, LUCENE) AND
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>>>>>> fixVersion = "master (8.0)"
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to
>>>>>>> work on those issues not yet
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>>>>>>> Grand <jp...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan
>>>>>>> Woodward
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>>>>>> Nick!) we should think about
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>>>>>> 9.0.  I’ll volunteer to create the
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>>>>>> should have some time to
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover
>>>>>>> anything that still needs to be done
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process
>>>>>>> next year.
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra
>>>>>>> Targett <ca...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM
>>>>>>> Nicholas Knize
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à
>>>>>>> 10:36, jim ferenczi
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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 --
>>>>>>> >>>>>>>>>>>>&g
>>>>>>
>>>>>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

We have two Solr issues that are serious enough to warrant a 7.7.1 release: SOLR-13248 and SOLR-13255.  Given our backwards-compatibility guarantees, we should do this release before we restart the 8.0.0 process.

Would anyone like to volunteer to be release manager for 7.7.1?  Ideally we would get this done quickly so that I can continue releasing 8.0.0.

> On 14 Feb 2019, at 20:37, Mikhail Khludnev <mk...@apache.org> wrote:
> 
> On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
> Thank you, Alan. Give me an hour. 
> 
> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com <ma...@gmail.com>:
> OK, let’s do an RC2.  When do you think you can have a fix in?
> 
> Mikhail, will you be able to get your fix in soon as well?
> 
> Nope. Don't wait for SOLR-13126, it turns to be more complicated. 
>  
> 
>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi Alan,
>> 
>> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
>> 
>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> Hi Shalin,
>> 
>> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
>> 
>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> Hi Alan,
>>> 
>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>>> 
>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>>> 
>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>>> 
>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
>>>> 
>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>> 
>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>>> 
>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>>> 
>>>>> Cassandra
>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>>> 
>>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>>> 
>>>>>> 
>>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >
>>>>>> > Hey Alan,
>>>>>> >
>>>>>> > I just committed a minor inconsequential bugfix
>>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>>> > from commits I see you made this morning preparing for the RC I
>>>>>> > suspect I cut things _very_ close and just missed it.
>>>>>> >
>>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>> > go back and update CHANGES.txt I think.
>>>>>> >
>>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>>> > Thanks for stepping up and handling the release.
>>>>>> >
>>>>>> > Best,
>>>>>> >
>>>>>> > Jason
>>>>>> >
>>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>
>>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>>> >> I'll be more careful next time ;).
>>>>>> >>
>>>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>>> >>
>>>>>> >> Jim
>>>>>> >>
>>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>
>>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>>> >>>
>>>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>> >>>
>>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>>> >>>
>>>>>> >>> Cassandra
>>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>>>> >>>
>>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>>> >>>
>>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>
>>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>> >>>
>>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>
>>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>>> >>>
>>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>
>>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>
>>>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>>> >>>>
>>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>>> >>>>
>>>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>> >>>>
>>>>>> >>>> ~ David
>>>>>> >>>>
>>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>>> >>>>> no issues so far.
>>>>>> >>>>>
>>>>>> >>>>> Kevin Risden
>>>>>> >>>>>
>>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>> >>>>>>
>>>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>>>>> >>>>>>
>>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>
>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>> >>>>>>>
>>>>>> >>>>>>> - Nick
>>>>>> >>>>>>>
>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> Hey Jim,
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Jim,
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>> >>>>>>>>>> currently under review.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Kevin Risden
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Thanks,
>>>>>> >>>>>>>>>>>> Jim
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> Regards,
>>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>> >>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 --
>>>>>> >>>>>>>>>>>>&g
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev

Re: Lucene/Solr 8.0

[Mikhail Khludnev <mk...@apache.org>]

On Thu, Feb 14, 2019 at 10:08 PM Mikhail Khludnev <mk...@apache.org> wrote:

> Thank you, Alan. Give me an hour.
>
> чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:
>
>> OK, let’s do an RC2.  When do you think you can have a fix in?
>>
>> Mikhail, will you be able to get your fix in soon as well?
>>
>
Nope. Don't wait for SOLR-13126, it turns to be more complicated.


>
>> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
>> wrote:
>>
>> Hi Alan,
>>
>> There is a work-around which is to change the default to using legacy
>> assignment using cluster properties. But I don't like the idea of releasing
>> something that we know is broken and asking everyone to set a cluster
>> property to workaround it. I'd rather just rollback the commits that caused
>> the problem and then release 8.0
>>
>> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>>
>>> Hi Shalin,
>>>
>>> I'm not familiar with this bit of code - is there a workaround
>>> available?  ie a way of using a different replica placement strategy when
>>> creating a collection?  If there is, I'd be tempted to continue with the
>>> vote as is and then do an immediate 8.0.1 release once you have things
>>> fixed, particularly if we’re going to require a 7.7.1 as well.
>>>
>>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
>>> wrote:
>>>
>>> Hi Alan,
>>>
>>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
>>> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
>>> interest of time, I propose rolling back SOLR-12739 which caused these
>>> issues. We can re-introduce it with proper fixes for the related issues in
>>> 8.1.
>>>
>>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>>
>>>> The release candidate has already been built and voting is in progress,
>>>> so it’s missed the boat unless there’s a respin.  It does look like a nasty
>>>> bug though, so if you have a fix then feel free too commit it to the 8_0
>>>> branch in case we do an 8.0.1 release.
>>>>
>>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>>
>>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>>
>>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0
>>>>> branch.
>>>>>
>>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
>>>>> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>>>>> since there’s a lot of editing yet to be done for it.
>>>>>
>>>>> Cassandra
>>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>>>>> wrote:
>>>>>
>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
>>>>> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
>>>>> even if it's committed after the 8.0 for the code?  I could avoid touching
>>>>> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
>>>>> change list any way).
>>>>>
>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Thanks for letting me know Jason.  Your commit will have missed the
>>>>>> cut, yes, but I don’t think it matters that much.  It will get picked up in
>>>>>> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>>>>> then we can just alter CHANGES.txt
>>>>>>
>>>>>>
>>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>>>>> wrote:
>>>>>> >
>>>>>> > Hey Alan,
>>>>>> >
>>>>>> > I just committed a minor inconsequential bugfix
>>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>>> > from commits I see you made this morning preparing for the RC I
>>>>>> > suspect I cut things _very_ close and just missed it.
>>>>>> >
>>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>>> > included in 8.0, but it's not imperative by any means if I've
>>>>>> already
>>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>>> > go back and update CHANGES.txt I think.
>>>>>> >
>>>>>> > Sorry again for the potential complication.  I hate to be "that
>>>>>> guy".
>>>>>> > Thanks for stepping up and handling the release.
>>>>>> >
>>>>>> > Best,
>>>>>> >
>>>>>> > Jason
>>>>>> >
>>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <
>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>> >>
>>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this
>>>>>> too many times in the past so I just mechanically changed the redirect
>>>>>> without thinking of when or if the ref guide was also released.
>>>>>> >> I'll be more careful next time ;).
>>>>>> >>
>>>>>> >> On another note, now that 7.7 is out and that we're preparing the
>>>>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>>>>> was already discussed some time ago
>>>>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that
>>>>>> we reached a consensus and we have maybe new options with the move to
>>>>>> gitbox. One option discussed in the thread was to remove all files and add
>>>>>> a README that says that this branch is dead. I don't know if it's possible
>>>>>> but we could also make the branch protected in gitbox in order to avoid new
>>>>>> commits. What do you think ? Should we keep this branch and just consider
>>>>>> new commits as useless or should we try to "clean up" all Nx branches that
>>>>>> are not active anymore (5x, 6x, 7x) ?
>>>>>> >>
>>>>>> >> Jim
>>>>>> >>
>>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>>>>> casstargett@gmail.com> a écrit :
>>>>>> >>>
>>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>>>>>> just do a blanket find/replace in .htaccess to update the version. If we’re
>>>>>> not going to coordinate binary releases with Ref Guide releases, we need to
>>>>>> be careful not to change the redirects unless that version’s Ref Guide
>>>>>> release is also imminent.
>>>>>> >>>
>>>>>> >>> This is noted in the ReleaseToDo (
>>>>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>>>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>>>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>>> >>>
>>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so
>>>>>> it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
>>>>>> else needs to maybe take care of it), but all non-version specific Ref
>>>>>> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
>>>>>> fix, but we have an easy way to avoid routing people to dead links.
>>>>>> >>>
>>>>>> >>> Cassandra
>>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <
>>>>>> romseygeek@gmail.com>, wrote:
>>>>>> >>>
>>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>>>>>> volunteer to be the manager for this round.  My current plan is to build a
>>>>>> release candidate early next week, as soon as the 7.7 release has been
>>>>>> announced.
>>>>>> >>>
>>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> It is a shame, I agree, but some of this stuff has been
>>>>>> deprecated since 3.6, so another release cycle won’t hurt :). We should
>>>>>> prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>>> >>>
>>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>>>>> wrote:
>>>>>> >>>
>>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the
>>>>>> 8.0 cycle to remove things that have been deprecated in previous releases?
>>>>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>>>>> further.
>>>>>> >>>
>>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <
>>>>>> romseygeek@gmail.com> wrote:
>>>>>> >>>>
>>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we
>>>>>> may need to back port some extra deprecations to 8x.  We don’t necessarily
>>>>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
>>>>>> any problems.  I opened the issues to ensure that we didn’t keep carrying
>>>>>> deprecated code through any further releases.
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>>>>> wrote:
>>>>>> >>>>
>>>>>> >>>> I want to ensure people are aware of two issues "Remove
>>>>>> deprecated code in master" that Alan filed:
>>>>>> >>>>
>>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>>> >>>>
>>>>>> >>>> Although both issues are marked "master (9.0)", I think the
>>>>>> intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>>> >>>>
>>>>>> >>>> ~ David
>>>>>> >>>>
>>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>>>>> wrote:
>>>>>> >>>>>
>>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
>>>>>> 8.0.
>>>>>> >>>>> I'm keeping any eye on the builds this weekend but all
>>>>>> indications are
>>>>>> >>>>> no issues so far.
>>>>>> >>>>>
>>>>>> >>>>> Kevin Risden
>>>>>> >>>>>
>>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>>>>> wrote:
>>>>>> >>>>>>
>>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you
>>>>>> have a look?
>>>>>> >>>>>>
>>>>>> >>>>>> See eg.
>>>>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console
>>>>>> .
>>>>>> >>>>>>
>>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <
>>>>>> nknize@gmail.com> wrote:
>>>>>> >>>>>>>
>>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>> >>>>>>>
>>>>>> >>>>>>> - Nick
>>>>>> >>>>>>>
>>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>>>>> start the first RC when your patch is merged.
>>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's
>>>>>> a good idea to rush this in for 8.0. Would it be safer to target another
>>>>>> version in order to take some time to ensure that it's not breaking
>>>>>> anything ? I guess that your concern is that a change like this should
>>>>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>>>>> this part of the code and the implications of such a change so I let you
>>>>>> decide what we should do here but let's not delay the release if we realize
>>>>>> that this change requires more than a few days to be merged.
>>>>>> >>>>>>>>
>>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <
>>>>>> nknize@gmail.com> a écrit :
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> Hey Jim,
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> I just added
>>>>>> https://issues.apache.org/jira/browse/LUCENE-8669 along with a
>>>>>> pretty straightforward patch. This is a critical one that I think needs to
>>>>>> be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>> >>>>>>>>>
>>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Jim,
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>>>>> time to get
>>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated
>>>>>> and it is
>>>>>> >>>>>>>>>> currently under review.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm
>>>>>> curious if others
>>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> Kevin Risden
>>>>>> >>>>>>>>>>
>>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>>>>> jim.ferenczi@gmail.com> wrote:
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on
>>>>>> branch_8x because we don't handle two concurrent releases in our tests (
>>>>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins
>>>>>> job for this version only and will build the first candidate for this
>>>>>> version later this week if there are no objection.
>>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>>
>>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>>>>> jim.ferenczi@gmail.com> a écrit :
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>>>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>>>>> add them to the Policeman's Jenkins job ?
>>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has
>>>>>> started for both versions (7.7 and 8.0):
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug
>>>>>> fixes may be committed to the branch. However, you should submit all
>>>>>> patches you want to commit to Jira first to give others the chance to
>>>>>> review and possibly vote against the patch. Keep in mind that it is our
>>>>>> main intention to keep the branch as stable as possible.
>>>>>> >>>>>>>>>>>> All patches that are intended for the branch should
>>>>>> first be committed to the unstable branch, merged into the stable branch,
>>>>>> and then into the current release branch.
>>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may
>>>>>> continue as usual. However, if you plan to commit a big change to the
>>>>>> unstable branch while the branch feature freeze is in effect, think twice:
>>>>>> can't the addition wait a couple more days? Merges of bug fixes into the
>>>>>> branch may become more difficult.
>>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>>>>> "Blocker" will delay a release candidate build.
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Thanks,
>>>>>> >>>>>>>>>>>> Jim
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>
>>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>> >>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>>>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>>>>> another week to work on a patch and we can update the status at the end of
>>>>>> the week in order to decide if we can start the first build candidate
>>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>> >>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> I'd like to backport
>>>>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>>>>> still time.
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> Regards,
>>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>>> >>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>> >>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>>>>> noble.paul@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>> >>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>>>>> david.w.smiley@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>>>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as
>>>>>> 8.0 blocker) that I feel pretty good about.  This provides a key part of
>>>>>> the nested document support.
>>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week
>>>>>> -- SOLR-13129
>>>>>> >>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>>>>> jan.asf@cominvent.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>>>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>>>>> ooold bug.
>>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>>>>> feature in the UI and replace it with an error message popup or something.
>>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández
>>>>>> Löbbe <to...@gmail.com>:
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As
>>>>>> long as there is a reasonable time horizon for the issue being resolved I'm
>>>>>> +1 on making it a blocker. I'm not familiar enough with the UI code to help
>>>>>> either unfortunately.
>>>>>> >>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>>>>> gus.heck@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker
>>>>>> once before... And it's actually
>>>>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>>>>> a duplicate of an earlier issue (
>>>>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>>>>> question of whether or not overall quality has a bearing on the decision to
>>>>>> release. As it turns out the screen shot I posted to the issue is less than
>>>>>> half of the shards that eventually got created since there was an
>>>>>> outstanding queue of requests still processing at the time. I'm now having
>>>>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>>>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>>>>> or less makes it impossible to recommend the use of the admin UI for
>>>>>> anything other than read only observation of the cluster. Now imagine
>>>>>> someone leaves a browser window open and forgets about it rather than
>>>>>> browsing away or closing the window, not knowing that it's silently pumping
>>>>>> out requests after showing an error... would completely hose a node, and
>>>>>> until they tracked down the source of the requests, (hope he didn't go
>>>>>> home) it would be impossible to resolve...
>>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>>>>> jpountz@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on
>>>>>> its own, I'd rather not
>>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>>>>> since this isn't a new
>>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that
>>>>>> has affected Solr
>>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the
>>>>>> UI code at all, but
>>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>>>>> before we build a RC?
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>>>>> gus.heck@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>>>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to
>>>>>> block 8.0. I just got burned by it a second time.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>>>>> uwe@thetaphi.de> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>>>>> guess as possible on the FOSDEM conference!
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting
>>>>>> on the week of February 4th.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi
>>>>>> <ji...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to
>>>>>> start on releasing 8.0. The branch is
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>>>>> anytime now. Unless there are
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature
>>>>>> freeze next week in order to build the
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think
>>>>>> we can handle both with Alan so
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to
>>>>>> start the release process or if there
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan
>>>>>> Woodward <ro...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>>>>> deprecations on the new master
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m
>>>>>> going to need some assistance for
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>>>>> what to do.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA,
>>>>>> one for lucene and one for Solr,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to
>>>>>> be removed in each one.  I’ll create
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against,
>>>>>> and push the changes I’ve already
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual
>>>>>> JIRA issues for any changes that
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>>>>> particularly for the Solr deprecations
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar
>>>>>> with.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>>>>> romseygeek@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>>>>> release at the same time as 8.0, to
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>>>>>> let’s keep those jobs enabled
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>>>>> uwe@thetaphi.de> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>>>>>> Jenkins once I have some time
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with
>>>>>> branch_7x? Should we stop using it
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>>>>> branch_7_6 only for bugfixes), or
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7?
>>>>>> In the latter case I would keep
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit…
>>>>>> I’ve just created a branch for 8x
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of
>>>>>> updating the master branch to version
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in
>>>>>> the 8.0 release should also be
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze,
>>>>>> as I know there are still some
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>>>>> should let us clean up master by
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as
>>>>>> possible, and give us an idea of any
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>>>>> david.w.smiley@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>>>>> sg.online.email@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>>>>> soon as there is an enhancement
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get
>>>>>> our hands on.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David
>>>>>> Smiley
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this
>>>>>> filter:   project in (SOLR, LUCENE) AND
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>>>>> fixVersion = "master (8.0)"
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to
>>>>>> work on those issues not yet
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>>>>>> Grand <jp...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan
>>>>>> Woodward
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>>>>> Nick!) we should think about
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>>>>> 9.0.  I’ll volunteer to create the
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>>>>> should have some time to
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover
>>>>>> anything that still needs to be done
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process
>>>>>> next year.
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra
>>>>>> Targett <ca...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM
>>>>>> Nicholas Knize
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à
>>>>>> 10:36, jim ferenczi
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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 --
>>>>>> >>>>>>>>>>>>&g
>>>>>
>>>>>

-- 
Sincerely yours
Mikhail Khludnev

Re: Lucene/Solr 8.0

[Mikhail Khludnev <mk...@apache.org>]

Thank you, Alan. Give me an hour.

чт, 14 февр. 2019 г., 20:59 Alan Woodward romseygeek@gmail.com:

> OK, let’s do an RC2.  When do you think you can have a fix in?
>
> Mikhail, will you be able to get your fix in soon as well?
>
> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
>
> Hi Alan,
>
> There is a work-around which is to change the default to using legacy
> assignment using cluster properties. But I don't like the idea of releasing
> something that we know is broken and asking everyone to set a cluster
> property to workaround it. I'd rather just rollback the commits that caused
> the problem and then release 8.0
>
> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>> Hi Shalin,
>>
>> I'm not familiar with this bit of code - is there a workaround
>> available?  ie a way of using a different replica placement strategy when
>> creating a collection?  If there is, I'd be tempted to continue with the
>> vote as is and then do an immediate 8.0.1 release once you have things
>> fixed, particularly if we’re going to require a 7.7.1 as well.
>>
>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
>> wrote:
>>
>> Hi Alan,
>>
>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
>> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
>> interest of time, I propose rolling back SOLR-12739 which caused these
>> issues. We can re-introduce it with proper fixes for the related issues in
>> 8.1.
>>
>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
>> wrote:
>>
>>> The release candidate has already been built and voting is in progress,
>>> so it’s missed the boat unless there’s a respin.  It does look like a nasty
>>> bug though, so if you have a fix then feel free too commit it to the 8_0
>>> branch in case we do an 8.0.1 release.
>>>
>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>>
>>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>>
>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>>
>>>> I have no problem with bug-fixes and ref-guide changes on the 8_0
>>>> branch.
>>>>
>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>>>> wrote:
>>>>
>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
>>>> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>>>> since there’s a lot of editing yet to be done for it.
>>>>
>>>> Cassandra
>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>>>> wrote:
>>>>
>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
>>>> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
>>>> even if it's committed after the 8.0 for the code?  I could avoid touching
>>>> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
>>>> change list any way).
>>>>
>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>>>> wrote:
>>>>
>>>>> Thanks for letting me know Jason.  Your commit will have missed the
>>>>> cut, yes, but I don’t think it matters that much.  It will get picked up in
>>>>> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>>>> then we can just alter CHANGES.txt
>>>>>
>>>>>
>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>>>> wrote:
>>>>> >
>>>>> > Hey Alan,
>>>>> >
>>>>> > I just committed a minor inconsequential bugfix
>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>> > from commits I see you made this morning preparing for the RC I
>>>>> > suspect I cut things _very_ close and just missed it.
>>>>> >
>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>> > go back and update CHANGES.txt I think.
>>>>> >
>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>> > Thanks for stepping up and handling the release.
>>>>> >
>>>>> > Best,
>>>>> >
>>>>> > Jason
>>>>> >
>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>>>>> wrote:
>>>>> >>
>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
>>>>> many times in the past so I just mechanically changed the redirect without
>>>>> thinking of when or if the ref guide was also released.
>>>>> >> I'll be more careful next time ;).
>>>>> >>
>>>>> >> On another note, now that 7.7 is out and that we're preparing the
>>>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>>>> was already discussed some time ago
>>>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that
>>>>> we reached a consensus and we have maybe new options with the move to
>>>>> gitbox. One option discussed in the thread was to remove all files and add
>>>>> a README that says that this branch is dead. I don't know if it's possible
>>>>> but we could also make the branch protected in gitbox in order to avoid new
>>>>> commits. What do you think ? Should we keep this branch and just consider
>>>>> new commits as useless or should we try to "clean up" all Nx branches that
>>>>> are not active anymore (5x, 6x, 7x) ?
>>>>> >>
>>>>> >> Jim
>>>>> >>
>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>>>> casstargett@gmail.com> a écrit :
>>>>> >>>
>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>>>>> just do a blanket find/replace in .htaccess to update the version. If we’re
>>>>> not going to coordinate binary releases with Ref Guide releases, we need to
>>>>> be careful not to change the redirects unless that version’s Ref Guide
>>>>> release is also imminent.
>>>>> >>>
>>>>> >>> This is noted in the ReleaseToDo (
>>>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>> >>>
>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so
>>>>> it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
>>>>> else needs to maybe take care of it), but all non-version specific Ref
>>>>> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
>>>>> fix, but we have an easy way to avoid routing people to dead links.
>>>>> >>>
>>>>> >>> Cassandra
>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>>>>> wrote:
>>>>> >>>
>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>>>>> volunteer to be the manager for this round.  My current plan is to build a
>>>>> release candidate early next week, as soon as the 7.7 release has been
>>>>> announced.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated
>>>>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>>>>> cleaning this stuff up once 8.0 is out of the door though.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>>>> wrote:
>>>>> >>>
>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
>>>>> cycle to remove things that have been deprecated in previous releases?
>>>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>>>> further.
>>>>> >>>
>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we
>>>>> may need to back port some extra deprecations to 8x.  We don’t necessarily
>>>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
>>>>> any problems.  I opened the issues to ensure that we didn’t keep carrying
>>>>> deprecated code through any further releases.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> I want to ensure people are aware of two issues "Remove
>>>>> deprecated code in master" that Alan filed:
>>>>> >>>>
>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>> >>>>
>>>>> >>>> Although both issues are marked "master (9.0)", I think the
>>>>> intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>> >>>>
>>>>> >>>> ~ David
>>>>> >>>>
>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
>>>>> 8.0.
>>>>> >>>>> I'm keeping any eye on the builds this weekend but all
>>>>> indications are
>>>>> >>>>> no issues so far.
>>>>> >>>>>
>>>>> >>>>> Kevin Risden
>>>>> >>>>>
>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>>>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you
>>>>> have a look?
>>>>> >>>>>>
>>>>> >>>>>> See eg.
>>>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>>> >>>>>>
>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <
>>>>> nknize@gmail.com> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>> >>>>>>>
>>>>> >>>>>>> - Nick
>>>>> >>>>>>>
>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>>>> jim.ferenczi@gmail.com> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>>>> start the first RC when your patch is merged.
>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's
>>>>> a good idea to rush this in for 8.0. Would it be safer to target another
>>>>> version in order to take some time to ensure that it's not breaking
>>>>> anything ? I guess that your concern is that a change like this should
>>>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>>>> this part of the code and the implications of such a change so I let you
>>>>> decide what we should do here but let's not delay the release if we realize
>>>>> that this change requires more than a few days to be merged.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <
>>>>> nknize@gmail.com> a écrit :
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hey Jim,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I just added
>>>>> https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty
>>>>> straightforward patch. This is a critical one that I think needs to be in
>>>>> for 7.7 and 8.0. Can I set this as a blocker?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Jim,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>>>> time to get
>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated
>>>>> and it is
>>>>> >>>>>>>>>> currently under review.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm
>>>>> curious if others
>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Kevin Risden
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>>>> jim.ferenczi@gmail.com> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on
>>>>> branch_8x because we don't handle two concurrent releases in our tests (
>>>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins
>>>>> job for this version only and will build the first candidate for this
>>>>> version later this week if there are no objection.
>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>>>> jim.ferenczi@gmail.com> a écrit :
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>>>> add them to the Policeman's Jenkins job ?
>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started
>>>>> for both versions (7.7 and 8.0):
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug
>>>>> fixes may be committed to the branch. However, you should submit all
>>>>> patches you want to commit to Jira first to give others the chance to
>>>>> review and possibly vote against the patch. Keep in mind that it is our
>>>>> main intention to keep the branch as stable as possible.
>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first
>>>>> be committed to the unstable branch, merged into the stable branch, and
>>>>> then into the current release branch.
>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may
>>>>> continue as usual. However, if you plan to commit a big change to the
>>>>> unstable branch while the branch feature freeze is in effect, think twice:
>>>>> can't the addition wait a couple more days? Merges of bug fixes into the
>>>>> branch may become more difficult.
>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>>>> "Blocker" will delay a release candidate build.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Thanks,
>>>>> >>>>>>>>>>>> Jim
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>>>> another week to work on a patch and we can update the status at the end of
>>>>> the week in order to decide if we can start the first build candidate
>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>>>> tommaso.teofili@gmail.com> a écrit :
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> I'd like to backport
>>>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>>>> still time.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Regards,
>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>>>> noble.paul@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>>>> david.w.smiley@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as
>>>>> 8.0 blocker) that I feel pretty good about.  This provides a key part of
>>>>> the nested document support.
>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week
>>>>> -- SOLR-13129
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>>>> jan.asf@cominvent.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>>>> ooold bug.
>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>>>> feature in the UI and replace it with an error message popup or something.
>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández
>>>>> Löbbe <to...@gmail.com>:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As
>>>>> long as there is a reasonable time horizon for the issue being resolved I'm
>>>>> +1 on making it a blocker. I'm not familiar enough with the UI code to help
>>>>> either unfortunately.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>>>> gus.heck@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker
>>>>> once before... And it's actually
>>>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>>>> a duplicate of an earlier issue (
>>>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>>>> question of whether or not overall quality has a bearing on the decision to
>>>>> release. As it turns out the screen shot I posted to the issue is less than
>>>>> half of the shards that eventually got created since there was an
>>>>> outstanding queue of requests still processing at the time. I'm now having
>>>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>>>> or less makes it impossible to recommend the use of the admin UI for
>>>>> anything other than read only observation of the cluster. Now imagine
>>>>> someone leaves a browser window open and forgets about it rather than
>>>>> browsing away or closing the window, not knowing that it's silently pumping
>>>>> out requests after showing an error... would completely hose a node, and
>>>>> until they tracked down the source of the requests, (hope he didn't go
>>>>> home) it would be impossible to resolve...
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>>>> jpountz@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
>>>>> own, I'd rather not
>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>>>> since this isn't a new
>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that
>>>>> has affected Solr
>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
>>>>> code at all, but
>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>>>> before we build a RC?
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>>>> gus.heck@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>>>> 8.0. I just got burned by it a second time.
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>>>> uwe@thetaphi.de> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>>>> guess as possible on the FOSDEM conference!
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting
>>>>> on the week of February 4th.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>>>> jim.ferenczi@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start
>>>>> on releasing 8.0. The branch is
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>>>> anytime now. Unless there are
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature
>>>>> freeze next week in order to build the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we
>>>>> can handle both with Alan so
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to
>>>>> start the release process or if there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward
>>>>> <ro...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>>>> deprecations on the new master
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m
>>>>> going to need some assistance for
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>>>> what to do.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA,
>>>>> one for lucene and one for Solr,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to
>>>>> be removed in each one.  I’ll create
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against,
>>>>> and push the changes I’ve already
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual
>>>>> JIRA issues for any changes that
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>>>> particularly for the Solr deprecations
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar
>>>>> with.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>>>> romseygeek@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>>>> release at the same time as 8.0, to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>>>>> let’s keep those jobs enabled
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>>>> uwe@thetaphi.de> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>>>>> Jenkins once I have some time
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with
>>>>> branch_7x? Should we stop using it
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>>>> branch_7_6 only for bugfixes), or
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7?
>>>>> In the latter case I would keep
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
>>>>> just created a branch for 8x
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of
>>>>> updating the master branch to version
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in
>>>>> the 8.0 release should also be
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze,
>>>>> as I know there are still some
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>>>> should let us clean up master by
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible,
>>>>> and give us an idea of any
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>>>> david.w.smiley@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>>>> sg.online.email@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>>>> soon as there is an enhancement
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
>>>>> hands on.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>>>>>  project in (SOLR, LUCENE) AND
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>>>> fixVersion = "master (8.0)"
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work
>>>>> on those issues not yet
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>>>>> Grand <jp...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan
>>>>> Woodward
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>>>> Nick!) we should think about
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>>>> 9.0.  I’ll volunteer to create the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>>>> should have some time to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover
>>>>> anything that still needs to be done
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process
>>>>> next year.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra
>>>>> Targett <ca...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM
>>>>> Nicholas Knize
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à
>>>>> 10:36, jim ferenczi
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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 --
>>>>> >>>>>>>>>>>>&g
>>>>
>>>>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

OK, let’s do an RC2.  When do you think you can have a fix in?

Mikhail, will you be able to get your fix in soon as well?

> On 14 Feb 2019, at 14:34, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> 
> Hi Alan,
> 
> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> 
> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> Hi Shalin,
> 
> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> 
>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi Alan,
>> 
>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>> 
>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>> 
>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>> 
>>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
>>> 
>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>> 
>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>> 
>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>> 
>>>> Cassandra
>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>> 
>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>> 
>>>>> 
>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>>> >
>>>>> > Hey Alan,
>>>>> >
>>>>> > I just committed a minor inconsequential bugfix
>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>> > from commits I see you made this morning preparing for the RC I
>>>>> > suspect I cut things _very_ close and just missed it.
>>>>> >
>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>> > go back and update CHANGES.txt I think.
>>>>> >
>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>> > Thanks for stepping up and handling the release.
>>>>> >
>>>>> > Best,
>>>>> >
>>>>> > Jason
>>>>> >
>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>
>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>> >> I'll be more careful next time ;).
>>>>> >>
>>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>> >>
>>>>> >> Jim
>>>>> >>
>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>
>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>> >>>
>>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>> >>>
>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>> >>>
>>>>> >>> Cassandra
>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>>> >>>
>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>> >>>
>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>> >>>>
>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>> >>>>
>>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>> >>>>
>>>>> >>>> ~ David
>>>>> >>>>
>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>> >>>>>
>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>> >>>>> no issues so far.
>>>>> >>>>>
>>>>> >>>>> Kevin Risden
>>>>> >>>>>
>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>> >>>>>>
>>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>>>> >>>>>>
>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>> >>>>>>>
>>>>> >>>>>>> - Nick
>>>>> >>>>>>>
>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hey Jim,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Jim,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>> >>>>>>>>>> currently under review.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Kevin Risden
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Thanks,
>>>>> >>>>>>>>>>>> Jim
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Regards,
>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8204>)
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> --
>>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>> 
>>> 
>>> -- 
>>> Sincerely yours
>>> Mikhail Khludnev
>> 
>> 
>> 
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: Lucene/Solr 8.0

[Jan Høydahl <ja...@cominvent.com>]

Can we simply flip the default for that cluster property from false to true, so we keep all the committed code from SOLR-12739 but default to legacy behavior? Looks like it's only two lines in Assign.java that needs change?

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 14. feb. 2019 kl. 15:34 skrev Shalin Shekhar Mangar <sh...@gmail.com>:
> 
> Hi Alan,
> 
> There is a work-around which is to change the default to using legacy assignment using cluster properties. But I don't like the idea of releasing something that we know is broken and asking everyone to set a cluster property to workaround it. I'd rather just rollback the commits that caused the problem and then release 8.0
> 
> On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> Hi Shalin,
> 
> I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.
> 
>> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <shalinmangar@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Hi Alan,
>> 
>> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
>> 
>> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
>> 
>>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>>> 
>>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
>>> 
>>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>> 
>>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>> 
>>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>>> 
>>>> Cassandra
>>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>>> 
>>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>>> 
>>>>> 
>>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>>> >
>>>>> > Hey Alan,
>>>>> >
>>>>> > I just committed a minor inconsequential bugfix
>>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>>> > from commits I see you made this morning preparing for the RC I
>>>>> > suspect I cut things _very_ close and just missed it.
>>>>> >
>>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>>> > missed the first RC, or it's easier for you to omit from potential
>>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>>> > go back and update CHANGES.txt I think.
>>>>> >
>>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>>> > Thanks for stepping up and handling the release.
>>>>> >
>>>>> > Best,
>>>>> >
>>>>> > Jason
>>>>> >
>>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>
>>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>>> >> I'll be more careful next time ;).
>>>>> >>
>>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>>> >>
>>>>> >> Jim
>>>>> >>
>>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>
>>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>>> >>>
>>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>>> >>>
>>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>>> >>>
>>>>> >>> Cassandra
>>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>>> >>>
>>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>>> >>>
>>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>>> >>>
>>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>>> >>>>
>>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>>>> >>>> There's a "master-deprecations" branch as well.
>>>>> >>>>
>>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>>> >>>>
>>>>> >>>> ~ David
>>>>> >>>>
>>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>> >>>>>
>>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>> >>>>> no issues so far.
>>>>> >>>>>
>>>>> >>>>> Kevin Risden
>>>>> >>>>>
>>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>
>>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>> >>>>>>
>>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>>>> >>>>>>
>>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>
>>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>> >>>>>>>
>>>>> >>>>>>> - Nick
>>>>> >>>>>>>
>>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>
>>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>> >>>>>>>>
>>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> Hey Jim,
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>> >>>>>>>>>
>>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Jim,
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>> >>>>>>>>>> currently under review.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> Kevin Risden
>>>>> >>>>>>>>>>
>>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>>
>>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Thanks,
>>>>> >>>>>>>>>>>> Jim
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>>
>>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>> >>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Regards,
>>>>> >>>>>>>>>>>>>>> Tommaso
>>>>> >>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>> >>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>> >>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>> >>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> --
>>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>> >>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>> >>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8204>)
>>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>>> --
>>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>> 
>>> 
>>> -- 
>>> Sincerely yours
>>> Mikhail Khludnev
>> 
>> 
>> 
>> -- 
>> Regards,
>> Shalin Shekhar Mangar.
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: Lucene/Solr 8.0

[Shalin Shekhar Mangar <sh...@gmail.com>]

Hi Alan,

There is a work-around which is to change the default to using legacy
assignment using cluster properties. But I don't like the idea of releasing
something that we know is broken and asking everyone to set a cluster
property to workaround it. I'd rather just rollback the commits that caused
the problem and then release 8.0

On Thu, Feb 14, 2019 at 7:11 PM Alan Woodward <ro...@gmail.com> wrote:

> Hi Shalin,
>
> I'm not familiar with this bit of code - is there a workaround available?
> ie a way of using a different replica placement strategy when creating a
> collection?  If there is, I'd be tempted to continue with the vote as is
> and then do an immediate 8.0.1 release once you have things fixed,
> particularly if we’re going to require a 7.7.1 as well.
>
> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com>
> wrote:
>
> Hi Alan,
>
> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
> blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
> interest of time, I propose rolling back SOLR-12739 which caused these
> issues. We can re-introduce it with proper fixes for the related issues in
> 8.1.
>
> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com>
> wrote:
>
>> The release candidate has already been built and voting is in progress,
>> so it’s missed the boat unless there’s a respin.  It does look like a nasty
>> bug though, so if you have a fix then feel free too commit it to the 8_0
>> branch in case we do an 8.0.1 release.
>>
>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>>
>> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>>
>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>>
>>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>>
>>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>>> wrote:
>>>
>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even
>>> to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>>> since there’s a lot of editing yet to be done for it.
>>>
>>> Cassandra
>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>>> wrote:
>>>
>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
>>> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
>>> even if it's committed after the 8.0 for the code?  I could avoid touching
>>> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
>>> change list any way).
>>>
>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>>
>>>> Thanks for letting me know Jason.  Your commit will have missed the
>>>> cut, yes, but I don’t think it matters that much.  It will get picked up in
>>>> a respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>>> then we can just alter CHANGES.txt
>>>>
>>>>
>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>>> wrote:
>>>> >
>>>> > Hey Alan,
>>>> >
>>>> > I just committed a minor inconsequential bugfix
>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>> > from commits I see you made this morning preparing for the RC I
>>>> > suspect I cut things _very_ close and just missed it.
>>>> >
>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>> > missed the first RC, or it's easier for you to omit from potential
>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>> > go back and update CHANGES.txt I think.
>>>> >
>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>> > Thanks for stepping up and handling the release.
>>>> >
>>>> > Best,
>>>> >
>>>> > Jason
>>>> >
>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>>>> wrote:
>>>> >>
>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
>>>> many times in the past so I just mechanically changed the redirect without
>>>> thinking of when or if the ref guide was also released.
>>>> >> I'll be more careful next time ;).
>>>> >>
>>>> >> On another note, now that 7.7 is out and that we're preparing the
>>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>>> was already discussed some time ago
>>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that
>>>> we reached a consensus and we have maybe new options with the move to
>>>> gitbox. One option discussed in the thread was to remove all files and add
>>>> a README that says that this branch is dead. I don't know if it's possible
>>>> but we could also make the branch protected in gitbox in order to avoid new
>>>> commits. What do you think ? Should we keep this branch and just consider
>>>> new commits as useless or should we try to "clean up" all Nx branches that
>>>> are not active anymore (5x, 6x, 7x) ?
>>>> >>
>>>> >> Jim
>>>> >>
>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>>> casstargett@gmail.com> a écrit :
>>>> >>>
>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>>>> just do a blanket find/replace in .htaccess to update the version. If we’re
>>>> not going to coordinate binary releases with Ref Guide releases, we need to
>>>> be careful not to change the redirects unless that version’s Ref Guide
>>>> release is also imminent.
>>>> >>>
>>>> >>> This is noted in the ReleaseToDo (
>>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>> >>>
>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so
>>>> it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone
>>>> else needs to maybe take care of it), but all non-version specific Ref
>>>> Guide link is now being routed to a non-existent 7.7 path. It’s easy to
>>>> fix, but we have an easy way to avoid routing people to dead links.
>>>> >>>
>>>> >>> Cassandra
>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>>>> wrote:
>>>> >>>
>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>>>> volunteer to be the manager for this round.  My current plan is to build a
>>>> release candidate early next week, as soon as the 7.7 release has been
>>>> announced.
>>>> >>>
>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated
>>>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>>>> cleaning this stuff up once 8.0 is out of the door though.
>>>> >>>
>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>>> wrote:
>>>> >>>
>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
>>>> cycle to remove things that have been deprecated in previous releases?
>>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>>> further.
>>>> >>>
>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we
>>>> may need to back port some extra deprecations to 8x.  We don’t necessarily
>>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
>>>> any problems.  I opened the issues to ensure that we didn’t keep carrying
>>>> deprecated code through any further releases.
>>>> >>>>
>>>> >>>>
>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>>> wrote:
>>>> >>>>
>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated
>>>> code in master" that Alan filed:
>>>> >>>>
>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>> >>>> There's a "master-deprecations" branch as well.
>>>> >>>>
>>>> >>>> Although both issues are marked "master (9.0)", I think the intent
>>>> is actually 8.0 so that we are finally rid of the deprecated code?
>>>> >>>>
>>>> >>>> ~ David
>>>> >>>>
>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>>> wrote:
>>>> >>>>>
>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
>>>> 8.0.
>>>> >>>>> I'm keeping any eye on the builds this weekend but all
>>>> indications are
>>>> >>>>> no issues so far.
>>>> >>>>>
>>>> >>>>> Kevin Risden
>>>> >>>>>
>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> Nick, this change seems to be causing test failures. Can you
>>>> have a look?
>>>> >>>>>>
>>>> >>>>>> See eg.
>>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>> >>>>>>
>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>>>> wrote:
>>>> >>>>>>>
>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>> >>>>>>>
>>>> >>>>>>> - Nick
>>>> >>>>>>>
>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>>> jim.ferenczi@gmail.com> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>>> start the first RC when your patch is merged.
>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a
>>>> good idea to rush this in for 8.0. Would it be safer to target another
>>>> version in order to take some time to ensure that it's not breaking
>>>> anything ? I guess that your concern is that a change like this should
>>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>>> this part of the code and the implications of such a change so I let you
>>>> decide what we should do here but let's not delay the release if we realize
>>>> that this change requires more than a few days to be merged.
>>>> >>>>>>>>
>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <
>>>> nknize@gmail.com> a écrit :
>>>> >>>>>>>>>
>>>> >>>>>>>>> Hey Jim,
>>>> >>>>>>>>>
>>>> >>>>>>>>> I just added
>>>> https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty
>>>> straightforward patch. This is a critical one that I think needs to be in
>>>> for 7.7 and 8.0. Can I set this as a blocker?
>>>> >>>>>>>>>
>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Jim,
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>>> time to get
>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated
>>>> and it is
>>>> >>>>>>>>>> currently under review.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious
>>>> if others
>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Kevin Risden
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>>> jim.ferenczi@gmail.com> wrote:
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x
>>>> because we don't handle two concurrent releases in our tests (
>>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins
>>>> job for this version only and will build the first candidate for this
>>>> version later this week if there are no objection.
>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>>> jim.ferenczi@gmail.com> a écrit :
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>>> add them to the Policeman's Jenkins job ?
>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started
>>>> for both versions (7.7 and 8.0):
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes
>>>> may be committed to the branch. However, you should submit all patches you
>>>> want to commit to Jira first to give others the chance to review and
>>>> possibly vote against the patch. Keep in mind that it is our main intention
>>>> to keep the branch as stable as possible.
>>>> >>>>>>>>>>>> All patches that are intended for the branch should first
>>>> be committed to the unstable branch, merged into the stable branch, and
>>>> then into the current release branch.
>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue
>>>> as usual. However, if you plan to commit a big change to the unstable
>>>> branch while the branch feature freeze is in effect, think twice: can't the
>>>> addition wait a couple more days? Merges of bug fixes into the branch may
>>>> become more difficult.
>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>>> "Blocker" will delay a release candidate build.
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Thanks,
>>>> >>>>>>>>>>>> Jim
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>>> tommaso.teofili@gmail.com> a écrit :
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Tommaso
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>>> another week to work on a patch and we can update the status at the end of
>>>> the week in order to decide if we can start the first build candidate
>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>>> tommaso.teofili@gmail.com> a écrit :
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> I'd like to backport
>>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>>> still time.
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> Regards,
>>>> >>>>>>>>>>>>>>> Tommaso
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>>> noble.paul@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>>> david.w.smiley@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as
>>>> 8.0 blocker) that I feel pretty good about.  This provides a key part of
>>>> the nested document support.
>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week
>>>> -- SOLR-13129
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>>> jan.asf@cominvent.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>>> ooold bug.
>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>>> feature in the UI and replace it with an error message popup or something.
>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> --
>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe
>>>> <to...@gmail.com>:
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As
>>>> long as there is a reasonable time horizon for the issue being resolved I'm
>>>> +1 on making it a blocker. I'm not familiar enough with the UI code to help
>>>> either unfortunately.
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>>> gus.heck@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker
>>>> once before... And it's actually
>>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>>> a duplicate of an earlier issue (
>>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>>> question of whether or not overall quality has a bearing on the decision to
>>>> release. As it turns out the screen shot I posted to the issue is less than
>>>> half of the shards that eventually got created since there was an
>>>> outstanding queue of requests still processing at the time. I'm now having
>>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>>> or less makes it impossible to recommend the use of the admin UI for
>>>> anything other than read only observation of the cluster. Now imagine
>>>> someone leaves a browser window open and forgets about it rather than
>>>> browsing away or closing the window, not knowing that it's silently pumping
>>>> out requests after showing an error... would completely hose a node, and
>>>> until they tracked down the source of the requests, (hope he didn't go
>>>> home) it would be impossible to resolve...
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>>> jpountz@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
>>>> own, I'd rather not
>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>>> since this isn't a new
>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that
>>>> has affected Solr
>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
>>>> code at all, but
>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>>> before we build a RC?
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>>> gus.heck@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>>> 8.0. I just got burned by it a second time.
>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>>> uwe@thetaphi.de> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>>> guess as possible on the FOSDEM conference!
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on
>>>> the week of February 4th.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>>> jim.ferenczi@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start
>>>> on releasing 8.0. The branch is
>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>>> anytime now. Unless there are
>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature
>>>> freeze next week in order to build the
>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we
>>>> can handle both with Alan so
>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start
>>>> the release process or if there
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>>>> romseygeek@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>>> deprecations on the new master
>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m
>>>> going to need some assistance for
>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>>> what to do.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA,
>>>> one for lucene and one for Solr,
>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be
>>>> removed in each one.  I’ll create
>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and
>>>> push the changes I’ve already
>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual
>>>> JIRA issues for any changes that
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>>> particularly for the Solr deprecations
>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar
>>>> with.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>>> romseygeek@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>>> release at the same time as 8.0, to
>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>>>> let’s keep those jobs enabled
>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>>> uwe@thetaphi.de> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>>>> Jenkins once I have some time
>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x?
>>>> Should we stop using it
>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>>> branch_7_6 only for bugfixes), or
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7?
>>>> In the latter case I would keep
>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
>>>> just created a branch for 8x
>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating
>>>> the master branch to version
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the
>>>> 8.0 release should also be
>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as
>>>> I know there are still some
>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>>> should let us clean up master by
>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible,
>>>> and give us an idea of any
>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>>> david.w.smiley@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>>> sg.online.email@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>>> soon as there is an enhancement
>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
>>>> hands on.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>>>>  project in (SOLR, LUCENE) AND
>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>>> fixVersion = "master (8.0)"
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work
>>>> on those issues not yet
>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand
>>>> <jp...@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan
>>>> Woodward
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>>> Nick!) we should think about
>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>>> 9.0.  I’ll volunteer to create the
>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>>> should have some time to
>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover
>>>> anything that still needs to be done
>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process
>>>> next year.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett
>>>> <ca...@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>>>> Knize
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36,
>>>> jim ferenczi
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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)
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>
>>> --
>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> http://www.solrenterprisesearchserver.com
>>>
>>>
>>>
>>
>> --
>> Sincerely yours
>> Mikhail Khludnev
>>
>>
>>
>
> --
> Regards,
> Shalin Shekhar Mangar.
>
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Hi Shalin,

I'm not familiar with this bit of code - is there a workaround available?  ie a way of using a different replica placement strategy when creating a collection?  If there is, I'd be tempted to continue with the vote as is and then do an immediate 8.0.1 release once you have things fixed, particularly if we’re going to require a 7.7.1 as well.

> On 14 Feb 2019, at 12:45, Shalin Shekhar Mangar <sh...@gmail.com> wrote:
> 
> Hi Alan,
> 
> I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the interest of time, I propose rolling back SOLR-12739 which caused these issues. We can re-introduce it with proper fixes for the related issues in 8.1.
> 
> On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.
> 
>> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mkhl@apache.org <ma...@apache.org>> wrote:
>> 
>> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
>> 
>> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>> 
>>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>>> 
>>> Cassandra
>>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>>> 
>>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>>> 
>>>> 
>>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>>> >
>>>> > Hey Alan,
>>>> >
>>>> > I just committed a minor inconsequential bugfix
>>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>>> > realize I was cutting it so close to your work on cutting RC1, but
>>>> > from commits I see you made this morning preparing for the RC I
>>>> > suspect I cut things _very_ close and just missed it.
>>>> >
>>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>>> > problems for you on the release end.  I'm happy to do whatever's
>>>> > easiest for you regarding that commit.  It'd be nice to have it
>>>> > included in 8.0, but it's not imperative by any means if I've already
>>>> > missed the first RC, or it's easier for you to omit from potential
>>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>>> > go back and update CHANGES.txt I think.
>>>> >
>>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>>> > Thanks for stepping up and handling the release.
>>>> >
>>>> > Best,
>>>> >
>>>> > Jason
>>>> >
>>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>> >>
>>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>>> >> I'll be more careful next time ;).
>>>> >>
>>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>>> >>
>>>> >> Jim
>>>> >>
>>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>
>>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>>> >>>
>>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>>> >>>
>>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>>> >>>
>>>> >>> Cassandra
>>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>>> >>>
>>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>>> >>>
>>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>
>>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>>> >>>
>>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>
>>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>>> >>>
>>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>
>>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>> >>>>
>>>> >>>>
>>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>
>>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>> >>>>
>>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>>> >>>> There's a "master-deprecations" branch as well.
>>>> >>>>
>>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>> >>>>
>>>> >>>> ~ David
>>>> >>>>
>>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>> >>>>>
>>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>> >>>>> no issues so far.
>>>> >>>>>
>>>> >>>>> Kevin Risden
>>>> >>>>>
>>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>
>>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>> >>>>>>
>>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>>> >>>>>>
>>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>
>>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>> >>>>>>>
>>>> >>>>>>> - Nick
>>>> >>>>>>>
>>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>
>>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>> >>>>>>>>
>>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>
>>>> >>>>>>>>> Hey Jim,
>>>> >>>>>>>>>
>>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>> >>>>>>>>>
>>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Jim,
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>> >>>>>>>>>> currently under review.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> Kevin Risden
>>>> >>>>>>>>>>
>>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>>
>>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Thanks,
>>>> >>>>>>>>>>>> Jim
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>>
>>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Tommaso
>>>> >>>>>>>>>>>>>
>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>>> >>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> Regards,
>>>> >>>>>>>>>>>>>>> Tommaso
>>>> >>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> Hi Noble,
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>>> >>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>> >>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>> >>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> --
>>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>> >>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>> >>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>>> >>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8204>)
>>>> >>>>>>>>>>>>>>>>>>>>>>>
>>>> --
>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>> 
>> 
>> -- 
>> Sincerely yours
>> Mikhail Khludnev
> 
> 
> 
> -- 
> Regards,
> Shalin Shekhar Mangar.

Re: Lucene/Solr 8.0

[Shalin Shekhar Mangar <sh...@gmail.com>]

Hi Alan,

I opened SOLR-13248 a few minutes ago. It is a bad bug that should be a
blocker for 8.0 and might require a bug fix 7.7.1 release as well. In the
interest of time, I propose rolling back SOLR-12739 which caused these
issues. We can re-introduce it with proper fixes for the related issues in
8.1.

On Thu, Feb 14, 2019 at 3:45 PM Alan Woodward <ro...@gmail.com> wrote:

> The release candidate has already been built and voting is in progress, so
> it’s missed the boat unless there’s a respin.  It does look like a nasty
> bug though, so if you have a fix then feel free too commit it to the 8_0
> branch in case we do an 8.0.1 release.
>
> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
>
> Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?
>
> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com>
> wrote:
>
>> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>>
>> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com>
>> wrote:
>>
>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to
>> Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
>> since there’s a lot of editing yet to be done for it.
>>
>> Cassandra
>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
>> wrote:
>>
>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
>> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
>> even if it's committed after the 8.0 for the code?  I could avoid touching
>> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
>> change list any way).
>>
>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>>
>>> Thanks for letting me know Jason.  Your commit will have missed the cut,
>>> yes, but I don’t think it matters that much.  It will get picked up in a
>>> respin or in any subsequent bug-fix release, and if RC1 passes the vote
>>> then we can just alter CHANGES.txt
>>>
>>>
>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>>> wrote:
>>> >
>>> > Hey Alan,
>>> >
>>> > I just committed a minor inconsequential bugfix
>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>> > realize I was cutting it so close to your work on cutting RC1, but
>>> > from commits I see you made this morning preparing for the RC I
>>> > suspect I cut things _very_ close and just missed it.
>>> >
>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>> > problems for you on the release end.  I'm happy to do whatever's
>>> > easiest for you regarding that commit.  It'd be nice to have it
>>> > included in 8.0, but it's not imperative by any means if I've already
>>> > missed the first RC, or it's easier for you to omit from potential
>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>> > go back and update CHANGES.txt I think.
>>> >
>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>> > Thanks for stepping up and handling the release.
>>> >
>>> > Best,
>>> >
>>> > Jason
>>> >
>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> >>
>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
>>> many times in the past so I just mechanically changed the redirect without
>>> thinking of when or if the ref guide was also released.
>>> >> I'll be more careful next time ;).
>>> >>
>>> >> On another note, now that 7.7 is out and that we're preparing the
>>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>>> was already discussed some time ago
>>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
>>> reached a consensus and we have maybe new options with the move to gitbox.
>>> One option discussed in the thread was to remove all files and add a README
>>> that says that this branch is dead. I don't know if it's possible but we
>>> could also make the branch protected in gitbox in order to avoid new
>>> commits. What do you think ? Should we keep this branch and just consider
>>> new commits as useless or should we try to "clean up" all Nx branches that
>>> are not active anymore (5x, 6x, 7x) ?
>>> >>
>>> >> Jim
>>> >>
>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>>> casstargett@gmail.com> a écrit :
>>> >>>
>>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>>> just do a blanket find/replace in .htaccess to update the version. If we’re
>>> not going to coordinate binary releases with Ref Guide releases, we need to
>>> be careful not to change the redirects unless that version’s Ref Guide
>>> release is also imminent.
>>> >>>
>>> >>> This is noted in the ReleaseToDo (
>>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>>> but I’ve seen it occur a little too soon for the past few releases…in those
>>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>> >>>
>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
>>> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
>>> needs to maybe take care of it), but all non-version specific Ref Guide
>>> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
>>> we have an easy way to avoid routing people to dead links.
>>> >>>
>>> >>> Cassandra
>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>>> wrote:
>>> >>>
>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>>> volunteer to be the manager for this round.  My current plan is to build a
>>> release candidate early next week, as soon as the 7.7 release has been
>>> announced.
>>> >>>
>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>> >>>
>>> >>> It is a shame, I agree, but some of this stuff has been deprecated
>>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>>> cleaning this stuff up once 8.0 is out of the door though.
>>> >>>
>>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>>> wrote:
>>> >>>
>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
>>> cycle to remove things that have been deprecated in previous releases?
>>> solr.LatLonType is one example.  It's a shame to keep around such things
>>> further.
>>> >>>
>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we
>>> may need to back port some extra deprecations to 8x.  We don’t necessarily
>>> need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without
>>> any problems.  I opened the issues to ensure that we didn’t keep carrying
>>> deprecated code through any further releases.
>>> >>>>
>>> >>>>
>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>>> wrote:
>>> >>>>
>>> >>>> I want to ensure people are aware of two issues "Remove deprecated
>>> code in master" that Alan filed:
>>> >>>>
>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>> >>>> There's a "master-deprecations" branch as well.
>>> >>>>
>>> >>>> Although both issues are marked "master (9.0)", I think the intent
>>> is actually 8.0 so that we are finally rid of the deprecated code?
>>> >>>>
>>> >>>> ~ David
>>> >>>>
>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>>> wrote:
>>> >>>>>
>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and
>>> 8.0.
>>> >>>>> I'm keeping any eye on the builds this weekend but all indications
>>> are
>>> >>>>> no issues so far.
>>> >>>>>
>>> >>>>> Kevin Risden
>>> >>>>>
>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>>> wrote:
>>> >>>>>>
>>> >>>>>> Nick, this change seems to be causing test failures. Can you have
>>> a look?
>>> >>>>>>
>>> >>>>>> See eg.
>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>> >>>>>>
>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>>> wrote:
>>> >>>>>>>
>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>> >>>>>>>
>>> >>>>>>> - Nick
>>> >>>>>>>
>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>>> jim.ferenczi@gmail.com> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>>> start the first RC when your patch is merged.
>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a
>>> good idea to rush this in for 8.0. Would it be safer to target another
>>> version in order to take some time to ensure that it's not breaking
>>> anything ? I guess that your concern is that a change like this should
>>> happen in a major version but I wonder if it's worth the risk. I don't know
>>> this part of the code and the implications of such a change so I let you
>>> decide what we should do here but let's not delay the release if we realize
>>> that this change requires more than a few days to be merged.
>>> >>>>>>>>
>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com>
>>> a écrit :
>>> >>>>>>>>>
>>> >>>>>>>>> Hey Jim,
>>> >>>>>>>>>
>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>>> along with a pretty straightforward patch. This is a critical one that I
>>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>> >>>>>>>>>
>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Jim,
>>> >>>>>>>>>>
>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave
>>> time to get
>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated
>>> and it is
>>> >>>>>>>>>> currently under review.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious
>>> if others
>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Kevin Risden
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>> jim.ferenczi@gmail.com> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x
>>> because we don't handle two concurrent releases in our tests (
>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job
>>> for this version only and will build the first candidate for this version
>>> later this week if there are no objection.
>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>> jim.ferenczi@gmail.com> a écrit :
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and
>>> 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also
>>> add them to the Policeman's Jenkins job ?
>>> >>>>>>>>>>>> This also means that the feature freeze phase has started
>>> for both versions (7.7 and 8.0):
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes
>>> may be committed to the branch. However, you should submit all patches you
>>> want to commit to Jira first to give others the chance to review and
>>> possibly vote against the patch. Keep in mind that it is our main intention
>>> to keep the branch as stable as possible.
>>> >>>>>>>>>>>> All patches that are intended for the branch should first
>>> be committed to the unstable branch, merged into the stable branch, and
>>> then into the current release branch.
>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue
>>> as usual. However, if you plan to commit a big change to the unstable
>>> branch while the branch feature freeze is in effect, think twice: can't the
>>> addition wait a couple more days? Merges of bug fixes into the branch may
>>> become more difficult.
>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>>> "Blocker" will delay a release candidate build.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Thanks,
>>> >>>>>>>>>>>> Jim
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> sure, thanks Jim!
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)
>>> tomorrow or wednesday and to announce the feature freeze the same day.
>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves
>>> another week to work on a patch and we can update the status at the end of
>>> the week in order to decide if we can start the first build candidate
>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I'd like to backport
>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's
>>> still time.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Regards,
>>> >>>>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> Hi Noble,
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>> noble.paul@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>> david.w.smiley@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>>> blocker) that I feel pretty good about.  This provides a key part of the
>>> nested document support.
>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week --
>>> SOLR-13129
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>> jan.asf@cominvent.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a
>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>> ooold bug.
>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering
>>> feature in the UI and replace it with an error message popup or something.
>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>>> tomasflobbe@gmail.com>:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long
>>> as there is a reasonable time horizon for the issue being resolved I'm +1
>>> on making it a blocker. I'm not familiar enough with the UI code to help
>>> either unfortunately.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once
>>> before... And it's actually
>>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>>> a duplicate of an earlier issue (
>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>> question of whether or not overall quality has a bearing on the decision to
>>> release. As it turns out the screen shot I posted to the issue is less than
>>> half of the shards that eventually got created since there was an
>>> outstanding queue of requests still processing at the time. I'm now having
>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>> or less makes it impossible to recommend the use of the admin UI for
>>> anything other than read only observation of the cluster. Now imagine
>>> someone leaves a browser window open and forgets about it rather than
>>> browsing away or closing the window, not knowing that it's silently pumping
>>> out requests after showing an error... would completely hose a node, and
>>> until they tracked down the source of the requests, (hope he didn't go
>>> home) it would be impossible to resolve...
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>> jpountz@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
>>> own, I'd rather not
>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>>> since this isn't a new
>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that
>>> has affected Solr
>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
>>> code at all, but
>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed
>>> before we build a RC?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>> 8.0. I just got burned by it a second time.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time
>>> guess as possible on the FOSDEM conference!
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on
>>> the week of February 4th.
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>> jim.ferenczi@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start
>>> on releasing 8.0. The branch is
>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>>> anytime now. Unless there are
>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze
>>> next week in order to build the
>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we
>>> can handle both with Alan so
>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start
>>> the release process or if there
>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>>> deprecations on the new master
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going
>>> to need some assistance for
>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear
>>> what to do.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one
>>> for lucene and one for Solr,
>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be
>>> removed in each one.  I’ll create
>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and
>>> push the changes I’ve already
>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA
>>> issues for any changes that
>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>>> particularly for the Solr deprecations
>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>>> release at the same time as 8.0, to
>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>>> let’s keep those jobs enabled
>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>>> Jenkins once I have some time
>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x?
>>> Should we stop using it
>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>>> branch_7_6 only for bugfixes), or
>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In
>>> the latter case I would keep
>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
>>> just created a branch for 8x
>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating
>>> the master branch to version
>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the
>>> 8.0 release should also be
>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as
>>> I know there are still some
>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>>> should let us clean up master by
>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible,
>>> and give us an idea of any
>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>>> david.w.smiley@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>> sg.online.email@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January
>>> soon as there is an enhancement
>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
>>> hands on.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>>>  project in (SOLR, LUCENE) AND
>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>>> fixVersion = "master (8.0)"
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work
>>> on those issues not yet
>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>>> jpountz@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>>> Nick!) we should think about
>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>>> 9.0.  I’ll volunteer to create the
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>>> should have some time to
>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything
>>> that still needs to be done
>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next
>>> year.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <
>>> casstargett@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>>> Knize
>>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36,
>>> jim ferenczi
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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)
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
>>
>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>
>
>

-- 
Regards,
Shalin Shekhar Mangar.

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

The release candidate has already been built and voting is in progress, so it’s missed the boat unless there’s a respin.  It does look like a nasty bug though, so if you have a fix then feel free too commit it to the 8_0 branch in case we do an 8.0.1 release.

> On 14 Feb 2019, at 09:35, Mikhail Khludnev <mk...@apache.org> wrote:
> 
> Does https://issues.apache.org/jira/browse/SOLR-13126 <https://issues.apache.org/jira/browse/SOLR-13126> fit for 8_0 ? 
> 
> On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
> 
>> On 13 Feb 2019, at 22:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>> 
>> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
>> 
>> Cassandra
>> On Feb 13, 2019, 4:20 PM -0600, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>, wrote:
>>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>>> 
>>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>>> 
>>> 
>>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>>> >
>>> > Hey Alan,
>>> >
>>> > I just committed a minor inconsequential bugfix
>>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>>> > realize I was cutting it so close to your work on cutting RC1, but
>>> > from commits I see you made this morning preparing for the RC I
>>> > suspect I cut things _very_ close and just missed it.
>>> >
>>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>>> > problems for you on the release end.  I'm happy to do whatever's
>>> > easiest for you regarding that commit.  It'd be nice to have it
>>> > included in 8.0, but it's not imperative by any means if I've already
>>> > missed the first RC, or it's easier for you to omit from potential
>>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>>> > go back and update CHANGES.txt I think.
>>> >
>>> > Sorry again for the potential complication.  I hate to be "that guy".
>>> > Thanks for stepping up and handling the release.
>>> >
>>> > Best,
>>> >
>>> > Jason
>>> >
>>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> >>
>>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>>> >> I'll be more careful next time ;).
>>> >>
>>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>>> >>
>>> >> Jim
>>> >>
>>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>
>>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>> >>>
>>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>> >>>
>>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>> >>>
>>> >>> Cassandra
>>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>>> >>>
>>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>> >>>
>>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> >>>
>>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>> >>>
>>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> >>>
>>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>> >>>
>>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>
>>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>> >>>>
>>> >>>>
>>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>
>>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>> >>>>
>>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>> >>>> There's a "master-deprecations" branch as well.
>>> >>>>
>>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>> >>>>
>>> >>>> ~ David
>>> >>>>
>>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>> >>>>>
>>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>>> >>>>> no issues so far.
>>> >>>>>
>>> >>>>> Kevin Risden
>>> >>>>>
>>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>
>>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>> >>>>>>
>>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>> >>>>>>
>>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>
>>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>> >>>>>>>
>>> >>>>>>> - Nick
>>> >>>>>>>
>>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>
>>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>> >>>>>>>>
>>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>
>>> >>>>>>>>> Hey Jim,
>>> >>>>>>>>>
>>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>> >>>>>>>>>
>>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>> >>>>>>>>>>
>>> >>>>>>>>>> Jim,
>>> >>>>>>>>>>
>>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>> >>>>>>>>>> currently under review.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>> >>>>>>>>>> feel this should make it into 8.0 or not.
>>> >>>>>>>>>>
>>> >>>>>>>>>> Kevin Risden
>>> >>>>>>>>>>
>>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>> >>>>>>>>>>>
>>> >>>>>>>>>>>
>>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> No new features may be committed to the branch.
>>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Thanks,
>>> >>>>>>>>>>>> Jim
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>>
>>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> sure, thanks Jim!
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>
>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>>> >>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Regards,
>>> >>>>>>>>>>>>>>> Tommaso
>>> >>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> Hi Noble,
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>>> >>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>> >>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>> >>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> --
>>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>> >>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>> >>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>> >>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>> >>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8204>)
>>> >>>>>>>>>>>>>>>>>>>>>>>
>>> --
>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> 
> 
> -- 
> Sincerely yours
> Mikhail Khludnev

Re: Lucene/Solr 8.0

[Mikhail Khludnev <mk...@apache.org>]

Does https://issues.apache.org/jira/browse/SOLR-13126 fit for 8_0 ?

On Thu, Feb 14, 2019 at 11:00 AM Alan Woodward <ro...@gmail.com> wrote:

> I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.
>
> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
>
> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to
> Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all
> since there’s a lot of editing yet to be done for it.
>
> Cassandra
> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>,
> wrote:
>
> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
> only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
> even if it's committed after the 8.0 for the code?  I could avoid touching
> CHANGES.txt if that helps (it'd be of dubious value to users browsing the
> change list any way).
>
> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com>
> wrote:
>
>> Thanks for letting me know Jason.  Your commit will have missed the cut,
>> yes, but I don’t think it matters that much.  It will get picked up in a
>> respin or in any subsequent bug-fix release, and if RC1 passes the vote
>> then we can just alter CHANGES.txt
>>
>>
>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com>
>> wrote:
>> >
>> > Hey Alan,
>> >
>> > I just committed a minor inconsequential bugfix
>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>> > realize I was cutting it so close to your work on cutting RC1, but
>> > from commits I see you made this morning preparing for the RC I
>> > suspect I cut things _very_ close and just missed it.
>> >
>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>> > problems for you on the release end.  I'm happy to do whatever's
>> > easiest for you regarding that commit.  It'd be nice to have it
>> > included in 8.0, but it's not imperative by any means if I've already
>> > missed the first RC, or it's easier for you to omit from potential
>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>> > go back and update CHANGES.txt I think.
>> >
>> > Sorry again for the potential complication.  I hate to be "that guy".
>> > Thanks for stepping up and handling the release.
>> >
>> > Best,
>> >
>> > Jason
>> >
>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
>> wrote:
>> >>
>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
>> many times in the past so I just mechanically changed the redirect without
>> thinking of when or if the ref guide was also released.
>> >> I'll be more careful next time ;).
>> >>
>> >> On another note, now that 7.7 is out and that we're preparing the
>> release for 8.0 what do you think of removing/nuking the 7x branch. This
>> was already discussed some time ago
>> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
>> reached a consensus and we have maybe new options with the move to gitbox.
>> One option discussed in the thread was to remove all files and add a README
>> that says that this branch is dead. I don't know if it's possible but we
>> could also make the branch protected in gitbox in order to avoid new
>> commits. What do you think ? Should we keep this branch and just consider
>> new commits as useless or should we try to "clean up" all Nx branches that
>> are not active anymore (5x, 6x, 7x) ?
>> >>
>> >> Jim
>> >>
>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <
>> casstargett@gmail.com> a écrit :
>> >>>
>> >>> I’d like to remind RMs that when finishing up a release, we can’t
>> just do a blanket find/replace in .htaccess to update the version. If we’re
>> not going to coordinate binary releases with Ref Guide releases, we need to
>> be careful not to change the redirects unless that version’s Ref Guide
>> release is also imminent.
>> >>>
>> >>> This is noted in the ReleaseToDo (
>> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
>> but I’ve seen it occur a little too soon for the past few releases…in those
>> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>> >>>
>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
>> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
>> needs to maybe take care of it), but all non-version specific Ref Guide
>> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
>> we have an easy way to avoid routing people to dead links.
>> >>>
>> >>> Cassandra
>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
>> wrote:
>> >>>
>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
>> volunteer to be the manager for this round.  My current plan is to build a
>> release candidate early next week, as soon as the 7.7 release has been
>> announced.
>> >>>
>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>> >>>
>> >>> It is a shame, I agree, but some of this stuff has been deprecated
>> since 3.6, so another release cycle won’t hurt :). We should prioritise
>> cleaning this stuff up once 8.0 is out of the door though.
>> >>>
>> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
>> wrote:
>> >>>
>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
>> cycle to remove things that have been deprecated in previous releases?
>> solr.LatLonType is one example.  It's a shame to keep around such things
>> further.
>> >>>
>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >>>>
>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may
>> need to back port some extra deprecations to 8x.  We don’t necessarily need
>> them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
>> problems.  I opened the issues to ensure that we didn’t keep carrying
>> deprecated code through any further releases.
>> >>>>
>> >>>>
>> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
>> wrote:
>> >>>>
>> >>>> I want to ensure people are aware of two issues "Remove deprecated
>> code in master" that Alan filed:
>> >>>>
>> >>>> https://issues.apache.org/jira/browse/SOLR-13138
>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
>> >>>> There's a "master-deprecations" branch as well.
>> >>>>
>> >>>> Although both issues are marked "master (9.0)", I think the intent
>> is actually 8.0 so that we are finally rid of the deprecated code?
>> >>>>
>> >>>> ~ David
>> >>>>
>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
>> wrote:
>> >>>>>
>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> >>>>> I'm keeping any eye on the builds this weekend but all indications
>> are
>> >>>>> no issues so far.
>> >>>>>
>> >>>>> Kevin Risden
>> >>>>>
>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
>> wrote:
>> >>>>>>
>> >>>>>> Nick, this change seems to be causing test failures. Can you have
>> a look?
>> >>>>>>
>> >>>>>> See eg.
>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >>>>>>
>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>> wrote:
>> >>>>>>>
>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>> >>>>>>>
>> >>>>>>> - Nick
>> >>>>>>>
>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
>> jim.ferenczi@gmail.com> wrote:
>> >>>>>>>>
>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll
>> start the first RC when your patch is merged.
>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a
>> good idea to rush this in for 8.0. Would it be safer to target another
>> version in order to take some time to ensure that it's not breaking
>> anything ? I guess that your concern is that a change like this should
>> happen in a major version but I wonder if it's worth the risk. I don't know
>> this part of the code and the implications of such a change so I let you
>> decide what we should do here but let's not delay the release if we realize
>> that this change requires more than a few days to be merged.
>> >>>>>>>>
>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com>
>> a écrit :
>> >>>>>>>>>
>> >>>>>>>>> Hey Jim,
>> >>>>>>>>>
>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>> along with a pretty straightforward patch. This is a critical one that I
>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>> >>>>> Kevin Risden <kr...@apache.org> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Jim,
>> >>>>>>>>>>
>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time
>> to get
>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and
>> it is
>> >>>>>>>>>> currently under review.
>> >>>>>>>>>>
>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious
>> if others
>> >>>>>>>>>> feel this should make it into 8.0 or not.
>> >>>>>>>>>>
>> >>>>>>>>>> Kevin Risden
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>> jim.ferenczi@gmail.com> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x
>> because we don't handle two concurrent releases in our tests (
>> https://issues.apache.org/jira/browse/LUCENE-8665).
>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job
>> for this version only and will build the first candidate for this version
>> later this week if there are no objection.
>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>> jim.ferenczi@gmail.com> a écrit :
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hi,
>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7.
>> I'll now create the Jenkins tasks for these versions, Uwe can you also add
>> them to the Policeman's Jenkins job ?
>> >>>>>>>>>>>> This also means that the feature freeze phase has started
>> for both versions (7.7 and 8.0):
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> No new features may be committed to the branch.
>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes
>> may be committed to the branch. However, you should submit all patches you
>> want to commit to Jira first to give others the chance to review and
>> possibly vote against the patch. Keep in mind that it is our main intention
>> to keep the branch as stable as possible.
>> >>>>>>>>>>>> All patches that are intended for the branch should first be
>> committed to the unstable branch, merged into the stable branch, and then
>> into the current release branch.
>> >>>>>>>>>>>> Normal unstable and stable branch development may continue
>> as usual. However, if you plan to commit a big change to the unstable
>> branch while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch may
>> become more difficult.
>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
>> "Blocker" will delay a release candidate build.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>> Jim
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> sure, thanks Jim!
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Tommaso
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow
>> or wednesday and to announce the feature freeze the same day.
>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another
>> week to work on a patch and we can update the status at the end of the week
>> in order to decide if we can start the first build candidate
>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I'd like to backport
>> https://issues.apache.org/jira/browse/LUCENE-8659
>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
>> time.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Regards,
>> >>>>>>>>>>>>>>> Tommaso
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Hi Noble,
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>> noble.paul@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>> david.w.smiley@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week --
>> SOLR-13129
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>> jan.asf@cominvent.com> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker
>> for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold
>> bug.
>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature
>> in the UI and replace it with an error message popup or something.
>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long
>> as there is a reasonable time horizon for the issue being resolved I'm +1
>> on making it a blocker. I'm not familiar enough with the UI code to help
>> either unfortunately.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once
>> before... And it's actually
>> <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g>
>> a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it rather than browsing away or closing the
>> window, not knowing that it's silently pumping out requests after showing
>> an error... would completely hose a node, and until they tracked down the
>> source of the requests, (hope he didn't go home) it would be impossible to
>> resolve...
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>> jpountz@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
>> own, I'd rather not
>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it
>> since this isn't a new
>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has
>> affected Solr
>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
>> code at all, but
>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before
>> we build a RC?
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess
>> as possible on the FOSDEM conference!
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> -----
>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on
>> the week of February 4th.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>> jim.ferenczi@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on
>> releasing 8.0. The branch is
>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
>> anytime now. Unless there are
>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze
>> next week in order to build the
>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we
>> can handle both with Alan so
>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start
>> the release process or if there
>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>> romseygeek@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
>> deprecations on the new master
>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going
>> to need some assistance for
>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what
>> to do.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one
>> for lucene and one for Solr,
>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be
>> removed in each one.  I’ll create
>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and
>> push the changes I’ve already
>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA
>> issues for any changes that
>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
>> particularly for the Solr deprecations
>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
>> romseygeek@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7
>> release at the same time as 8.0, to
>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
>> let’s keep those jobs enabled
>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
>> Jenkins once I have some time
>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x?
>> Should we stop using it
>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
>> branch_7_6 only for bugfixes), or
>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In
>> the latter case I would keep
>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
>> just created a branch for 8x
>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating
>> the master branch to version
>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the
>> 8.0 release should also be
>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I
>> know there are still some
>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
>> should let us clean up master by
>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible,
>> and give us an idea of any
>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
>> david.w.smiley@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
>> sg.online.email@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon
>> as there is an enhancement
>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
>> hands on.
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>>  project in (SOLR, LUCENE) AND
>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
>> fixVersion = "master (8.0)"
>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on
>> those issues not yet
>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>> jpountz@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks
>> Nick!) we should think about
>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to
>> 9.0.  I’ll volunteer to create the
>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we
>> should have some time to
>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything
>> that still needs to be done
>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next
>> year.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <
>> casstargett@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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
>> <ji...@gmail.com>
>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>> Knize
>> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36,
>> jim ferenczi
>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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)
>> >>>>>>>>>>>>>>>>>>>>>>>
>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>

-- 
Sincerely yours
Mikhail Khludnev

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

I have no problem with bug-fixes and ref-guide changes on the 8_0 branch.

> On 13 Feb 2019, at 22:25, Cassandra Targett <ca...@gmail.com> wrote:
> 
> I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.
> 
> Cassandra
> On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
>> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 <https://issues.apache.org/jira/browse/SOLR-13129> which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>> 
>> On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
>> 
>> 
>> > On 13 Feb 2019, at 16:27, Jason Gerlowski <gerlowskija@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > Hey Alan,
>> >
>> > I just committed a minor inconsequential bugfix
>> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
>> > realize I was cutting it so close to your work on cutting RC1, but
>> > from commits I see you made this morning preparing for the RC I
>> > suspect I cut things _very_ close and just missed it.
>> >
>> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
>> > problems for you on the release end.  I'm happy to do whatever's
>> > easiest for you regarding that commit.  It'd be nice to have it
>> > included in 8.0, but it's not imperative by any means if I've already
>> > missed the first RC, or it's easier for you to omit from potential
>> > subsequent RCs.  Let me know if there's anything you'd like me to do
>> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
>> > go back and update CHANGES.txt I think.
>> >
>> > Sorry again for the potential complication.  I hate to be "that guy".
>> > Thanks for stepping up and handling the release.
>> >
>> > Best,
>> >
>> > Jason
>> >
>> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> >>
>> >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>> >> I'll be more careful next time ;).
>> >>
>> >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh <https://markmail.org/message/xl7vypkylhmeefhh> but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>> >>
>> >> Jim
>> >>
>> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> a écrit :
>> >>>
>> >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>> >>>
>> >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc <https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc>), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>> >>>
>> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>> >>>
>> >>> Cassandra
>> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>, wrote:
>> >>>
>> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>> >>>
>> >>> On 8 Feb 2019, at 09:07, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> >>>
>> >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>> >>>
>> >>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> >>>
>> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>> >>>
>> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> >>>>
>> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>> >>>>
>> >>>>
>> >>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> >>>>
>> >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>> >>>>
>> >>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>> >>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>> >>>> There's a "master-deprecations" branch as well.
>> >>>>
>> >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>> >>>>
>> >>>> ~ David
>> >>>>
>> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>> >>>>>
>> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> >>>>> I'm keeping any eye on the builds this weekend but all indications are
>> >>>>> no issues so far.
>> >>>>>
>> >>>>> Kevin Risden
>> >>>>>
>> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>
>> >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>> >>>>>>
>> >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>> >>>>>>
>> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>
>> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>> >>>>>>>
>> >>>>>>> - Nick
>> >>>>>>>
>> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>
>> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>> >>>>>>>>
>> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>
>> >>>>>>>>> Hey Jim,
>> >>>>>>>>>
>> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> >>>>>>>>>
>> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>> >>>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>> >>>>>>>>>>
>> >>>>>>>>>> Jim,
>> >>>>>>>>>>
>> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> >>>>>>>>>> currently under review.
>> >>>>>>>>>>
>> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> >>>>>>>>>> feel this should make it into 8.0 or not.
>> >>>>>>>>>>
>> >>>>>>>>>> Kevin Risden
>> >>>>>>>>>>
>> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>
>> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Hi,
>> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>> >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> No new features may be committed to the branch.
>> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>> >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>> >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Thanks,
>> >>>>>>>>>>>> Jim
>> >>>>>>>>>>>>
>> >>>>>>>>>>>>
>> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> sure, thanks Jim!
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Tommaso
>> >>>>>>>>>>>>>
>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> >>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>> >>>>>>>>>>>>>> early next week. Would that work for you ?
>> >>>>>>>>>>>>>>
>> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Regards,
>> >>>>>>>>>>>>>>> Tommaso
>> >>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> >>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> Hi Noble,
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> No it hasn't created yet.
>> >>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>> >>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>> >>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> --
>> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>> >>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually <https://maps.google.com/?q=e+before...+And+it%27s+actually&entry=gmail&source=g> a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>> >>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>> >>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Cool,
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> Uwe
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>> -----
>> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>> >>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> >>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> >>>>>>>>>>>>>>>>>>>>>>>> for now.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>> >>>>>>>>>>>>>>>>>>>>>>>> later today.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de <http://www.thetaphi.de/>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>> >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
>> >>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >>>>>>>>>>>>>>>>>>>>>>>> <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>> >>>>>>>>>>>>>>>>>>>>>>>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >>>>>>>>>>>>>>>>>>>>>>>> <nknize@gmail.com <ma...@gmail.com>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <casstargett@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> I find 9 open blockers for 8.0:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> We still have two blockers for the Lucene 8 release:
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>> >>>>>>>>>>>>>>>>>>>>>>>> 7075?jql=(project%3D%22Lucene%20-
>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>> >>>>>>>>>>>>>>>>>>>>>>>> r%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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>> >>>>>>>>>>>>>>>>>>>>>>>> 12720?jql=(project%3D%22Lucene%20-
>> >>>>>>>>>>>>>>>>>>>>>>>> %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> >>>>>>>>>>>>>>>>>>>>>>>> <jim.ferenczi@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <erickerickson@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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
>> >>>>>>>>>>>>>>>>>>>>>>>> <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>> >>>>>>>>>>>>>>>>>>>>>>>> <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8204>)
>> >>>>>>>>>>>>>>>>>>>>>>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

I’ll let Alan reply definitively, but IMO if branch_8_0 is closed even to Ref Guide-only commits, we’re not going to have an 8.0 Ref Guide at all since there’s a lot of editing yet to be done for it.

Cassandra
On Feb 13, 2019, 4:20 PM -0600, David Smiley <da...@gmail.com>, wrote:
> I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this even if it's committed after the 8.0 for the code?  I could avoid touching CHANGES.txt if that helps (it'd be of dubious value to users browsing the change list any way).
>
> > On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:
> > > Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt
> > >
> > >
> > > > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> > > >
> > > > Hey Alan,
> > > >
> > > > I just committed a minor inconsequential bugfix
> > > > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > > > realize I was cutting it so close to your work on cutting RC1, but
> > > > from commits I see you made this morning preparing for the RC I
> > > > suspect I cut things _very_ close and just missed it.
> > > >
> > > > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > > > problems for you on the release end.  I'm happy to do whatever's
> > > > easiest for you regarding that commit.  It'd be nice to have it
> > > > included in 8.0, but it's not imperative by any means if I've already
> > > > missed the first RC, or it's easier for you to omit from potential
> > > > subsequent RCs.  Let me know if there's anything you'd like me to do
> > > > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > > > go back and update CHANGES.txt I think.
> > > >
> > > > Sorry again for the potential complication.  I hate to be "that guy".
> > > > Thanks for stepping up and handling the release.
> > > >
> > > > Best,
> > > >
> > > > Jason
> > > >
> > > > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
> > > >>
> > > >> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> > > >> I'll be more careful next time ;).
> > > >>
> > > >> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
> > > >>
> > > >> Jim
> > > >>
> > > >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
> > > >>>
> > > >>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
> > > >>>
> > > >>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
> > > >>>
> > > >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
> > > >>>
> > > >>> Cassandra
> > > >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> > > >>>
> > > >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
> > > >>>
> > > >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> > > >>>
> > > >>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> > > >>>
> > > >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> > > >>>
> > > >>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> > > >>>
> > > >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> > > >>>>
> > > >>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> > > >>>>
> > > >>>>
> > > >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> > > >>>>
> > > >>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> > > >>>>
> > > >>>> https://issues.apache.org/jira/browse/SOLR-13138
> > > >>>> https://issues.apache.org/jira/browse/LUCENE-8638
> > > >>>> There's a "master-deprecations" branch as well.
> > > >>>>
> > > >>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> > > >>>>
> > > >>>> ~ David
> > > >>>>
> > > >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> > > >>>>>
> > > >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > > >>>>> I'm keeping any eye on the builds this weekend but all indications are
> > > >>>>> no issues so far.
> > > >>>>>
> > > >>>>> Kevin Risden
> > > >>>>>
> > > >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> > > >>>>>>
> > > >>>>>> Nick, this change seems to be causing test failures. Can you have a look?
> > > >>>>>>
> > > >>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > > >>>>>>
> > > >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > > >>>>>>>
> > > >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
> > > >>>>>>>
> > > >>>>>>> - Nick
> > > >>>>>>>
> > > >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> > > >>>>>>>>
> > > >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > > >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > > >>>>>>>>
> > > >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> > > >>>>>>>>>
> > > >>>>>>>>> Hey Jim,
> > > >>>>>>>>>
> > > >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
> > > >>>>> Kevin Risden <kr...@apache.org> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>> Jim,
> > > >>>>>>>>>>
> > > >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
> > > >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > > >>>>>>>>>> currently under review.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > > >>>>>>>>>> feel this should make it into 8.0 or not.
> > > >>>>>>>>>>
> > > >>>>>>>>>> Kevin Risden
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> > > >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > > >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > > >>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> No new features may be committed to the branch.
> > > >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > > >>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > > >>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > > >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Thanks,
> > > >>>>>>>>>>>> Jim
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> sure, thanks Jim!
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Tommaso
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > > >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
> > > >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > > >>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > > >>>>>>>>>>>>>> early next week. Would that work for you ?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > > >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Regards,
> > > >>>>>>>>>>>>>>> Tommaso
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > > >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Hi Noble,
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> No it hasn't created yet.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > > >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > > >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
> > > >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
> > > >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
> > > >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
> > > >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
> > > >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Cool,
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> Uwe
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> -----
> > > >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
> > > >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
> > > >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
> > > >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> > > >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
> > > >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
> > > >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > > >>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > > >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
> > > >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
> > > >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
> > > >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
> > > >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
> > > >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
> > > >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
> > > >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > > >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
> > > >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
> > > >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
> > > >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
> > > >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > > >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > > >>>>>>>>>>>>>>>>>>>>>>>> for now.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
> > > >>>>>>>>>>>>>>>>>>>>>>>> later today.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
> > > >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > > >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > > >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> -----
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > > >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
> > > >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
> > > >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
> > > >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
> > > >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
> > > >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> January.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
> > > >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> SG
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > > >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > >>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > >>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
> > > >>>>>>>>>>>>>>>>>>>>>>>> assigned.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> +1
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
> > > >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > > >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
> > > >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
> > > >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
> > > >>>>>>>>>>>>>>>>>>>>>>>> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
> > > >>>>>>>>>>>>>>>>>>>>>>>> r%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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
> > > >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
> > > >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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)
> > > >>>>>>>>>>>>>>>>>>>>>>>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

I've been shepherding https://issues.apache.org/jira/browse/SOLR-13129 which
only touches the Solr Ref Guide.  Could the Ref Guide for 8.0 include this
even if it's committed after the 8.0 for the code?  I could avoid touching
CHANGES.txt if that helps (it'd be of dubious value to users browsing the
change list any way).

On Wed, Feb 13, 2019 at 11:43 AM Alan Woodward <ro...@gmail.com> wrote:

> Thanks for letting me know Jason.  Your commit will have missed the cut,
> yes, but I don’t think it matters that much.  It will get picked up in a
> respin or in any subsequent bug-fix release, and if RC1 passes the vote
> then we can just alter CHANGES.txt
>
>
> > On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> >
> > Hey Alan,
> >
> > I just committed a minor inconsequential bugfix
> > (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> > realize I was cutting it so close to your work on cutting RC1, but
> > from commits I see you made this morning preparing for the RC I
> > suspect I cut things _very_ close and just missed it.
> >
> > Hopefully my ill-timed commit to branch_8_0 doesn't create any
> > problems for you on the release end.  I'm happy to do whatever's
> > easiest for you regarding that commit.  It'd be nice to have it
> > included in 8.0, but it's not imperative by any means if I've already
> > missed the first RC, or it's easier for you to omit from potential
> > subsequent RCs.  Let me know if there's anything you'd like me to do
> > (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> > go back and update CHANGES.txt I think.
> >
> > Sorry again for the potential complication.  I hate to be "that guy".
> > Thanks for stepping up and handling the release.
> >
> > Best,
> >
> > Jason
> >
> > On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >>
> >> Thanks for fixing Cassandra and sorry for the noise. I did this too
> many times in the past so I just mechanically changed the redirect without
> thinking of when or if the ref guide was also released.
> >> I'll be more careful next time ;).
> >>
> >> On another note, now that 7.7 is out and that we're preparing the
> release for 8.0 what do you think of removing/nuking the 7x branch. This
> was already discussed some time ago
> https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
> reached a consensus and we have maybe new options with the move to gitbox.
> One option discussed in the thread was to remove all files and add a README
> that says that this branch is dead. I don't know if it's possible but we
> could also make the branch protected in gitbox in order to avoid new
> commits. What do you think ? Should we keep this branch and just consider
> new commits as useless or should we try to "clean up" all Nx branches that
> are not active anymore (5x, 6x, 7x) ?
> >>
> >> Jim
> >>
> >> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com>
> a écrit :
> >>>
> >>> I’d like to remind RMs that when finishing up a release, we can’t just
> do a blanket find/replace in .htaccess to update the version. If we’re not
> going to coordinate binary releases with Ref Guide releases, we need to be
> careful not to change the redirects unless that version’s Ref Guide release
> is also imminent.
> >>>
> >>> This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
> >>>
> >>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
> needs to maybe take care of it), but all non-version specific Ref Guide
> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
> we have an easy way to avoid routing people to dead links.
> >>>
> >>> Cassandra
> >>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
> >>>
> >>> Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
> >>>
> >>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> >>>
> >>> It is a shame, I agree, but some of this stuff has been deprecated
> since 3.6, so another release cycle won’t hurt :). We should prioritise
> cleaning this stuff up once 8.0 is out of the door though.
> >>>
> >>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com>
> wrote:
> >>>
> >>> Okay.  I suppose the issue is that it's simply too late in the 8.0
> cycle to remove things that have been deprecated in previous releases?
> solr.LatLonType is one example.  It's a shame to keep around such things
> further.
> >>>
> >>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >>>>
> >>>> Not quite - the plan is to remove things entirely in 9.0, but we may
> need to back port some extra deprecations to 8x.  We don’t necessarily need
> them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
> >>>>
> >>>>
> >>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com>
> wrote:
> >>>>
> >>>> I want to ensure people are aware of two issues "Remove deprecated
> code in master" that Alan filed:
> >>>>
> >>>> https://issues.apache.org/jira/browse/SOLR-13138
> >>>> https://issues.apache.org/jira/browse/LUCENE-8638
> >>>> There's a "master-deprecations" branch as well.
> >>>>
> >>>> Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
> >>>>
> >>>> ~ David
> >>>>
> >>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org>
> wrote:
> >>>>>
> >>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> >>>>> I'm keeping any eye on the builds this weekend but all indications
> are
> >>>>> no issues so far.
> >>>>>
> >>>>> Kevin Risden
> >>>>>
> >>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com>
> wrote:
> >>>>>>
> >>>>>> Nick, this change seems to be causing test failures. Can you have a
> look?
> >>>>>>
> >>>>>> See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> >>>>>>
> >>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
> wrote:
> >>>>>>>
> >>>>>>> Thank you Jim. LUCENE-8669 has been merged.
> >>>>>>>
> >>>>>>> - Nick
> >>>>>>>
> >>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> >>>>>>>>
> >>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start
> the first RC when your patch is merged.
> >>>>>>>> Kevin, this looks like a big change so I am not sure if it's a
> good idea to rush this in for 8.0. Would it be safer to target another
> version in order to take some time to ensure that it's not breaking
> anything ? I guess that your concern is that a change like this should
> happen in a major version but I wonder if it's worth the risk. I don't know
> this part of the code and the implications of such a change so I let you
> decide what we should do here but let's not delay the release if we realize
> that this change requires more than a few days to be merged.
> >>>>>>>>
> >>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com>
> a écrit :
> >>>>>>>>>
> >>>>>>>>> Hey Jim,
> >>>>>>>>>
> >>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
> along with a pretty straightforward patch. This is a critical one that I
> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> >>>>>>>>>
> >>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
> >>>>> Kevin Risden <kr...@apache.org> wrote:
> >>>>>>>>>>
> >>>>>>>>>> Jim,
> >>>>>>>>>>
> >>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time
> to get
> >>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and
> it is
> >>>>>>>>>> currently under review.
> >>>>>>>>>>
> >>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
> others
> >>>>>>>>>> feel this should make it into 8.0 or not.
> >>>>>>>>>>
> >>>>>>>>>> Kevin Risden
> >>>>>>>>>>
> >>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x
> because we don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> >>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job
> for this version only and will build the first candidate for this version
> later this week if there are no objection.
> >>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
> jim.ferenczi@gmail.com> a écrit :
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hi,
> >>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7.
> I'll now create the Jenkins tasks for these versions, Uwe can you also add
> them to the Policeman's Jenkins job ?
> >>>>>>>>>>>> This also means that the feature freeze phase has started for
> both versions (7.7 and 8.0):
> >>>>>>>>>>>>
> >>>>>>>>>>>> No new features may be committed to the branch.
> >>>>>>>>>>>> Documentation patches, build patches and serious bug fixes
> may be committed to the branch. However, you should submit all patches you
> want to commit to Jira first to give others the chance to review and
> possibly vote against the patch. Keep in mind that it is our main intention
> to keep the branch as stable as possible.
> >>>>>>>>>>>> All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> >>>>>>>>>>>> Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> >>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority
> "Blocker" will delay a release candidate build.
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Thanks,
> >>>>>>>>>>>> Jim
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> sure, thanks Jim!
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Tommaso
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> >>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
> >>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow
> or wednesday and to announce the feature freeze the same day.
> >>>>>>>>>>>>>> For blocker issues that are still open this leaves another
> week to work on a patch and we can update the status at the end of the week
> in order to decide if we can start the first build candidate
> >>>>>>>>>>>>>> early next week. Would that work for you ?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> >>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
> time.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Regards,
> >>>>>>>>>>>>>>> Tommaso
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> >>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Hi Noble,
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> No it hasn't created yet.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
> noble.paul@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> >>>>>>>>>>>>>>>>>> I will work on some documentation for it this week --
> SOLR-13129
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
> jan.asf@cominvent.com> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker
> for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold
> bug.
> >>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature
> in the UI and replace it with an error message popup or something.
> >>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> --
> >>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
> >>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long
> as there is a reasonable time horizon for the issue being resolved I'm +1
> on making it a blocker. I'm not familiar enough with the UI code to help
> either unfortunately.
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
> gus.heck@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once
> before... And it's actually
> <https://maps.google.com/?q=e+before...+And+it's+actually&entry=gmail&source=g>
> a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
> jpountz@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its
> own, I'd rather not
> >>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since
> this isn't a new
> >>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has
> affected Solr
> >>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI
> code at all, but
> >>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before
> we build a RC?
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
> gus.heck@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Cool,
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess
> as possible on the FOSDEM conference!
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> Uwe
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
> >>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
> >>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
> >>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
> >>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
> >>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
> >>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on
> the week of February 4th.
> >>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on
> releasing 8.0. The branch is
> >>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process
> anytime now. Unless there are
> >>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze
> next week in order to build the
> >>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
> >>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can
> handle both with Alan so
> >>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start
> the release process or if there
> >>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
> romseygeek@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> a écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various
> deprecations on the new master
> >>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going
> to need some assistance for
> >>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what
> to do.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one
> for lucene and one for Solr,
> >>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be
> removed in each one.  I’ll create
> >>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and
> push the changes I’ve already
> >>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA
> issues for any changes that
> >>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received,
> particularly for the Solr deprecations
> >>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <
> romseygeek@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release
> at the same time as 8.0, to
> >>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So
> let’s keep those jobs enabled
> >>>>>>>>>>>>>>>>>>>>>>>> for now.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to
> Jenkins once I have some time
> >>>>>>>>>>>>>>>>>>>>>>>> later today.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x?
> Should we stop using it
> >>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use
> branch_7_6 only for bugfixes), or
> >>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In
> the latter case I would keep
> >>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> -----
> >>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
> >>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
> >>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
> >>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
> >>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
> >>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve
> just created a branch for 8x
> >>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating
> the master branch to version
> >>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the
> 8.0 release should also be
> >>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I
> know there are still some
> >>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it
> should let us clean up master by
> >>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and
> give us an idea of any
> >>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> January.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <
> sg.online.email@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon
> as there is an enhancement
> >>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our
> hands on.
> >>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thx
> >>>>>>>>>>>>>>>>>>>>>>>>>> SG
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:
>  project in (SOLR, LUCENE) AND
> >>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and
> fixVersion = "master (8.0)"
> >>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >>>>>>>>>>>>>>>>>>>>>>>>
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >>>>>>>>>>>>>>>>>>>>>>>>
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on
> those issues not yet
> >>>>>>>>>>>>>>>>>>>>>>>> assigned.
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
> jpountz@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> +1
> >>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!)
> we should think about
> >>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.
> I’ll volunteer to create the
> >>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should
> have some time to
> >>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything
> that still needs to be done
> >>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next
> year.
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> >>>>>>>>>>>>>>>>>>>>>>>> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
> Knize
> >>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
> >>>>>>>>>>>>>>>>>>>>>>>> r%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
> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
> >>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36,
> jim ferenczi
> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <er...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <da...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
> >>>>>>>>>>>>>>>>>>>>>>>> <jp...@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)
> >>>>>>>>>>>>>>>>>>>>>>>

-- 
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Thanks for letting me know Jason.  Your commit will have missed the cut, yes, but I don’t think it matters that much.  It will get picked up in a respin or in any subsequent bug-fix release, and if RC1 passes the vote then we can just alter CHANGES.txt


> On 13 Feb 2019, at 16:27, Jason Gerlowski <ge...@gmail.com> wrote:
> 
> Hey Alan,
> 
> I just committed a minor inconsequential bugfix
> (1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
> realize I was cutting it so close to your work on cutting RC1, but
> from commits I see you made this morning preparing for the RC I
> suspect I cut things _very_ close and just missed it.
> 
> Hopefully my ill-timed commit to branch_8_0 doesn't create any
> problems for you on the release end.  I'm happy to do whatever's
> easiest for you regarding that commit.  It'd be nice to have it
> included in 8.0, but it's not imperative by any means if I've already
> missed the first RC, or it's easier for you to omit from potential
> subsequent RCs.  Let me know if there's anything you'd like me to do
> (revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
> go back and update CHANGES.txt I think.
> 
> Sorry again for the potential complication.  I hate to be "that guy".
> Thanks for stepping up and handling the release.
> 
> Best,
> 
> Jason
> 
> On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>> 
>> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
>> I'll be more careful next time ;).
>> 
>> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>> 
>> Jim
>> 
>> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>>> 
>>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>> 
>>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>> 
>>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>> 
>>> Cassandra
>>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>>> 
>>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>> 
>>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>> 
>>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>> 
>>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>>> 
>>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>> 
>>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>>>> 
>>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>> 
>>>> 
>>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>>> 
>>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>> 
>>>> https://issues.apache.org/jira/browse/SOLR-13138
>>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>>> There's a "master-deprecations" branch as well.
>>>> 
>>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>> 
>>>> ~ David
>>>> 
>>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>>> 
>>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>>> no issues so far.
>>>>> 
>>>>> Kevin Risden
>>>>> 
>>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>>>> 
>>>>>> Nick, this change seems to be causing test failures. Can you have a look?
>>>>>> 
>>>>>> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>>>> 
>>>>>> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Thank you Jim. LUCENE-8669 has been merged.
>>>>>>> 
>>>>>>> - Nick
>>>>>>> 
>>>>>>> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>> 
>>>>>>>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>>>>>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>>>>>> 
>>>>>>>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>>>>>>> 
>>>>>>>>> Hey Jim,
>>>>>>>>> 
>>>>>>>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>>>>>>> 
>>>>>>>>> On Wed, Jan 30, 2019 at 1:07 PM
>>>>> Kevin Risden <kr...@apache.org> wrote:
>>>>>>>>>> 
>>>>>>>>>> Jim,
>>>>>>>>>> 
>>>>>>>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>>>>>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>>>>>>>> currently under review.
>>>>>>>>>> 
>>>>>>>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>>>>>>>> feel this should make it into 8.0 or not.
>>>>>>>>>> 
>>>>>>>>>> Kevin Risden
>>>>>>>>>> 
>>>>>>>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>>>>>>>>> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>>>>>>>>> I'll restore the version bump for 8.0 when 7.7 is out.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>>>>>>>>>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>>>>>>>>>> 
>>>>>>>>>>>> No new features may be committed to the branch.
>>>>>>>>>>>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>>>>>>>>>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>>>>>>>>>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>>>>>>>>>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Thanks,
>>>>>>>>>>>> Jim
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>>>>>>> 
>>>>>>>>>>>>> sure, thanks Jim!
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Tommaso
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>>>>>>>> <ji...@gmail.com> ha scritto:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Go ahead Tommaso the branch is not created yet.
>>>>>>>>>>>>>> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>>>>>>>>>>>> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>>>>>>>>>>>> early next week. Would that work for you ?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>>>>>>>>>>>>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Tommaso
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>>>>>>>>>>>>> <jp...@gmail.com> ha scritto:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Noble,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>>>>>>>>>>>>>>>> I will work on some documentation for it this week -- SOLR-13129
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>>>>>>>>>>>>>>>>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>>>>>>>>>>>>>>>>> I'll try to take a look next week.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>> Jan Høydahl, search solution architect
>>>>>>>>>>>>>>>>>>> Cominvent AS - www.cominvent.com
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>>>>>>>>>>>>>>>>>>> call it a blocker and delay the release for it since this isn't a new
>>>>>>>>>>>>>>>>>>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>>>>>>>>>>>>>>>>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>>>>>>>>>>>>>>>>>>> maybe this is something that could get fixed before we build a RC?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Cool,
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> -----Original Message-----
>>>>>>>>>>>>>>>>>>>>>>>> From: Adrien Grand <jp...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> Sent: Thursday, January 24, 2019 5:33 PM
>>>>>>>>>>>>>>>>>>>>>>>> To: Lucene Dev <de...@lucene.apache.org>
>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>> As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>>>>>>>>>>>>>>>>>>>>>> already created so we can start the process anytime now. Unless there are
>>>>>>>>>>>>>>>>>>>>>>>> objections I'd like to start the feature freeze next week in order to build the
>>>>>>>>>>>>>>>>>>>>>>>> first candidate the week after.
>>>>>>>>>>>>>>>>>>>>>>>>> We'll also need a 7.7 release but I think we can handle both with Alan so
>>>>>>>>>>>>>>>>>>>>>>>> the question now is whether we are ok to start the release process or if there
>>>>>>>>>>>>>>>>>>>>>>>> are any blockers left ;).
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> a écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I’ve started to work through the various deprecations on the new master
>>>>>>>>>>>>>>>>>>>>>>>> branch.  There are a lot of them, and I’m going to need some assistance for
>>>>>>>>>>>>>>>>>>>>>>>> several of them, as it’s not entirely clear what to do.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>>>>>>>>>>>>>>>>>>>>>> with lists of the deprecations that need to be removed in each one.  I’ll create
>>>>>>>>>>>>>>>>>>>>>>>> a shared branch on gitbox to work against, and push the changes I’ve already
>>>>>>>>>>>>>>>>>>>>>>>> done there.  We can then create individual JIRA issues for any changes that
>>>>>>>>>>>>>>>>>>>>>>>> are more involved than just deleting code.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> All assistance gratefully received, particularly for the Solr deprecations
>>>>>>>>>>>>>>>>>>>>>>>> where there’s a lot of code I’m unfamiliar with.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>>>>>>>>>>>>>>>>>>>>>> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>>>>>>>>>>>>>>>>>>>>>> for now.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>>>>>>>>>>>>>>>>>>>>>> later today.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> The question: How to proceed with branch_7x? Should we stop using it
>>>>>>>>>>>>>>>>>>>>>>>> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>>>>>>>>>>>>>>>>>>>>>> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>>>>>>>>>>>>>>>>>>>>>> the jenkins jobs enabled for a while.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> -----
>>>>>>>>>>>>>>>>>>>>>>>>>> Uwe Schindler
>>>>>>>>>>>>>>>>>>>>>>>>>> Achterdiek 19, D-28357 Bremen
>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>> eMail: uwe@thetaphi.de
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> From: Alan Woodward <ro...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>>>> Sent: Monday, January 7, 2019 11:30 AM
>>>>>>>>>>>>>>>>>>>>>>>>>> To: dev@lucene.apache.org
>>>>>>>>>>>>>>>>>>>>>>>>>> Subject: Re: Lucene/Solr 8.0
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>>>>>>>>>>>>>>>>>>>>>> from master, and am in the process of updating the master branch to version
>>>>>>>>>>>>>>>>>>>>>>>> 9.  New commits that should be included in the 8.0 release should also be
>>>>>>>>>>>>>>>>>>>>>>>> back-ported to branch_8x from master.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> This is not intended as a feature freeze, as I know there are still some
>>>>>>>>>>>>>>>>>>>>>>>> things being worked on for 8.0; however, it should let us clean up master by
>>>>>>>>>>>>>>>>>>>>>>>> removing as much deprecated code as possible, and give us an idea of any
>>>>>>>>>>>>>>>>>>>>>>>> replacement work that needs to be done.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> January.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>>>>>>>>>>>>>>>>>>>>>> on nested-documents we are waiting to get our hands on.
>>>>>>>>>>>>>>>>>>>>>>>>>> Any idea when Solr 8 would be out ?
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Thx
>>>>>>>>>>>>>>>>>>>>>>>>>> SG
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>>>>>>>>>>>>>>>>>>>>>> priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>>>>>>>>>>>>>>>>>>>>>>>>   click here:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>>>>>>>>>>>>>>>>>>>>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>>>>>>>>>>>>>>>>>>>>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> Thru the end of the month, I intend to work on those issues not yet
>>>>>>>>>>>>>>>>>>>>>>>> assigned.
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> +1
>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>>>>>>>>>>>>>>>>>>>>>> <ro...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>>>>>>>>>>>>>>>>>>>>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>>>>>>>>>>>>>>>>>>>>>> branch this week - say Wednesday?  Then we should have some time to
>>>>>>>>>>>>>>>>>>>>>>>> clean up the master branch and uncover anything that still needs to be done
>>>>>>>>>>>>>>>>>>>>>>>> on 8.0 before we start the release process next year.
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> <er...@gmail.com> 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 <ji...@gmail.com>
>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>> <da...@gmail.com> a écrit :
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> +1 to a 7.6 —lots of stuff in there
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>>>>>>>>>>>>>>>>>>>>>> <nk...@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>> <ca...@gmail.com> 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
>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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%3DBlocke
>>>>>>>>>>>>>>>>>>>>>>>> r%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
>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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%3DBlocke
>>>>>>>>>>>>>>>>>>>>>>>> r%20and%20resolution%20%3D%20Unresolved%20
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>> <er...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ca...@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
>>>>>>>>>>>>>>>>>>>>>>>> <ji...@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
>>>>>>>>>>>>>>>>>>>>>>>> <da...@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
>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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
>>>>>>>>>>>>>>>>>>>>>>>> <jp...@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
>>>>>>>>>>>>>>>>>>>>>>>> <rc...@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 <jp...@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 requ
>>> 
>>> --
>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>>> 
>>> 
>>> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Jason Gerlowski <ge...@gmail.com>]

Hey Alan,

I just committed a minor inconsequential bugfix
(1b6c8fa95ba8c5b0646f599132c8ffd20c697e72) to branch_8_0.  I didn't
realize I was cutting it so close to your work on cutting RC1, but
from commits I see you made this morning preparing for the RC I
suspect I cut things _very_ close and just missed it.

Hopefully my ill-timed commit to branch_8_0 doesn't create any
problems for you on the release end.  I'm happy to do whatever's
easiest for you regarding that commit.  It'd be nice to have it
included in 8.0, but it's not imperative by any means if I've already
missed the first RC, or it's easier for you to omit from potential
subsequent RCs.  Let me know if there's anything you'd like me to do
(revert it, etc.).  At a minimum if it doesn't make 8.0 I'll need to
go back and update CHANGES.txt I think.

Sorry again for the potential complication.  I hate to be "that guy".
Thanks for stepping up and handling the release.

Best,

Jason

On Wed, Feb 13, 2019 at 4:52 AM jim ferenczi <ji...@gmail.com> wrote:
>
> Thanks for fixing Cassandra and sorry for the noise. I did this too many times in the past so I just mechanically changed the redirect without thinking of when or if the ref guide was also released.
> I'll be more careful next time ;).
>
> On another note, now that 7.7 is out and that we're preparing the release for 8.0 what do you think of removing/nuking the 7x branch. This was already discussed some time ago https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we reached a consensus and we have maybe new options with the move to gitbox. One option discussed in the thread was to remove all files and add a README that says that this branch is dead. I don't know if it's possible but we could also make the branch protected in gitbox in order to avoid new commits. What do you think ? Should we keep this branch and just consider new commits as useless or should we try to "clean up" all Nx branches that are not active anymore (5x, 6x, 7x) ?
>
> Jim
>
> Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a écrit :
>>
>> I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.
>>
>> This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.
>>
>> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.
>>
>> Cassandra
>> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
>>
>> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>>
>> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>>
>> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
>>
>> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>>
>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>>
>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>>>
>>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>>>
>>>
>>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>>
>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>>
>>> https://issues.apache.org/jira/browse/SOLR-13138
>>> https://issues.apache.org/jira/browse/LUCENE-8638
>>> There's a "master-deprecations" branch as well.
>>>
>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>>
>>> ~ David
>>>
>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>>>
>>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>>> I'm keeping any eye on the builds this weekend but all indications are
>>>> no issues so far.
>>>>
>>>> Kevin Risden
>>>>
>>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>>> >
>>>> > Nick, this change seems to be causing test failures. Can you have a look?
>>>> >
>>>> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>>> >
>>>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>>>> > >
>>>> > > Thank you Jim. LUCENE-8669 has been merged.
>>>> > >
>>>> > > - Nick
>>>> > >
>>>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>>> > >>
>>>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>>> > >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>>> > >>
>>>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>> > >>>
>>>> > >>> Hey Jim,
>>>> > >>>
>>>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>> > >>>
>>>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>>>> Kevin Risden <kr...@apache.org> wrote:
>>>> > >>>>
>>>> > >>>> Jim,
>>>> > >>>>
>>>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>> > >>>> currently under review.
>>>> > >>>>
>>>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>> > >>>> feel this should make it into 8.0 or not.
>>>> > >>>>
>>>> > >>>> Kevin Risden
>>>> > >>>>
>>>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>> > >>>> >
>>>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>> > >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>>> > >>>> >
>>>> > >>>> >
>>>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>> > >>>> >>
>>>> > >>>> >> Hi,
>>>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>> > >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>> > >>>> >>
>>>> > >>>> >> No new features may be committed to the branch.
>>>> > >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>> > >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>> > >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>> > >>>> >>
>>>> > >>>> >>
>>>> > >>>> >> Thanks,
>>>> > >>>> >> Jim
>>>> > >>>> >>
>>>> > >>>> >>
>>>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> > >>>> >>>
>>>> > >>>> >>> sure, thanks Jim!
>>>> > >>>> >>>
>>>> > >>>> >>> Tommaso
>>>> > >>>> >>>
>>>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>> > >>>> >>> <ji...@gmail.com> ha scritto:
>>>> > >>>> >>> >
>>>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>>>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>> > >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>> > >>>> >>> > early next week. Would that work for you ?
>>>> > >>>> >>> >
>>>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> > >>>> >>> >>
>>>> > >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>> > >>>> >>> >>
>>>> > >>>> >>> >> Regards,
>>>> > >>>> >>> >> Tommaso
>>>> > >>>> >>> >>
>>>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>> > >>>> >>> >> <jp...@gmail.com> ha scritto:
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > Hi Noble,
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > No it hasn't created yet.
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>> > >>>> >>> >> > >
>>>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>>> > >>>> >>> >> > >
>>>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >
>>>> > >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>> > >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>>>> > >>>> >>> >> > > >
>>>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>> > >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>> > >>>> >>> >> > > >> I'll try to take a look next week.
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> --
>>>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>>>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >>>
>>>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>> > >>>> >>> >> > > >>>
>>>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >>>>
>>>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>>>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>>>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>>>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>>>> > >>>> >>> >> > > >>>>
>>>> > >>>> >>> >> > > >>>>
>>>> > >>>> >>> >> > > >>>>
>>>> > >>>> >>> >> > > >>>>
>>>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >>>> >
>>>> > >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>> > >>>> >>> >> > > >>>> >
>>>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> > >>>> >>> >> > > >>>> >>
>>>> > >>>> >>> >> > > >>>> >> Cool,
>>>> > >>>> >>> >> > > >>>> >>
>>>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>> > >>>> >>> >> > > >>>> >>
>>>> > >>>> >>> >> > > >>>> >> Uwe
>>>> > >>>> >>> >> > > >>>> >>
>>>> > >>>> >>> >> > > >>>> >> -----
>>>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>>>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>>> > >>>> >>> >> > > >>>> >>
>>>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>>>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>>> > >>>> >>> >> > > >>>> >> >
>>>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>> > >>>> >>> >> > > >>>> >> >
>>>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >
>>>> > >>>> >>> >> > > >>>> >> > > Hi,
>>>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>> > >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>>>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>>>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>>>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>>>> > >>>> >>> >> > > >>>> >> > >
>>>> > >>>> >>> >> > > >>>> >> > >
>>>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > a écrit :
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>>>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>> > >>>> >>> >> > > >>>> >> > for now.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> Hi,
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>> > >>>> >>> >> > > >>>> >> > later today.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> Uwe
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> -----
>>>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>>>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> January.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>>>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> Thx
>>>> > >>>> >>> >> > > >>>> >> > >> SG
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>> > >>>> >>> >> > > >>>> >> > >>    click here:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>> > >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> > >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>>> > >>>> >>> >> > > >>>> >> > assigned.
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> +1
>>>> > >>>> >>> >> > > >>>> >> > >>
>>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>> > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>>> > >>>> >>> >> > > >>>> >> > >> >
>>>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>>>> > >>>> >>> >> > > >>>> >> > >> >
>>>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>>>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>>>> > >>>> >>> >> > > >>>> >> > >> >
>>>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > wrote:
>>>> > >>>> >>> >> > > >>>> >> > >> >
>>>> > >>>> >>> >> > > >>>> >> > >> > 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
>>>> > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>>> > >>>> >>> >> > > >>>> >> > 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
>>>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>>> > >>>> >>> >> > > >>>> >> > >> >> >>
>>>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>> > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>>>> > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>>> > >>>> >>> >> > > >>>> >> > <er...@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
>>>> > >>>> >>> >> > > >>>> >> > <da...@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
>>>> > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>>>> > >>>> >>> >> > > >>>> >> > r%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
>>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>>> > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>>>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>>> > >>>> >>> >> > > >>>> >> > <er...@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
>>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>>> > >>>> >>> >> > > >>>> >> > <da...@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
>>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 requ
>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>>
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Thanks for fixing Cassandra and sorry for the noise. I did this too many
times in the past so I just mechanically changed the redirect without
thinking of when or if the ref guide was also released.
I'll be more careful next time ;).

On another note, now that 7.7 is out and that we're preparing the release
for 8.0 what do you think of removing/nuking the 7x branch. This was
already discussed some time ago
https://markmail.org/message/xl7vypkylhmeefhh but I don't think that we
reached a consensus and we have maybe new options with the move to gitbox.
One option discussed in the thread was to remove all files and add a README
that says that this branch is dead. I don't know if it's possible but we
could also make the branch protected in gitbox in order to avoid new
commits. What do you think ? Should we keep this branch and just consider
new commits as useless or should we try to "clean up" all Nx branches that
are not active anymore (5x, 6x, 7x) ?

Jim

Le mar. 12 févr. 2019 à 20:25, Cassandra Targett <ca...@gmail.com> a
écrit :

> I’d like to remind RMs that when finishing up a release, we can’t just do
> a blanket find/replace in .htaccess to update the version. If we’re not
> going to coordinate binary releases with Ref Guide releases, we need to be
> careful not to change the redirects unless that version’s Ref Guide release
> is also imminent.
>
> This is noted in the ReleaseToDo (
> https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc),
> but I’ve seen it occur a little too soon for the past few releases…in those
> cases, the Ref Guide release was pretty close so it didn’t matter that much.
>
> In this case, though, I haven’t had time to do a 7.7 Ref Guide so it
> doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else
> needs to maybe take care of it), but all non-version specific Ref Guide
> link is now being routed to a non-existent 7.7 path. It’s easy to fix, but
> we have an easy way to avoid routing people to dead links.
>
> Cassandra
> On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>,
> wrote:
>
> Once 7.7 is out the door, we should get on with releasing 8.0.  I
> volunteer to be the manager for this round.  My current plan is to build a
> release candidate early next week, as soon as the 7.7 release has been
> announced.
>
> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
>
> It is a shame, I agree, but some of this stuff has been deprecated since
> 3.6, so another release cycle won’t hurt :). We should prioritise cleaning
> this stuff up once 8.0 is out of the door though.
>
> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
>
> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle
> to remove things that have been deprecated in previous releases?
>  solr.LatLonType is one example.  It's a shame to keep around such things
> further.
>
> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
>
>> Not quite - the plan is to remove things entirely in 9.0, but we may need
>> to back port some extra deprecations to 8x.  We don’t necessarily need them
>> in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
>> problems.  I opened the issues to ensure that we didn’t keep carrying
>> deprecated code through any further releases.
>>
>>
>> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>>
>> I want to ensure people are aware of two issues "Remove deprecated code
>> in master" that Alan filed:
>>
>> https://issues.apache.org/jira/browse/SOLR-13138
>> https://issues.apache.org/jira/browse/LUCENE-8638
>> There's a "master-deprecations" branch as well.
>>
>> Although both issues are marked "master (9.0)", I think the intent is
>> actually 8.0 so that we are finally rid of the deprecated code?
>>
>> ~ David
>>
>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>>
>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>> I'm keeping any eye on the builds this weekend but all indications are
>>> no issues so far.
>>>
>>> Kevin Risden
>>>
>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>>> >
>>> > Nick, this change seems to be causing test failures. Can you have a
>>> look?
>>> >
>>> > See eg.
>>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>>> >
>>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>>> wrote:
>>> > >
>>> > > Thank you Jim. LUCENE-8669 has been merged.
>>> > >
>>> > > - Nick
>>> > >
>>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> > >>
>>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start
>>> the first RC when your patch is merged.
>>> > >> Kevin, this looks like a big change so I am not sure if it's a good
>>> idea to rush this in for 8.0. Would it be safer to target another version
>>> in order to take some time to ensure that it's not breaking anything ? I
>>> guess that your concern is that a change like this should happen in a major
>>> version but I wonder if it's worth the risk. I don't know this part of the
>>> code and the implications of such a change so I let you decide what we
>>> should do here but let's not delay the release if we realize that this
>>> change requires more than a few days to be merged.
>>> > >>
>>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
>>> écrit :
>>> > >>>
>>> > >>> Hey Jim,
>>> > >>>
>>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>>> along with a pretty straightforward patch. This is a critical one that I
>>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>> > >>>
>>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>>> Kevin Risden <kr...@apache.org> wrote:
>>> > >>>>
>>> > >>>> Jim,
>>> > >>>>
>>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to
>>> get
>>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it
>>> is
>>> > >>>> currently under review.
>>> > >>>>
>>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
>>> others
>>> > >>>> feel this should make it into 8.0 or not.
>>> > >>>>
>>> > >>>> Kevin Risden
>>> > >>>>
>>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>>> jim.ferenczi@gmail.com> wrote:
>>> > >>>> >
>>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x
>>> because we don't handle two concurrent releases in our tests (
>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>> > >>>> > Since we want to release 7.7 first I created the Jenkins job
>>> for this version only and will build the first candidate for this version
>>> later this week if there are no objection.
>>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>>> jim.ferenczi@gmail.com> a écrit :
>>> > >>>> >>
>>> > >>>> >> Hi,
>>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7.
>>> I'll now create the Jenkins tasks for these versions, Uwe can you also add
>>> them to the Policeman's Jenkins job ?
>>> > >>>> >> This also means that the feature freeze phase has started for
>>> both versions (7.7 and 8.0):
>>> > >>>> >>
>>> > >>>> >> No new features may be committed to the branch.
>>> > >>>> >> Documentation patches, build patches and serious bug fixes may
>>> be committed to the branch. However, you should submit all patches you want
>>> to commit to Jira first to give others the chance to review and possibly
>>> vote against the patch. Keep in mind that it is our main intention to keep
>>> the branch as stable as possible.
>>> > >>>> >> All patches that are intended for the branch should first be
>>> committed to the unstable branch, merged into the stable branch, and then
>>> into the current release branch.
>>> > >>>> >> Normal unstable and stable branch development may continue as
>>> usual. However, if you plan to commit a big change to the unstable branch
>>> while the branch feature freeze is in effect, think twice: can't the
>>> addition wait a couple more days? Merges of bug fixes into the branch may
>>> become more difficult.
>>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker"
>>> will delay a release candidate build.
>>> > >>>> >>
>>> > >>>> >>
>>> > >>>> >> Thanks,
>>> > >>>> >> Jim
>>> > >>>> >>
>>> > >>>> >>
>>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> > >>>> >>>
>>> > >>>> >>> sure, thanks Jim!
>>> > >>>> >>>
>>> > >>>> >>> Tommaso
>>> > >>>> >>>
>>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> > >>>> >>> <ji...@gmail.com> ha scritto:
>>> > >>>> >>> >
>>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow
>>> or wednesday and to announce the feature freeze the same day.
>>> > >>>> >>> > For blocker issues that are still open this leaves another
>>> week to work on a patch and we can update the status at the end of the week
>>> in order to decide if we can start the first build candidate
>>> > >>>> >>> > early next week. Would that work for you ?
>>> > >>>> >>> >
>>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> > >>>> >>> >>
>>> > >>>> >>> >> I'd like to backport
>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
>>> time.
>>> > >>>> >>> >>
>>> > >>>> >>> >> Regards,
>>> > >>>> >>> >> Tommaso
>>> > >>>> >>> >>
>>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> > >>>> >>> >> <jp...@gmail.com> ha scritto:
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > Hi Noble,
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > No it hasn't created yet.
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>> noble.paul@gmail.com> wrote:
>>> > >>>> >>> >> > >
>>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>> > >>>> >>> >> > >
>>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>> david.w.smiley@gmail.com> wrote:
>>> > >>>> >>> >> > > >
>>> > >>>> >>> >> > > > I finally have a patch up for
>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>>> blocker) that I feel pretty good about.  This provides a key part of the
>>> nested document support.
>>> > >>>> >>> >> > > > I will work on some documentation for it this week
>>> -- SOLR-13129
>>> > >>>> >>> >> > > >
>>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>> jan.asf@cominvent.com> wrote:
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> I don't think it is critical for this to be a
>>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>>> ooold bug.
>>> > >>>> >>> >> > > >> I think we should simply remove the buffering
>>> feature in the UI and replace it with an error message popup or something.
>>> > >>>> >>> >> > > >> I'll try to take a look next week.
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> --
>>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe
>>> <to...@gmail.com>:
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As
>>> long as there is a reasonable time horizon for the issue being resolved I'm
>>> +1 on making it a blocker. I'm not familiar enough with the UI code to help
>>> either unfortunately.
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> > >>>> >>> >> > > >>>
>>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker
>>> once before... And it's actually a duplicate of an earlier issue (
>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>> question of whether or not overall quality has a bearing on the decision to
>>> release. As it turns out the screen shot I posted to the issue is less than
>>> half of the shards that eventually got created since there was an
>>> outstanding queue of requests still processing at the time. I'm now having
>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>> or less makes it impossible to recommend the use of the admin UI for
>>> anything other than read only observation of the cluster. Now imagine
>>> someone leaves a browser window open and forgets about it
>>> <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g>
>>> rather than browsing away or closing the window, not knowing that it's
>>> silently pumping out requests after showing an error... would completely
>>> hose a node, and until they tracked down the source of the requests, (hope
>>> he didn't go home) it would be impossible to resolve...
>>> > >>>> >>> >> > > >>>
>>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>> jpountz@gmail.com> wrote:
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its
>>> own, I'd rather not
>>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it
>>> since this isn't a new
>>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that
>>> has affected Solr
>>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI
>>> code at all, but
>>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed
>>> before we build a RC?
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> > >>>> >>> >> > > >>>> >
>>> > >>>> >>> >> > > >>>> > I'd like to suggest that
>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>> 8.0. I just got burned by it a second time.
>>> > >>>> >>> >> > > >>>> >
>>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> Cool,
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time
>>> guess as possible on the FOSDEM conference!
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> Uwe
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> -----
>>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>> > >>>> >>> >> > > >>>> >> >
>>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting
>>> on the week of February 4th.
>>> > >>>> >>> >> > > >>>> >> >
>>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi
>>> <ji...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > > Hi,
>>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to
>>> start on releasing 8.0. The branch is
>>> > >>>> >>> >> > > >>>> >> > already created so we can start the process
>>> anytime now. Unless there are
>>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature
>>> freeze next week in order to build the
>>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think
>>> we can handle both with Alan so
>>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to
>>> start the release process or if there
>>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan
>>> Woodward <ro...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > a écrit :
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various
>>> deprecations on the new master
>>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m
>>> going to need some assistance for
>>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear
>>> what to do.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA,
>>> one for lucene and one for Solr,
>>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to
>>> be removed in each one.  I’ll create
>>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against,
>>> and push the changes I’ve already
>>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual
>>> JIRA issues for any changes that
>>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received,
>>> particularly for the Solr deprecations
>>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar
>>> with.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>>> romseygeek@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7
>>> release at the same time as 8.0, to
>>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So
>>> let’s keep those jobs enabled
>>> > >>>> >>> >> > > >>>> >> > for now.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Hi,
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs
>>> to Jenkins once I have some time
>>> > >>>> >>> >> > > >>>> >> > later today.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with
>>> branch_7x? Should we stop using it
>>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use
>>> branch_7_6 only for bugfixes), or
>>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7?
>>> In the latter case I would keep
>>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Uwe
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> -----
>>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <romseygeek@gmail.com
>>> >
>>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit…
>>> I’ve just created a branch for 8x
>>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of
>>> updating the master branch to version
>>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in
>>> the 8.0 release should also be
>>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze,
>>> as I know there are still some
>>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it
>>> should let us clean up master by
>>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as
>>> possible, and give us an idea of any
>>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>>> david.w.smiley@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> January.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>> sg.online.email@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January
>>> soon as there is an enhancement
>>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get
>>> our hands on.
>>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Thx
>>> > >>>> >>> >> > > >>>> >> > >> SG
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David
>>> Smiley
>>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this
>>> filter:   project in (SOLR, LUCENE) AND
>>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and
>>> fixVersion = "master (8.0)"
>>> > >>>> >>> >> > > >>>> >> > >>    click here:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> >
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> > >>>> >>> >> > > >>>> >> >
>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> > >>>> >>> >> > > >>>> >> >
>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to
>>> work on those issues not yet
>>> > >>>> >>> >> > > >>>> >> > assigned.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>>> Grand <jp...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> +1
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan
>>> Woodward
>>> > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks
>>> Nick!) we should think about
>>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to
>>> 9.0.  I’ll volunteer to create the
>>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we
>>> should have some time to
>>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover
>>> anything that still needs to be done
>>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process
>>> next year.
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra
>>> Targett <ca...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > 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
>>> > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>> > >>>> >>> >> > > >>>> >> > 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
>>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>> > >>>> >>> >> > > >>>> >> > >> >> >>
>>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM
>>> Nicholas Knize
>>> > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>>> > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>> > >>>> >>> >> > > >>>> >> > <er...@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
>>> > >>>> >>> >> > > >>>> >> > <da...@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
>>> > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>>> > >>>> >>> >> > > >>>> >> > r%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
>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>> > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à
>>> 10:36, jim ferenczi
>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>> > >>>> >>> >> > > >>>> >> > <er...@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
>>> > >>>> >>> >> > > >>>> >> > <ca...@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
>>> > >>>> >>> >> > > >>>> >> > <ji...@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
>>> > >>>> >>> >> > > >>>> >> > <da...@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
>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>>> > >>>> >>> >> > > >>>> >> > <jp...@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
>>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 requ
>>
>> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>
>

Re: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

I’d like to remind RMs that when finishing up a release, we can’t just do a blanket find/replace in .htaccess to update the version. If we’re not going to coordinate binary releases with Ref Guide releases, we need to be careful not to change the redirects unless that version’s Ref Guide release is also imminent.

This is noted in the ReleaseToDo (https://wiki.apache.org/lucene-java/ReleaseTodo#Update_redirect_to_latest_Javadoc), but I’ve seen it occur a little too soon for the past few releases…in those cases, the Ref Guide release was pretty close so it didn’t matter that much.

In this case, though, I haven’t had time to do a 7.7 Ref Guide so it doesn’t exist yet (if it will ever be, I’m pretty swamped so someone else needs to maybe take care of it), but all non-version specific Ref Guide link is now being routed to a non-existent 7.7 path. It’s easy to fix, but we have an easy way to avoid routing people to dead links.

Cassandra
On Feb 8, 2019, 3:58 AM -0600, Alan Woodward <ro...@gmail.com>, wrote:
> Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.
>
> > On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> >
> > It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> >
> > > On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> > >
> > > Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> > >
> > > > On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:
> > > > > Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> > > > >
> > > > >
> > > > > > On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
> > > > > >
> > > > > > I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> > > > > >
> > > > > > https://issues.apache.org/jira/browse/SOLR-13138
> > > > > > https://issues.apache.org/jira/browse/LUCENE-8638
> > > > > > There's a "master-deprecations" branch as well.
> > > > > >
> > > > > > Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> > > > > >
> > > > > > ~ David
> > > > > >
> > > > > > > On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
> > > > > > > > SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> > > > > > > > I'm keeping any eye on the builds this weekend but all indications are
> > > > > > > > no issues so far.
> > > > > > > >
> > > > > > > > Kevin Risden
> > > > > > > >
> > > > > > > > On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> > > > > > > > >
> > > > > > > > > Nick, this change seems to be causing test failures. Can you have a look?
> > > > > > > > >
> > > > > > > > > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> > > > > > > > >
> > > > > > > > > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > > > > > > > > >
> > > > > > > > > > Thank you Jim. LUCENE-8669 has been merged.
> > > > > > > > > >
> > > > > > > > > > - Nick
> > > > > > > > > >
> > > > > > > > > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> > > > > > > > > >>
> > > > > > > > > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > > > > > > > > >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > > > > > > > > >>
> > > > > > > > > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> > > > > > > > > >>>
> > > > > > > > > >>> Hey Jim,
> > > > > > > > > >>>
> > > > > > > > > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > > > > > > > > >>>
> > > > > > > > > >>> On Wed, Jan 30, 2019 at 1:07 PM
> > > > > > > > Kevin Risden <kr...@apache.org> wrote:
> > > > > > > > > >>>>
> > > > > > > > > >>>> Jim,
> > > > > > > > > >>>>
> > > > > > > > > >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
> > > > > > > > > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > > > > > > > > >>>> currently under review.
> > > > > > > > > >>>>
> > > > > > > > > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > > > > > > > > >>>> feel this should make it into 8.0 or not.
> > > > > > > > > >>>>
> > > > > > > > > >>>> Kevin Risden
> > > > > > > > > >>>>
> > > > > > > > > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> > > > > > > > > >>>> >
> > > > > > > > > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> > > > > > > > > >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > > > > > > > > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
> > > > > > > > > >>>> >
> > > > > > > > > >>>> >
> > > > > > > > > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >> Hi,
> > > > > > > > > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > > > > > > > > >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >> No new features may be committed to the branch.
> > > > > > > > > >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > > > > > > > > >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > > > > > > > > >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > > > > > > > > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >> Thanks,
> > > > > > > > > >>>> >> Jim
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >>
> > > > > > > > > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> > > > > > > > > >>>> >>>
> > > > > > > > > >>>> >>> sure, thanks Jim!
> > > > > > > > > >>>> >>>
> > > > > > > > > >>>> >>> Tommaso
> > > > > > > > > >>>> >>>
> > > > > > > > > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > > > > > > > > >>>> >>> <ji...@gmail.com> ha scritto:
> > > > > > > > > >>>> >>> >
> > > > > > > > > >>>> >>> > Go ahead Tommaso the branch is not created yet.
> > > > > > > > > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > > > > > > > > >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > > > > > > > > >>>> >>> > early next week. Would that work for you ?
> > > > > > > > > >>>> >>> >
> > > > > > > > > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> > > > > > > > > >>>> >>> >>
> > > > > > > > > >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> > > > > > > > > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > > > > > > > > >>>> >>> >>
> > > > > > > > > >>>> >>> >> Regards,
> > > > > > > > > >>>> >>> >> Tommaso
> > > > > > > > > >>>> >>> >>
> > > > > > > > > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > > > > > > > > >>>> >>> >> <jp...@gmail.com> ha scritto:
> > > > > > > > > >>>> >>> >> >
> > > > > > > > > >>>> >>> >> > Hi Noble,
> > > > > > > > > >>>> >>> >> >
> > > > > > > > > >>>> >>> >> > No it hasn't created yet.
> > > > > > > > > >>>> >>> >> >
> > > > > > > > > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > >
> > > > > > > > > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
> > > > > > > > > >>>> >>> >> > >
> > > > > > > > > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >
> > > > > > > > > >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > > > > > > > > >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
> > > > > > > > > >>>> >>> >> > > >
> > > > > > > > > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>
> > > > > > > > > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > > > > > > > >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > > > > > > > > >>>> >>> >> > > >> I'll try to take a look next week.
> > > > > > > > > >>>> >>> >> > > >>
> > > > > > > > > >>>> >>> >> > > >> --
> > > > > > > > > >>>> >>> >> > > >> Jan Høydahl, search solution architect
> > > > > > > > > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
> > > > > > > > > >>>> >>> >> > > >>
> > > > > > > > > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > > > > > > > > >>>> >>> >> > > >>
> > > > > > > > > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > > > > > > > > >>>> >>> >> > > >>
> > > > > > > > > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>>
> > > > > > > > > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > > > > > > > > >>>> >>> >> > > >>>
> > > > > > > > > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>>>
> > > > > > > > > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
> > > > > > > > > >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
> > > > > > > > > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
> > > > > > > > > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> > > > > > > > > >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
> > > > > > > > > >>>> >>> >> > > >>>>
> > > > > > > > > >>>> >>> >> > > >>>>
> > > > > > > > > >>>> >>> >> > > >>>>
> > > > > > > > > >>>> >>> >> > > >>>>
> > > > > > > > > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >
> > > > > > > > > >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > > > > > > > > >>>> >>> >> > > >>>> >
> > > > > > > > > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> Cool,
> > > > > > > > > >>>> >>> >> > > >>>> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> > > > > > > > > >>>> >>> >> > > >>>> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> Uwe
> > > > > > > > > >>>> >>> >> > > >>>> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> -----
> > > > > > > > > >>>> >>> >> > > >>>> >> Uwe Schindler
> > > > > > > > > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> > > > > > > > > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
> > > > > > > > > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
> > > > > > > > > >>>> >>> >> > > >>>> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > -----Original Message-----
> > > > > > > > > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> > > > > > > > > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> > > > > > > > > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> > > > > > > > > >>>> >>> >> > > >>>> >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > > > > > > > > >>>> >>> >> > > >>>> >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >
> > > > > > > > > >>>> >>> >> > > >>>> >> > > Hi,
> > > > > > > > > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > > > > > > > > >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
> > > > > > > > > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
> > > > > > > > > >>>> >>> >> > > >>>> >> > first candidate the week after.
> > > > > > > > > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> > > > > > > > > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
> > > > > > > > > >>>> >>> >> > > >>>> >> > are any blockers left ;).
> > > > > > > > > >>>> >>> >> > > >>>> >> > >
> > > > > > > > > >>>> >>> >> > > >>>> >> > >
> > > > > > > > > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > a écrit :
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
> > > > > > > > > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> > > > > > > > > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > > > > > > > > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> > > > > > > > > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> > > > > > > > > >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
> > > > > > > > > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> > > > > > > > > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > > > > > > > > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > > > > > > > > >>>> >>> >> > > >>>> >> > for now.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Hi,
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> > > > > > > > > >>>> >>> >> > > >>>> >> > later today.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> > > > > > > > > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > > > > > > > > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > > > > > > > > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Uwe
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> -----
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > > > > > > > > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
> > > > > > > > > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
> > > > > > > > > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
> > > > > > > > > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
> > > > > > > > > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
> > > > > > > > > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> January.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> > > > > > > > > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Thx
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> SG
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > > > > > > > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > > > > > > > > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>    click here:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > > > > > > > >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > > > > > > > >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
> > > > > > > > > >>>> >>> >> > > >>>> >> > assigned.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> +1
> > > > > > > > > >>>> >>> >> > > >>>> >> > >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> > Hi all,
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > > > > > > > > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > > > > > > > > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
> > > > > > > > > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
> > > > > > > > > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > wrote:
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> > 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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> > > > > > > > > >>>> >>> >> > > >>>> >> > 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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >> >>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > > > > > > > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ji...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ca...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ji...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ca...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <er...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <da...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
> > > > > > > > > >>>> >>> >> > > >>>> >> > r%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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <jp...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
> > > > > > > > > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> > > > > > > > > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ji...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <er...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ca...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <ji...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <da...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <jp...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <jp...@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
> > > > > > > > > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 requ
> > > --
> > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
> >
>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Once 7.7 is out the door, we should get on with releasing 8.0.  I volunteer to be the manager for this round.  My current plan is to build a release candidate early next week, as soon as the 7.7 release has been announced.

> On 8 Feb 2019, at 09:07, Alan Woodward <ro...@gmail.com> wrote:
> 
> It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.
> 
>> On 8 Feb 2019, at 07:27, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> 
>> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
>> 
>> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
>> 
>> 
>>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> 
>>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>>> 
>>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>>> There's a "master-deprecations" branch as well.
>>> 
>>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>>> 
>>> ~ David
>>> 
>>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>>> I'm keeping any eye on the builds this weekend but all indications are
>>> no issues so far.
>>> 
>>> Kevin Risden
>>> 
>>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>> >
>>> > Nick, this change seems to be causing test failures. Can you have a look?
>>> >
>>> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>>> >
>>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>>> > >
>>> > > Thank you Jim. LUCENE-8669 has been merged.
>>> > >
>>> > > - Nick
>>> > >
>>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> > >>
>>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>>> > >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>> > >>
>>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>
>>> > >>> Hey Jim,
>>> > >>>
>>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>> > >>>
>>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>>> > >>>>
>>> > >>>> Jim,
>>> > >>>>
>>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>> > >>>> currently under review.
>>> > >>>>
>>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>> > >>>> feel this should make it into 8.0 or not.
>>> > >>>>
>>> > >>>> Kevin Risden
>>> > >>>>
>>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >
>>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>>> > >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>> > >>>> >
>>> > >>>> >
>>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>> >>
>>> > >>>> >> Hi,
>>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>> > >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>> > >>>> >>
>>> > >>>> >> No new features may be committed to the branch.
>>> > >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>> > >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>> > >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>> > >>>> >>
>>> > >>>> >>
>>> > >>>> >> Thanks,
>>> > >>>> >> Jim
>>> > >>>> >>
>>> > >>>> >>
>>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>> >>>
>>> > >>>> >>> sure, thanks Jim!
>>> > >>>> >>>
>>> > >>>> >>> Tommaso
>>> > >>>> >>>
>>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> > >>>> >>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>>> > >>>> >>> >
>>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>> > >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>> > >>>> >>> > early next week. Would that work for you ?
>>> > >>>> >>> >
>>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>> >>> >>
>>> > >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>> > >>>> >>> >>
>>> > >>>> >>> >> Regards,
>>> > >>>> >>> >> Tommaso
>>> > >>>> >>> >>
>>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> > >>>> >>> >> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > Hi Noble,
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > No it hasn't created yet.
>>> > >>>> >>> >> >
>>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > >
>>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>> > >>>> >>> >> > >
>>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >
>>> > >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>> > >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>>> > >>>> >>> >> > > >
>>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>> > >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>> > >>>> >>> >> > > >> I'll try to take a look next week.
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> --
>>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>> > >>>> >>> >> > > >>
>>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>
>>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g> rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>> > >>>> >>> >> > > >>>
>>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>>
>>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>> >
>>> > >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>>> > >>>> >>> >> > > >>>> >
>>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> Cool,
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> Uwe
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> -----
>>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de <http://www.thetaphi.de/>
>>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>> > >>>> >>> >> > > >>>> >>
>>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>> > >>>> >>> >> > > >>>> >> >
>>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>> > >>>> >>> >> > > >>>> >> >
>>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > > Hi,
>>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>> > >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > >
>>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > a écrit :
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>> > >>>> >>> >> > > >>>> >> > for now.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Hi,
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>> > >>>> >>> >> > > >>>> >> > later today.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Uwe
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> -----
>>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de <http://www.thetaphi.de/>
>>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> January.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Thx
>>> > >>>> >>> >> > > >>>> >> > >> SG
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> > >>>> >>> >> > > >>>> >> > >>    click here:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>>> > >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> > >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>> > >>>> >>> >> > > >>>> >> > assigned.
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> +1
>>> > >>>> >>> >> > > >>>> >> > >>
>>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> > >>>> >>> >> > > >>>> >> > <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >
>>> > >>>> >>> >> > > >>>> >> > >> > 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
>>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>>> > >>>> >>> >> > > >>>> >> > 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
>>> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>> >>> >> > > >>>> >> > >> >> >>
>>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> > >>>> >>> >> > > >>>> >> > <nknize@gmail.com <ma...@gmail.com>> 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
>>> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>>> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> I find 9 open blockers for 8.0:
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> Hi,
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 release:
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>>> > >>>> >>> >> > > >>>> >> > 7075?jql=(project%3D%22Lucene%20-
>>> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>> > >>>> >>> >> > > >>>> >> > r%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
>>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>>> > >>>> >>> >> > > >>>> >> > 12720?jql=(project%3D%22Lucene%20-
>>> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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
>>> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>
>>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir
>>> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 requ
>> -- 
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

It is a shame, I agree, but some of this stuff has been deprecated since 3.6, so another release cycle won’t hurt :). We should prioritise cleaning this stuff up once 8.0 is out of the door though.

> On 8 Feb 2019, at 07:27, David Smiley <da...@gmail.com> wrote:
> 
> Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to remove things that have been deprecated in previous releases?  solr.LatLonType is one example.  It's a shame to keep around such things further.
> 
> On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.
> 
> 
>> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> 
>> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
>> 
>> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
>> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
>> There's a "master-deprecations" branch as well.
>> 
>> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
>> 
>> ~ David
>> 
>> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> I'm keeping any eye on the builds this weekend but all indications are
>> no issues so far.
>> 
>> Kevin Risden
>> 
>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>> >
>> > Nick, this change seems to be causing test failures. Can you have a look?
>> >
>> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
>> > >
>> > > Thank you Jim. LUCENE-8669 has been merged.
>> > >
>> > > - Nick
>> > >
>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> > >>
>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>> > >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>> > >>
>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>
>> > >>> Hey Jim,
>> > >>>
>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> > >>>
>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
>> > >>>>
>> > >>>> Jim,
>> > >>>>
>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> > >>>> currently under review.
>> > >>>>
>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> > >>>> feel this should make it into 8.0 or not.
>> > >>>>
>> > >>>> Kevin Risden
>> > >>>>
>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >
>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
>> > >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> > >>>> >
>> > >>>> >
>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>> >>
>> > >>>> >> Hi,
>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>> > >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>> > >>>> >>
>> > >>>> >> No new features may be committed to the branch.
>> > >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>> > >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>> > >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Thanks,
>> > >>>> >> Jim
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>> >>>
>> > >>>> >>> sure, thanks Jim!
>> > >>>> >>>
>> > >>>> >>> Tommaso
>> > >>>> >>>
>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > >>>> >>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
>> > >>>> >>> >
>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>> > >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>> > >>>> >>> > early next week. Would that work for you ?
>> > >>>> >>> >
>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>> >>> >>
>> > >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> > >>>> >>> >>
>> > >>>> >>> >> Regards,
>> > >>>> >>> >> Tommaso
>> > >>>> >>> >>
>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > >>>> >>> >> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
>> > >>>> >>> >> >
>> > >>>> >>> >> > Hi Noble,
>> > >>>> >>> >> >
>> > >>>> >>> >> > No it hasn't created yet.
>> > >>>> >>> >> >
>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>> > >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> > >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> > >>>> >>> >> > > >> I'll try to take a look next week.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> --
>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g> rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Cool,
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Uwe
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> -----
>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de <http://www.thetaphi.de/>
>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Hi,
>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> > >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > a écrit :
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> > >>>> >>> >> > > >>>> >> > for now.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Hi,
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>> > >>>> >>> >> > > >>>> >> > later today.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Uwe
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> -----
>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de <http://www.thetaphi.de/>
>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> January.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thx
>> > >>>> >>> >> > > >>>> >> > >> SG
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> > >>>> >>> >> > > >>>> >> > >>    click here:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
>> > >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>> > >>>> >>> >> > > >>>> >> > assigned.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> +1
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> > >>>> >>> >> > > >>>> >> > <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > 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
>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
>> > >>>> >>> >> > > >>>> >> > 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
>> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>> >>> >> > > >>>> >> > >> >> >>
>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> > >>>> >>> >> > > >>>> >> > <nknize@gmail.com <ma...@gmail.com>> 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
>> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@gmail.com>> 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
>> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> I find 9 open blockers for 8.0:
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> Hi,
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 release:
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
>> > >>>> >>> >> > > >>>> >> > 7075?jql=(project%3D%22Lucene%20-
>> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%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
>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
>> > >>>> >>> >> > > >>>> >> > 12720?jql=(project%3D%22Lucene%20-
>> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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
>> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
>> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir
>> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 requ
> -- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

Okay.  I suppose the issue is that it's simply too late in the 8.0 cycle to
remove things that have been deprecated in previous releases?
 solr.LatLonType is one example.  It's a shame to keep around such things
further.

On Thu, Feb 7, 2019 at 1:03 AM Alan Woodward <ro...@gmail.com> wrote:

> Not quite - the plan is to remove things entirely in 9.0, but we may need
> to back port some extra deprecations to 8x.  We don’t necessarily need them
> in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
>
>
> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>
> I want to ensure people are aware of two issues "Remove deprecated code in
> master" that Alan filed:
>
> https://issues.apache.org/jira/browse/SOLR-13138
> https://issues.apache.org/jira/browse/LUCENE-8638
> There's a "master-deprecations" branch as well.
>
> Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
>
> ~ David
>
> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>
>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> I'm keeping any eye on the builds this weekend but all indications are
>> no issues so far.
>>
>> Kevin Risden
>>
>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> > Nick, this change seems to be causing test failures. Can you have a
>> look?
>> >
>> > See eg.
>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>> wrote:
>> > >
>> > > Thank you Jim. LUCENE-8669 has been merged.
>> > >
>> > > - Nick
>> > >
>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
>> wrote:
>> > >>
>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start
>> the first RC when your patch is merged.
>> > >> Kevin, this looks like a big change so I am not sure if it's a good
>> idea to rush this in for 8.0. Would it be safer to target another version
>> in order to take some time to ensure that it's not breaking anything ? I
>> guess that your concern is that a change like this should happen in a major
>> version but I wonder if it's worth the risk. I don't know this part of the
>> code and the implications of such a change so I let you decide what we
>> should do here but let's not delay the release if we realize that this
>> change requires more than a few days to be merged.
>> > >>
>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
>> écrit :
>> > >>>
>> > >>> Hey Jim,
>> > >>>
>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>> along with a pretty straightforward patch. This is a critical one that I
>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> > >>>
>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>> Kevin Risden <kr...@apache.org> wrote:
>> > >>>>
>> > >>>> Jim,
>> > >>>>
>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to
>> get
>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it
>> is
>> > >>>> currently under review.
>> > >>>>
>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
>> others
>> > >>>> feel this should make it into 8.0 or not.
>> > >>>>
>> > >>>> Kevin Risden
>> > >>>>
>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>> jim.ferenczi@gmail.com> wrote:
>> > >>>> >
>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x
>> because we don't handle two concurrent releases in our tests (
>> https://issues.apache.org/jira/browse/LUCENE-8665).
>> > >>>> > Since we want to release 7.7 first I created the Jenkins job for
>> this version only and will build the first candidate for this version later
>> this week if there are no objection.
>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> > >>>> >
>> > >>>> >
>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>> jim.ferenczi@gmail.com> a écrit :
>> > >>>> >>
>> > >>>> >> Hi,
>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7.
>> I'll now create the Jenkins tasks for these versions, Uwe can you also add
>> them to the Policeman's Jenkins job ?
>> > >>>> >> This also means that the feature freeze phase has started for
>> both versions (7.7 and 8.0):
>> > >>>> >>
>> > >>>> >> No new features may be committed to the branch.
>> > >>>> >> Documentation patches, build patches and serious bug fixes may
>> be committed to the branch. However, you should submit all patches you want
>> to commit to Jira first to give others the chance to review and possibly
>> vote against the patch. Keep in mind that it is our main intention to keep
>> the branch as stable as possible.
>> > >>>> >> All patches that are intended for the branch should first be
>> committed to the unstable branch, merged into the stable branch, and then
>> into the current release branch.
>> > >>>> >> Normal unstable and stable branch development may continue as
>> usual. However, if you plan to commit a big change to the unstable branch
>> while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch may
>> become more difficult.
>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker"
>> will delay a release candidate build.
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Thanks,
>> > >>>> >> Jim
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> > >>>> >>>
>> > >>>> >>> sure, thanks Jim!
>> > >>>> >>>
>> > >>>> >>> Tommaso
>> > >>>> >>>
>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > >>>> >>> <ji...@gmail.com> ha scritto:
>> > >>>> >>> >
>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow
>> or wednesday and to announce the feature freeze the same day.
>> > >>>> >>> > For blocker issues that are still open this leaves another
>> week to work on a patch and we can update the status at the end of the week
>> in order to decide if we can start the first build candidate
>> > >>>> >>> > early next week. Would that work for you ?
>> > >>>> >>> >
>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> > >>>> >>> >>
>> > >>>> >>> >> I'd like to backport
>> https://issues.apache.org/jira/browse/LUCENE-8659
>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
>> time.
>> > >>>> >>> >>
>> > >>>> >>> >> Regards,
>> > >>>> >>> >> Tommaso
>> > >>>> >>> >>
>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > >>>> >>> >> <jp...@gmail.com> ha scritto:
>> > >>>> >>> >> >
>> > >>>> >>> >> > Hi Noble,
>> > >>>> >>> >> >
>> > >>>> >>> >> > No it hasn't created yet.
>> > >>>> >>> >> >
>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>> noble.paul@gmail.com> wrote:
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>> david.w.smiley@gmail.com> wrote:
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> > >>>> >>> >> > > > I will work on some documentation for it this week --
>> SOLR-13129
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>> jan.asf@cominvent.com> wrote:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I don't think it is critical for this to be a
>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>> ooold bug.
>> > >>>> >>> >> > > >> I think we should simply remove the buffering
>> feature in the UI and replace it with an error message popup or something.
>> > >>>> >>> >> > > >> I'll try to take a look next week.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> --
>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long
>> as there is a reasonable time horizon for the issue being resolved I'm +1
>> on making it a blocker. I'm not familiar enough with the UI code to help
>> either unfortunately.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker
>> once before... And it's actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it
>> <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g>
>> rather than browsing away or closing the window, not knowing that it's
>> silently pumping out requests after showing an error... would completely
>> hose a node, and until they tracked down the source of the requests, (hope
>> he didn't go home) it would be impossible to resolve...
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>> jpountz@gmail.com> wrote:
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its
>> own, I'd rather not
>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it
>> since this isn't a new
>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that
>> has affected Solr
>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI
>> code at all, but
>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed
>> before we build a RC?
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Cool,
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time
>> guess as possible on the FOSDEM conference!
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Uwe
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> -----
>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting
>> on the week of February 4th.
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>> jim.ferenczi@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Hi,
>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to
>> start on releasing 8.0. The branch is
>> > >>>> >>> >> > > >>>> >> > already created so we can start the process
>> anytime now. Unless there are
>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature
>> freeze next week in order to build the
>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think
>> we can handle both with Alan so
>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to
>> start the release process or if there
>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan
>> Woodward <ro...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > a écrit :
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various
>> deprecations on the new master
>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m
>> going to need some assistance for
>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear
>> what to do.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA,
>> one for lucene and one for Solr,
>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to
>> be removed in each one.  I’ll create
>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against,
>> and push the changes I’ve already
>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual
>> JIRA issues for any changes that
>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received,
>> particularly for the Solr deprecations
>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar
>> with.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>> romseygeek@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7
>> release at the same time as 8.0, to
>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So
>> let’s keep those jobs enabled
>> > >>>> >>> >> > > >>>> >> > for now.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Hi,
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to
>> Jenkins once I have some time
>> > >>>> >>> >> > > >>>> >> > later today.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with
>> branch_7x? Should we stop using it
>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use
>> branch_7_6 only for bugfixes), or
>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7?
>> In the latter case I would keep
>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Uwe
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> -----
>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit…
>> I’ve just created a branch for 8x
>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of
>> updating the master branch to version
>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in
>> the 8.0 release should also be
>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze,
>> as I know there are still some
>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it
>> should let us clean up master by
>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible,
>> and give us an idea of any
>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>> david.w.smiley@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> January.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>> sg.online.email@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January
>> soon as there is an enhancement
>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our
>> hands on.
>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thx
>> > >>>> >>> >> > > >>>> >> > >> SG
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David
>> Smiley
>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this
>> filter:   project in (SOLR, LUCENE) AND
>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and
>> fixVersion = "master (8.0)"
>> > >>>> >>> >> > > >>>> >> > >>    click here:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> >
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > >>>> >>> >> > > >>>> >> >
>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > >>>> >>> >> > > >>>> >> >
>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to
>> work on those issues not yet
>> > >>>> >>> >> > > >>>> >> > assigned.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>> Grand <jp...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> +1
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan
>> Woodward
>> > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks
>> Nick!) we should think about
>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to
>> 9.0.  I’ll volunteer to create the
>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we
>> should have some time to
>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover
>> anything that still needs to be done
>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process
>> next year.
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra
>> Targett <ca...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > 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
>> > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > 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
>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>> > >>>> >>> >> > > >>>> >> > >> >> >>
>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM
>> Nicholas Knize
>> > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>> > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <er...@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
>> > >>>> >>> >> > > >>>> >> > <da...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à
>> 10:36, jim ferenczi
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <er...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <da...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 requ
>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Hi,
I created the curated highlights for the 7.7.0 release:

   - Lucene: https://wiki.apache.org/lucene-java/ReleaseNote77
   - Solr: https://wiki.apache.org/solr/ReleaseNote77


Could you please help to check that I did not miss important entries in the
list ?

Thanks,
Jim

Le jeu. 7 févr. 2019 à 10:03, Alan Woodward <ro...@gmail.com> a écrit :

> Not quite - the plan is to remove things entirely in 9.0, but we may need
> to back port some extra deprecations to 8x.  We don’t necessarily need them
> in 8.0 though - we can deprecate in 8.1 and remove in 9 without any
> problems.  I opened the issues to ensure that we didn’t keep carrying
> deprecated code through any further releases.
>
> On 7 Feb 2019, at 06:43, David Smiley <da...@gmail.com> wrote:
>
> I want to ensure people are aware of two issues "Remove deprecated code in
> master" that Alan filed:
>
> https://issues.apache.org/jira/browse/SOLR-13138
> https://issues.apache.org/jira/browse/LUCENE-8638
> There's a "master-deprecations" branch as well.
>
> Although both issues are marked "master (9.0)", I think the intent is
> actually 8.0 so that we are finally rid of the deprecated code?
>
> ~ David
>
> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:
>
>> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
>> I'm keeping any eye on the builds this weekend but all indications are
>> no issues so far.
>>
>> Kevin Risden
>>
>> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>> >
>> > Nick, this change seems to be causing test failures. Can you have a
>> look?
>> >
>> > See eg.
>> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>> >
>> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com>
>> wrote:
>> > >
>> > > Thank you Jim. LUCENE-8669 has been merged.
>> > >
>> > > - Nick
>> > >
>> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
>> wrote:
>> > >>
>> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start
>> the first RC when your patch is merged.
>> > >> Kevin, this looks like a big change so I am not sure if it's a good
>> idea to rush this in for 8.0. Would it be safer to target another version
>> in order to take some time to ensure that it's not breaking anything ? I
>> guess that your concern is that a change like this should happen in a major
>> version but I wonder if it's worth the risk. I don't know this part of the
>> code and the implications of such a change so I let you decide what we
>> should do here but let's not delay the release if we realize that this
>> change requires more than a few days to be merged.
>> > >>
>> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
>> écrit :
>> > >>>
>> > >>> Hey Jim,
>> > >>>
>> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
>> along with a pretty straightforward patch. This is a critical one that I
>> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>> > >>>
>> > >>> On Wed, Jan 30, 2019 at 1:07 PM
>> Kevin Risden <kr...@apache.org> wrote:
>> > >>>>
>> > >>>> Jim,
>> > >>>>
>> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to
>> get
>> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it
>> is
>> > >>>> currently under review.
>> > >>>>
>> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
>> others
>> > >>>> feel this should make it into 8.0 or not.
>> > >>>>
>> > >>>> Kevin Risden
>> > >>>>
>> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
>> jim.ferenczi@gmail.com> wrote:
>> > >>>> >
>> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x
>> because we don't handle two concurrent releases in our tests (
>> https://issues.apache.org/jira/browse/LUCENE-8665).
>> > >>>> > Since we want to release 7.7 first I created the Jenkins job for
>> this version only and will build the first candidate for this version later
>> this week if there are no objection.
>> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> > >>>> >
>> > >>>> >
>> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
>> jim.ferenczi@gmail.com> a écrit :
>> > >>>> >>
>> > >>>> >> Hi,
>> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7.
>> I'll now create the Jenkins tasks for these versions, Uwe can you also add
>> them to the Policeman's Jenkins job ?
>> > >>>> >> This also means that the feature freeze phase has started for
>> both versions (7.7 and 8.0):
>> > >>>> >>
>> > >>>> >> No new features may be committed to the branch.
>> > >>>> >> Documentation patches, build patches and serious bug fixes may
>> be committed to the branch. However, you should submit all patches you want
>> to commit to Jira first to give others the chance to review and possibly
>> vote against the patch. Keep in mind that it is our main intention to keep
>> the branch as stable as possible.
>> > >>>> >> All patches that are intended for the branch should first be
>> committed to the unstable branch, merged into the stable branch, and then
>> into the current release branch.
>> > >>>> >> Normal unstable and stable branch development may continue as
>> usual. However, if you plan to commit a big change to the unstable branch
>> while the branch feature freeze is in effect, think twice: can't the
>> addition wait a couple more days? Merges of bug fixes into the branch may
>> become more difficult.
>> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker"
>> will delay a release candidate build.
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Thanks,
>> > >>>> >> Jim
>> > >>>> >>
>> > >>>> >>
>> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> > >>>> >>>
>> > >>>> >>> sure, thanks Jim!
>> > >>>> >>>
>> > >>>> >>> Tommaso
>> > >>>> >>>
>> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> > >>>> >>> <ji...@gmail.com> ha scritto:
>> > >>>> >>> >
>> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
>> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow
>> or wednesday and to announce the feature freeze the same day.
>> > >>>> >>> > For blocker issues that are still open this leaves another
>> week to work on a patch and we can update the status at the end of the week
>> in order to decide if we can start the first build candidate
>> > >>>> >>> > early next week. Would that work for you ?
>> > >>>> >>> >
>> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> > >>>> >>> >>
>> > >>>> >>> >> I'd like to backport
>> https://issues.apache.org/jira/browse/LUCENE-8659
>> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
>> time.
>> > >>>> >>> >>
>> > >>>> >>> >> Regards,
>> > >>>> >>> >> Tommaso
>> > >>>> >>> >>
>> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> > >>>> >>> >> <jp...@gmail.com> ha scritto:
>> > >>>> >>> >> >
>> > >>>> >>> >> > Hi Noble,
>> > >>>> >>> >> >
>> > >>>> >>> >> > No it hasn't created yet.
>> > >>>> >>> >> >
>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>> noble.paul@gmail.com> wrote:
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>> > >>>> >>> >> > >
>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>> david.w.smiley@gmail.com> wrote:
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> > >>>> >>> >> > > > I will work on some documentation for it this week --
>> SOLR-13129
>> > >>>> >>> >> > > >
>> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>> jan.asf@cominvent.com> wrote:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I don't think it is critical for this to be a
>> blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an
>> ooold bug.
>> > >>>> >>> >> > > >> I think we should simply remove the buffering
>> feature in the UI and replace it with an error message popup or something.
>> > >>>> >>> >> > > >> I'll try to take a look next week.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> --
>> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
>> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long
>> as there is a reasonable time horizon for the issue being resolved I'm +1
>> on making it a blocker. I'm not familiar enough with the UI code to help
>> either unfortunately.
>> > >>>> >>> >> > > >>
>> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker
>> once before... And it's actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it
>> <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g>
>> rather than browsing away or closing the window, not knowing that it's
>> silently pumping out requests after showing an error... would completely
>> hose a node, and until they tracked down the source of the requests, (hope
>> he didn't go home) it would be impossible to resolve...
>> > >>>> >>> >> > > >>>
>> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>> jpountz@gmail.com> wrote:
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its
>> own, I'd rather not
>> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it
>> since this isn't a new
>> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that
>> has affected Solr
>> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI
>> code at all, but
>> > >>>> >>> >> > > >>>> maybe this is something that could get fixed
>> before we build a RC?
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>>
>> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> > >>>> >>> >> > > >>>> >
>> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Cool,
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> I am working on giving my best release time
>> guess as possible on the FOSDEM conference!
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> Uwe
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> -----
>> > >>>> >>> >> > > >>>> >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
>> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>> > >>>> >>> >> > > >>>> >>
>> > >>>> >>> >> > > >>>> >> > -----Original Message-----
>> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting
>> on the week of February 4th.
>> > >>>> >>> >> > > >>>> >> >
>> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>> jim.ferenczi@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Hi,
>> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to
>> start on releasing 8.0. The branch is
>> > >>>> >>> >> > > >>>> >> > already created so we can start the process
>> anytime now. Unless there are
>> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature
>> freeze next week in order to build the
>> > >>>> >>> >> > > >>>> >> > first candidate the week after.
>> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think
>> we can handle both with Alan so
>> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to
>> start the release process or if there
>> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > >
>> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan
>> Woodward <ro...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > a écrit :
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various
>> deprecations on the new master
>> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m
>> going to need some assistance for
>> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear
>> what to do.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA,
>> one for lucene and one for Solr,
>> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to
>> be removed in each one.  I’ll create
>> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against,
>> and push the changes I’ve already
>> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual
>> JIRA issues for any changes that
>> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received,
>> particularly for the Solr deprecations
>> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar
>> with.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>> romseygeek@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7
>> release at the same time as 8.0, to
>> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So
>> let’s keep those jobs enabled
>> > >>>> >>> >> > > >>>> >> > for now.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Hi,
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to
>> Jenkins once I have some time
>> > >>>> >>> >> > > >>>> >> > later today.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with
>> branch_7x? Should we stop using it
>> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use
>> branch_7_6 only for bugfixes), or
>> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7?
>> In the latter case I would keep
>> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Uwe
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> -----
>> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
>> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit…
>> I’ve just created a branch for 8x
>> > >>>> >>> >> > > >>>> >> > from master, and am in the process of
>> updating the master branch to version
>> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in
>> the 8.0 release should also be
>> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze,
>> as I know there are still some
>> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it
>> should let us clean up master by
>> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible,
>> and give us an idea of any
>> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>> david.w.smiley@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> January.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>> sg.online.email@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January
>> soon as there is an enhancement
>> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our
>> hands on.
>> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thx
>> > >>>> >>> >> > > >>>> >> > >> SG
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David
>> Smiley
>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this
>> filter:   project in (SOLR, LUCENE) AND
>> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and
>> fixVersion = "master (8.0)"
>> > >>>> >>> >> > > >>>> >> > >>    click here:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> >
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > >>>> >>> >> > > >>>> >> >
>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > >>>> >>> >> > > >>>> >> >
>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to
>> work on those issues not yet
>> > >>>> >>> >> > > >>>> >> > assigned.
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien
>> Grand <jp...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> +1
>> > >>>> >>> >> > > >>>> >> > >>
>> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan
>> Woodward
>> > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Hi all,
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks
>> Nick!) we should think about
>> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to
>> 9.0.  I’ll volunteer to create the
>> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we
>> should have some time to
>> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover
>> anything that still needs to be done
>> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process
>> next year.
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra
>> Targett <ca...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > wrote:
>> > >>>> >>> >> > > >>>> >> > >> >
>> > >>>> >>> >> > > >>>> >> > >> > 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
>> > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>> > >>>> >>> >> > > >>>> >> > 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
>> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>> > >>>> >>> >> > > >>>> >> > >> >> >>
>> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM
>> Nicholas Knize
>> > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>> > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <er...@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
>> > >>>> >>> >> > > >>>> >> > <da...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à
>> 10:36, jim ferenczi
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <er...@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
>> > >>>> >>> >> > > >>>> >> > <ca...@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
>> > >>>> >>> >> > > >>>> >> > <ji...@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
>> > >>>> >>> >> > > >>>> >> > <da...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>> > >>>> >>> >> > > >>>> >> > <jp...@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
>> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 thi
>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Not quite - the plan is to remove things entirely in 9.0, but we may need to back port some extra deprecations to 8x.  We don’t necessarily need them in 8.0 though - we can deprecate in 8.1 and remove in 9 without any problems.  I opened the issues to ensure that we didn’t keep carrying deprecated code through any further releases.

> On 7 Feb 2019, at 06:43, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
> 
> I want to ensure people are aware of two issues "Remove deprecated code in master" that Alan filed:
> 
> https://issues.apache.org/jira/browse/SOLR-13138 <https://issues.apache.org/jira/browse/SOLR-13138>
> https://issues.apache.org/jira/browse/LUCENE-8638 <https://issues.apache.org/jira/browse/LUCENE-8638>
> There's a "master-deprecations" branch as well.
> 
> Although both issues are marked "master (9.0)", I think the intent is actually 8.0 so that we are finally rid of the deprecated code?
> 
> ~ David
> 
> On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> I'm keeping any eye on the builds this weekend but all indications are
> no issues so far.
> 
> Kevin Risden
> 
> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
> >
> > Nick, this change seems to be causing test failures. Can you have a look?
> >
> > See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console <https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console>.
> >
> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> wrote:
> > >
> > > Thank you Jim. LUCENE-8669 has been merged.
> > >
> > > - Nick
> > >
> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
> > >>
> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> > >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> > >>
> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> a écrit :
> > >>>
> > >>> Hey Jim,
> > >>>
> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 <https://issues.apache.org/jira/browse/LUCENE-8669> along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > >>>
> > >>> On Wed, Jan 30, 2019 at 1:07 PM
> Kevin Risden <krisden@apache.org <ma...@apache.org>> wrote:
> > >>>>
> > >>>> Jim,
> > >>>>
> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > >>>> currently under review.
> > >>>>
> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> > >>>> feel this should make it into 8.0 or not.
> > >>>>
> > >>>> Kevin Risden
> > >>>>
> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >
> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665 <https://issues.apache.org/jira/browse/LUCENE-8665>).
> > >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
> > >>>> >
> > >>>> >
> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>> a écrit :
> > >>>> >>
> > >>>> >> Hi,
> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> > >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> > >>>> >>
> > >>>> >> No new features may be committed to the branch.
> > >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> > >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> > >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> > >>>> >>
> > >>>> >>
> > >>>> >> Thanks,
> > >>>> >> Jim
> > >>>> >>
> > >>>> >>
> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
> > >>>> >>>
> > >>>> >>> sure, thanks Jim!
> > >>>> >>>
> > >>>> >>> Tommaso
> > >>>> >>>
> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > >>>> >>> <jim.ferenczi@gmail.com <ma...@gmail.com>> ha scritto:
> > >>>> >>> >
> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> > >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> > >>>> >>> > early next week. Would that work for you ?
> > >>>> >>> >
> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <tommaso.teofili@gmail.com <ma...@gmail.com>> a écrit :
> > >>>> >>> >>
> > >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659 <https://issues.apache.org/jira/browse/LUCENE-8659>
> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> > >>>> >>> >>
> > >>>> >>> >> Regards,
> > >>>> >>> >> Tommaso
> > >>>> >>> >>
> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > >>>> >>> >> <jpountz@gmail.com <ma...@gmail.com>> ha scritto:
> > >>>> >>> >> >
> > >>>> >>> >> > Hi Noble,
> > >>>> >>> >> >
> > >>>> >>> >> > No it hasn't created yet.
> > >>>> >>> >> >
> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <noble.paul@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > >
> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
> > >>>> >>> >> > >
> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >
> > >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 <https://issues.apache.org/jira/browse/SOLR-12768> (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
> > >>>> >>> >> > > >
> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <jan.asf@cominvent.com <ma...@cominvent.com>> wrote:
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > >>>> >>> >> > > >> I'll try to take a look next week.
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> --
> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com <http://www.cominvent.com/>
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com <ma...@gmail.com>>:
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>
> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g> rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > >>>> >>> >> > > >>>
> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> > >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>> >
> > >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
> > >>>> >>> >> > > >>>> >
> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> Cool,
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> Uwe
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> -----
> > >>>> >>> >> > > >>>> >> Uwe Schindler
> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de <http://www.thetaphi.de/>
> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> > -----Original Message-----
> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> > >>>> >>> >> > > >>>> >> >
> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > >>>> >>> >> > > >>>> >> >
> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > > Hi,
> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
> > >>>> >>> >> > > >>>> >> > first candidate the week after.
> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > a écrit :
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > >>>> >>> >> > > >>>> >> > for now.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Hi,
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> > >>>> >>> >> > > >>>> >> > later today.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Uwe
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> -----
> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de <http://www.thetaphi.de/>
> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org <ma...@lucene.apache.org>
> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> January.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Thx
> > >>>> >>> >> > > >>>> >> > >> SG
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >>>> >>> >> > > >>>> >> > >>    click here:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
> > >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
> > >>>> >>> >> > > >>>> >> > assigned.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> +1
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > >>>> >>> >> > > >>>> >> > <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > Hi all,
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > 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
> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
> > >>>> >>> >> > > >>>> >> > 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
> > >>>> >>> >> > > >>>> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
> > >>>> >>> >> > > >>>> >> > >> >> >>
> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > >>>> >>> >> > > >>>> >> > <nknize@gmail.com <ma...@gmail.com>> 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
> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@gmail.com>> 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
> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <casstargett@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> I find 9 open blockers for 8.0:
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> Hi,
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 release:
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
> > >>>> >>> >> > > >>>> >> > 7075?jql=(project%3D%22Lucene%20-
> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
> > >>>> >>> >> > > >>>> >> > r%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
> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
> > >>>> >>> >> > > >>>> >> > 12720?jql=(project%3D%22Lucene%20-
> > >>>> >>> >> > > >>>> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > >>>> >>> >> > > >>>> >> > <jim.ferenczi@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <erickerickson@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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
> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
> > >>>> >>> >> > > >>>> >> > <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir
> > >>>> >>> >> > > >>>> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [2]
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [3]
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [4]
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [5]
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [7]
> > >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/browse/LUCENE-8134 <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 thi
> -- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

I want to ensure people are aware of two issues "Remove deprecated code in
master" that Alan filed:

https://issues.apache.org/jira/browse/SOLR-13138
https://issues.apache.org/jira/browse/LUCENE-8638
There's a "master-deprecations" branch as well.

Although both issues are marked "master (9.0)", I think the intent is
actually 8.0 so that we are finally rid of the deprecated code?

~ David

On Sat, Feb 2, 2019 at 7:25 AM Kevin Risden <kr...@apache.org> wrote:

> SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
> I'm keeping any eye on the builds this weekend but all indications are
> no issues so far.
>
> Kevin Risden
>
> On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
> >
> > Nick, this change seems to be causing test failures. Can you have a look?
> >
> > See eg.
> https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
> >
> > On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> > >
> > > Thank you Jim. LUCENE-8669 has been merged.
> > >
> > > - Nick
> > >
> > > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com>
> wrote:
> > >>
> > >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
> first RC when your patch is merged.
> > >> Kevin, this looks like a big change so I am not sure if it's a good
> idea to rush this in for 8.0. Would it be safer to target another version
> in order to take some time to ensure that it's not breaking anything ? I
> guess that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
> > >>
> > >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a
> écrit :
> > >>>
> > >>> Hey Jim,
> > >>>
> > >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669
> along with a pretty straightforward patch. This is a critical one that I
> think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> > >>>
> > >>> On Wed, Jan 30, 2019 at 1:07 PM
> Kevin Risden <kr...@apache.org> wrote:
> > >>>>
> > >>>> Jim,
> > >>>>
> > >>>> Since 7.7 needs to be released before 8.0 does that leave time to
> get
> > >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> > >>>> currently under review.
> > >>>>
> > >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if
> others
> > >>>> feel this should make it into 8.0 or not.
> > >>>>
> > >>>> Kevin Risden
> > >>>>
> > >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <
> jim.ferenczi@gmail.com> wrote:
> > >>>> >
> > >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x
> because we don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > >>>> > Since we want to release 7.7 first I created the Jenkins job for
> this version only and will build the first candidate for this version later
> this week if there are no objection.
> > >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
> > >>>> >
> > >>>> >
> > >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <
> jim.ferenczi@gmail.com> a écrit :
> > >>>> >>
> > >>>> >> Hi,
> > >>>> >> Hearing no objection I created the branches for 8.0 and 7.7.
> I'll now create the Jenkins tasks for these versions, Uwe can you also add
> them to the Policeman's Jenkins job ?
> > >>>> >> This also means that the feature freeze phase has started for
> both versions (7.7 and 8.0):
> > >>>> >>
> > >>>> >> No new features may be committed to the branch.
> > >>>> >> Documentation patches, build patches and serious bug fixes may
> be committed to the branch. However, you should submit all patches you want
> to commit to Jira first to give others the chance to review and possibly
> vote against the patch. Keep in mind that it is our main intention to keep
> the branch as stable as possible.
> > >>>> >> All patches that are intended for the branch should first be
> committed to the unstable branch, merged into the stable branch, and then
> into the current release branch.
> > >>>> >> Normal unstable and stable branch development may continue as
> usual. However, if you plan to commit a big change to the unstable branch
> while the branch feature freeze is in effect, think twice: can't the
> addition wait a couple more days? Merges of bug fixes into the branch may
> become more difficult.
> > >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker"
> will delay a release candidate build.
> > >>>> >>
> > >>>> >>
> > >>>> >> Thanks,
> > >>>> >> Jim
> > >>>> >>
> > >>>> >>
> > >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >>>> >>>
> > >>>> >>> sure, thanks Jim!
> > >>>> >>>
> > >>>> >>> Tommaso
> > >>>> >>>
> > >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> > >>>> >>> <ji...@gmail.com> ha scritto:
> > >>>> >>> >
> > >>>> >>> > Go ahead Tommaso the branch is not created yet.
> > >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
> wednesday and to announce the feature freeze the same day.
> > >>>> >>> > For blocker issues that are still open this leaves another
> week to work on a patch and we can update the status at the end of the week
> in order to decide if we can start the first build candidate
> > >>>> >>> > early next week. Would that work for you ?
> > >>>> >>> >
> > >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> > >>>> >>> >>
> > >>>> >>> >> I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> > >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still
> time.
> > >>>> >>> >>
> > >>>> >>> >> Regards,
> > >>>> >>> >> Tommaso
> > >>>> >>> >>
> > >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> > >>>> >>> >> <jp...@gmail.com> ha scritto:
> > >>>> >>> >> >
> > >>>> >>> >> > Hi Noble,
> > >>>> >>> >> >
> > >>>> >>> >> > No it hasn't created yet.
> > >>>> >>> >> >
> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
> noble.paul@gmail.com> wrote:
> > >>>> >>> >> > >
> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
> > >>>> >>> >> > >
> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> > >>>> >>> >> > > >
> > >>>> >>> >> > > > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > >>>> >>> >> > > > I will work on some documentation for it this week --
> SOLR-13129
> > >>>> >>> >> > > >
> > >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
> jan.asf@cominvent.com> wrote:
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> I don't think it is critical for this to be a blocker
> for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold
> bug.
> > >>>> >>> >> > > >> I think we should simply remove the buffering feature
> in the UI and replace it with an error message popup or something.
> > >>>> >>> >> > > >> I'll try to take a look next week.
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> --
> > >>>> >>> >> > > >> Jan Høydahl, search solution architect
> > >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> I think the UI is an important Solr feature. As long
> as there is a reasonable time horizon for the issue being resolved I'm +1
> on making it a blocker. I'm not familiar enough with the UI code to help
> either unfortunately.
> > >>>> >>> >> > > >>
> > >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
> gus.heck@gmail.com> wrote:
> > >>>> >>> >> > > >>>
> > >>>> >>> >> > > >>> It looks like someone tried to make it a blocker
> once before... And it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it
> <https://maps.google.com/?q=dow+open+and+forgets+about+it&entry=gmail&source=g>
> rather than browsing away or closing the window, not knowing that it's
> silently pumping out requests after showing an error... would completely
> hose a node, and until they tracked down the source of the requests, (hope
> he didn't go home) it would be impossible to resolve...
> > >>>> >>> >> > > >>>
> > >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
> jpountz@gmail.com> wrote:
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>> Releasing a new major is very challenging on its
> own, I'd rather not
> > >>>> >>> >> > > >>>> call it a blocker and delay the release for it
> since this isn't a new
> > >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has
> affected Solr
> > >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI
> code at all, but
> > >>>> >>> >> > > >>>> maybe this is something that could get fixed before
> we build a RC?
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>>
> > >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
> gus.heck@gmail.com> wrote:
> > >>>> >>> >> > > >>>> >
> > >>>> >>> >> > > >>>> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > >>>> >>> >> > > >>>> >
> > >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
> uwe@thetaphi.de> wrote:
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> Cool,
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> I am working on giving my best release time
> guess as possible on the FOSDEM conference!
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> Uwe
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> -----
> > >>>> >>> >> > > >>>> >> Uwe Schindler
> > >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> > >>>> >>> >> > > >>>> >> http://www.thetaphi.de
> > >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
> > >>>> >>> >> > > >>>> >>
> > >>>> >>> >> > > >>>> >> > -----Original Message-----
> > >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> > >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> > >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> > >>>> >>> >> > > >>>> >> >
> > >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on
> the week of February 4th.
> > >>>> >>> >> > > >>>> >> >
> > >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > > Hi,
> > >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start
> on releasing 8.0. The branch is
> > >>>> >>> >> > > >>>> >> > already created so we can start the process
> anytime now. Unless there are
> > >>>> >>> >> > > >>>> >> > objections I'd like to start the feature
> freeze next week in order to build the
> > >>>> >>> >> > > >>>> >> > first candidate the week after.
> > >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we
> can handle both with Alan so
> > >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start
> the release process or if there
> > >>>> >>> >> > > >>>> >> > are any blockers left ;).
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > >
> > >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward
> <ro...@gmail.com>
> > >>>> >>> >> > > >>>> >> > a écrit :
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various
> deprecations on the new master
> > >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m
> going to need some assistance for
> > >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear
> what to do.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA,
> one for lucene and one for Solr,
> > >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be
> removed in each one.  I’ll create
> > >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and
> push the changes I’ve already
> > >>>> >>> >> > > >>>> >> > done there.  We can then create individual
> JIRA issues for any changes that
> > >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> All assistance gratefully received,
> particularly for the Solr deprecations
> > >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar
> with.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
> romseygeek@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7
> release at the same time as 8.0, to
> > >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So
> let’s keep those jobs enabled
> > >>>> >>> >> > > >>>> >> > for now.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
> uwe@thetaphi.de> wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Hi,
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to
> Jenkins once I have some time
> > >>>> >>> >> > > >>>> >> > later today.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> The question: How to proceed with
> branch_7x? Should we stop using it
> > >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use
> branch_7_6 only for bugfixes), or
> > >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7?
> In the latter case I would keep
> > >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Uwe
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> -----
> > >>>> >>> >> > > >>>> >> > >> Uwe Schindler
> > >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> > >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
> > >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> > >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> > >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
> > >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve
> just created a branch for 8x
> > >>>> >>> >> > > >>>> >> > from master, and am in the process of updating
> the master branch to version
> > >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the
> 8.0 release should also be
> > >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze,
> as I know there are still some
> > >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it
> should let us clean up master by
> > >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible,
> and give us an idea of any
> > >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> January.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
> sg.online.email@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January
> soon as there is an enhancement
> > >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our
> hands on.
> > >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Thx
> > >>>> >>> >> > > >>>> >> > >> SG
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:
>  project in (SOLR, LUCENE) AND
> > >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and
> fixVersion = "master (8.0)"
> > >>>> >>> >> > > >>>> >> > >>    click here:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > >>>> >>> >> > > >>>> >> >
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >>>> >>> >> > > >>>> >> >
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work
> on those issues not yet
> > >>>> >>> >> > > >>>> >> > assigned.
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien
> Grand <jp...@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> +1
> > >>>> >>> >> > > >>>> >> > >>
> > >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan
> Woodward
> > >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > Hi all,
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks
> Nick!) we should think about
> > >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to
> 9.0.  I’ll volunteer to create the
> > >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we
> should have some time to
> > >>>> >>> >> > > >>>> >> > clean up the master branch and uncover
> anything that still needs to be done
> > >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process
> next year.
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra
> Targett <ca...@gmail.com>
> > >>>> >>> >> > > >>>> >> > wrote:
> > >>>> >>> >> > > >>>> >> > >> >
> > >>>> >>> >> > > >>>> >> > >> > 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
> > >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> > >>>> >>> >> > > >>>> >> > 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
> > >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
> > >>>> >>> >> > > >>>> >> > >> >> >>
> > >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM
> Nicholas Knize
> > >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
> > >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
> > >>>> >>> >> > > >>>> >> > <ji...@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
> > >>>> >>> >> > > >>>> >> > <ca...@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
> > >>>> >>> >> > > >>>> >> > <ji...@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
> > >>>> >>> >> > > >>>> >> > <ca...@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
> > >>>> >>> >> > > >>>> >> > <er...@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
> > >>>> >>> >> > > >>>> >> > <da...@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
> > >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
> > >>>> >>> >> > > >>>> >> > r%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
> > >>>> >>> >> > > >>>> >> > <jp...@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
> > >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
> > >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> > >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à
> 10:36, jim ferenczi
> > >>>> >>> >> > > >>>> >> > <ji...@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
> > >>>> >>> >> > > >>>> >> > <er...@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
> > >>>> >>> >> > > >>>> >> > <ca...@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
> > >>>> >>> >> > > >>>> >> > <ji...@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
> > >>>> >>> >> > > >>>> >> > <da...@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
> > >>>> >>> >> > > >>>> >> > <jp...@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
> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
> > >>>> >>> >> > > >>>> >> > <jp...@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
> > >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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 thi

-- 
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Kevin Risden <kr...@apache.org>]

SOLR-9515 - Hadoop 3 upgrade has been merged to master, 8x, and 8.0.
I'm keeping any eye on the builds this weekend but all indications are
no issues so far.

Kevin Risden

On Fri, Feb 1, 2019 at 2:46 AM Adrien Grand <jp...@gmail.com> wrote:
>
> Nick, this change seems to be causing test failures. Can you have a look?
>
> See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.
>
> On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
> >
> > Thank you Jim. LUCENE-8669 has been merged.
> >
> > - Nick
> >
> > On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
> >>
> >> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
> >> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
> >>
> >> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
> >>>
> >>> Hey Jim,
> >>>
> >>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
> >>>
> >>> On Wed, Jan 30, 2019 at 1:07 PM
Kevin Risden <kr...@apache.org> wrote:
> >>>>
> >>>> Jim,
> >>>>
> >>>> Since 7.7 needs to be released before 8.0 does that leave time to get
> >>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> >>>> currently under review.
> >>>>
> >>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> >>>> feel this should make it into 8.0 or not.
> >>>>
> >>>> Kevin Risden
> >>>>
> >>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
> >>>> >
> >>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> >>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> >>>> > I'll restore the version bump for 8.0 when 7.7 is out.
> >>>> >
> >>>> >
> >>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
> >>>> >>
> >>>> >> Hi,
> >>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
> >>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
> >>>> >>
> >>>> >> No new features may be committed to the branch.
> >>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
> >>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
> >>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
> >>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
> >>>> >>
> >>>> >>
> >>>> >> Thanks,
> >>>> >> Jim
> >>>> >>
> >>>> >>
> >>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
> >>>> >>>
> >>>> >>> sure, thanks Jim!
> >>>> >>>
> >>>> >>> Tommaso
> >>>> >>>
> >>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> >>>> >>> <ji...@gmail.com> ha scritto:
> >>>> >>> >
> >>>> >>> > Go ahead Tommaso the branch is not created yet.
> >>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> >>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> >>>> >>> > early next week. Would that work for you ?
> >>>> >>> >
> >>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
> >>>> >>> >>
> >>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> >>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >>>> >>> >>
> >>>> >>> >> Regards,
> >>>> >>> >> Tommaso
> >>>> >>> >>
> >>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> >>>> >>> >> <jp...@gmail.com> ha scritto:
> >>>> >>> >> >
> >>>> >>> >> > Hi Noble,
> >>>> >>> >> >
> >>>> >>> >> > No it hasn't created yet.
> >>>> >>> >> >
> >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> >>>> >>> >> > >
> >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
> >>>> >>> >> > >
> >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> >>>> >>> >> > > >
> >>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> >>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
> >>>> >>> >> > > >
> >>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> >>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> >>>> >>> >> > > >> I'll try to take a look next week.
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> --
> >>>> >>> >> > > >> Jan Høydahl, search solution architect
> >>>> >>> >> > > >> Cominvent AS - www.cominvent.com
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> >>>> >>> >> > > >>>
> >>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> >>>> >>> >> > > >>>
> >>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> >>>> >>> >> > > >>>>
> >>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
> >>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
> >>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
> >>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> >>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
> >>>> >>> >> > > >>>>
> >>>> >>> >> > > >>>>
> >>>> >>> >> > > >>>>
> >>>> >>> >> > > >>>>
> >>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >>>> >>> >> > > >>>> >
> >>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> >>>> >>> >> > > >>>> >
> >>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >>>> >>> >> > > >>>> >>
> >>>> >>> >> > > >>>> >> Cool,
> >>>> >>> >> > > >>>> >>
> >>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> >>>> >>> >> > > >>>> >>
> >>>> >>> >> > > >>>> >> Uwe
> >>>> >>> >> > > >>>> >>
> >>>> >>> >> > > >>>> >> -----
> >>>> >>> >> > > >>>> >> Uwe Schindler
> >>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> >>>> >>> >> > > >>>> >> http://www.thetaphi.de
> >>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
> >>>> >>> >> > > >>>> >>
> >>>> >>> >> > > >>>> >> > -----Original Message-----
> >>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> >>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> >>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> >>>> >>> >> > > >>>> >> >
> >>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >>>> >>> >> > > >>>> >> >
> >>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >
> >>>> >>> >> > > >>>> >> > > Hi,
> >>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> >>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
> >>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
> >>>> >>> >> > > >>>> >> > first candidate the week after.
> >>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> >>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
> >>>> >>> >> > > >>>> >> > are any blockers left ;).
> >>>> >>> >> > > >>>> >> > >
> >>>> >>> >> > > >>>> >> > >
> >>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >>>> >>> >> > > >>>> >> > a écrit :
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
> >>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> >>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> >>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> >>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> >>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
> >>>> >>> >> > > >>>> >> > are more involved than just deleting code.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> >>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> >>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> >>>> >>> >> > > >>>> >> > for now.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> Hi,
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> >>>> >>> >> > > >>>> >> > later today.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> >>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> >>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> >>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> Uwe
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> -----
> >>>> >>> >> > > >>>> >> > >> Uwe Schindler
> >>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> >>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
> >>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> >>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
> >>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
> >>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
> >>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
> >>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
> >>>> >>> >> > > >>>> >> > replacement work that needs to be done.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> January.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> >>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
> >>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> Thx
> >>>> >>> >> > > >>>> >> > >> SG
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> >>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >>>> >>> >> > > >>>> >> > >>    click here:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
> >>>> >>> >> > > >>>> >> > assigned.
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> +1
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
> >>>> >>> >> > > >>>> >> > >> >
> >>>> >>> >> > > >>>> >> > >> > Hi all,
> >>>> >>> >> > > >>>> >> > >> >
> >>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> >>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
> >>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
> >>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
> >>>> >>> >> > > >>>> >> > >> >
> >>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> >>>> >>> >> > > >>>> >> > wrote:
> >>>> >>> >> > > >>>> >> > >> >
> >>>> >>> >> > > >>>> >> > >> > 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
> >>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> >>>> >>> >> > > >>>> >> > 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
> >>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
> >>>> >>> >> > > >>>> >> > >> >> >>
> >>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
> >>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
> >>>> >>> >> > > >>>> >> > <ji...@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
> >>>> >>> >> > > >>>> >> > <ca...@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
> >>>> >>> >> > > >>>> >> > <ji...@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
> >>>> >>> >> > > >>>> >> > <ca...@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
> >>>> >>> >> > > >>>> >> > <er...@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
> >>>> >>> >> > > >>>> >> > <da...@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
> >>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
> >>>> >>> >> > > >>>> >> > r%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
> >>>> >>> >> > > >>>> >> > <jp...@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
> >>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
> >>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >>>> >>> >> > > >>>> >> > <ji...@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
> >>>> >>> >> > > >>>> >> > <er...@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
> >>>> >>> >> > > >>>> >> > <ca...@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
> >>>> >>> >> > > >>>> >> > <ji...@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
> >>>> >>> >> > > >>>> >> > <da...@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
> >>>> >>> >> > > >>>> >> > <jp...@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
> >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
> >>>> >>> >> > > >>>> >> > <jp...@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
> >>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
> >>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> >>>> >>> >> > > >>>> >> > help@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
> >>>> >>> >> > > >>>> >> > ----------
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> >>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> >>>> >>> >> > > >>>> >> > help@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-
> >>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> >>>> >>> >> > > >>>> >> > help@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-
> >>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >>>> >>> >> > > >>>> >> > help@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
> >>>> >>> >> > > >>>> >> > >> >> >>> --
> >>>> >>> >> > > >>>> >> > >> >> >>>
> >>>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >>>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >>>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
> >>>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> >>
> >>>> >>> >> > > >>>> >> > >> >
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> --
> >>>> >>> >> > > >>>> >> > >> Adrien
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> ---------------------------------------------------------------------
> >>>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> --
> >>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >>>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
> >>>> >>> >> > > >>>> >> > >>
> >>>> >>> >> > > >>>> >> > >> --
> >>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >>>> >>> >> > > >>>> >> >
> >
> > --
> >
> > Nicholas Knize, Ph.D., GISP
> > Geospatial Software Guy  |  Elasticsearch
> > Apache Lucene PMC Member and Committer
> > nknize@apache.org
>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

Nick, this change seems to be causing test failures. Can you have a look?

See eg. https://builds.apache.org/job/Lucene-Solr-SmokeRelease-8.x/15/console.

On Fri, Feb 1, 2019 at 12:27 AM Nicholas Knize <nk...@gmail.com> wrote:
>
> Thank you Jim. LUCENE-8669 has been merged.
>
> - Nick
>
> On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:
>>
>> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first RC when your patch is merged.
>> Kevin, this looks like a big change so I am not sure if it's a good idea to rush this in for 8.0. Would it be safer to target another version in order to take some time to ensure that it's not breaking anything ? I guess that your concern is that a change like this should happen in a major version but I wonder if it's worth the risk. I don't know this part of the code and the implications of such a change so I let you decide what we should do here but let's not delay the release if we realize that this change requires more than a few days to be merged.
>>
>> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>>>
>>> Hey Jim,
>>>
>>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a pretty straightforward patch. This is a critical one that I think needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>>
>>> On Wed, Jan 30, 2019 at 1:07 PM Kevin Risden <kr...@apache.org> wrote:
>>>>
>>>> Jim,
>>>>
>>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>>> currently under review.
>>>>
>>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>>> feel this should make it into 8.0 or not.
>>>>
>>>> Kevin Risden
>>>>
>>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>>>> >
>>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
>>>> > Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
>>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>>> >
>>>> >
>>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>>> >>
>>>> >> Hi,
>>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>>>> >> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>>> >>
>>>> >> No new features may be committed to the branch.
>>>> >> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>>>> >> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>>>> >> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>>> >>
>>>> >>
>>>> >> Thanks,
>>>> >> Jim
>>>> >>
>>>> >>
>>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> >>>
>>>> >>> sure, thanks Jim!
>>>> >>>
>>>> >>> Tommaso
>>>> >>>
>>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>> >>> <ji...@gmail.com> ha scritto:
>>>> >>> >
>>>> >>> > Go ahead Tommaso the branch is not created yet.
>>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>>> >>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>>> >>> > early next week. Would that work for you ?
>>>> >>> >
>>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>>> >>> >>
>>>> >>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>>> >>> >>
>>>> >>> >> Regards,
>>>> >>> >> Tommaso
>>>> >>> >>
>>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>>> >>> >> <jp...@gmail.com> ha scritto:
>>>> >>> >> >
>>>> >>> >> > Hi Noble,
>>>> >>> >> >
>>>> >>> >> > No it hasn't created yet.
>>>> >>> >> >
>>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>>> >>> >> > >
>>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>>> >>> >> > >
>>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>>> >>> >> > > >
>>>> >>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>>> >>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>>>> >>> >> > > >
>>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>>> >>> >> > > >>
>>>> >>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>>> >>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>>> >>> >> > > >> I'll try to take a look next week.
>>>> >>> >> > > >>
>>>> >>> >> > > >> --
>>>> >>> >> > > >> Jan Høydahl, search solution architect
>>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>>>> >>> >> > > >>
>>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>>> >>> >> > > >>
>>>> >>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>>> >>> >> > > >>
>>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>> >>> >> > > >>>
>>>> >>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>> >>> >> > > >>>
>>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>> >>> >> > > >>>>
>>>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>>>> >>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>> >>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>>>> >>> >> > > >>>>
>>>> >>> >> > > >>>>
>>>> >>> >> > > >>>>
>>>> >>> >> > > >>>>
>>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>> >>> >> > > >>>> >
>>>> >>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>> >>> >> > > >>>> >
>>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> >>> >> > > >>>> >>
>>>> >>> >> > > >>>> >> Cool,
>>>> >>> >> > > >>>> >>
>>>> >>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>> >>> >> > > >>>> >>
>>>> >>> >> > > >>>> >> Uwe
>>>> >>> >> > > >>>> >>
>>>> >>> >> > > >>>> >> -----
>>>> >>> >> > > >>>> >> Uwe Schindler
>>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>>> >>> >> > > >>>> >>
>>>> >>> >> > > >>>> >> > -----Original Message-----
>>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>>> >>> >> > > >>>> >> >
>>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>> >>> >> > > >>>> >> >
>>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >
>>>> >>> >> > > >>>> >> > > Hi,
>>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>> >>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>>> >>> >> > > >>>> >> > first candidate the week after.
>>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>>>> >>> >> > > >>>> >> > are any blockers left ;).
>>>> >>> >> > > >>>> >> > >
>>>> >>> >> > > >>>> >> > >
>>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>> >>> >> > > >>>> >> > a écrit :
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>> >>> >> > > >>>> >> > for now.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> Hi,
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>> >>> >> > > >>>> >> > later today.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> Uwe
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> -----
>>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>> >>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> January.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> Thx
>>>> >>> >> > > >>>> >> > >> SG
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>> >>> >> > > >>>> >> > >>    click here:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>> >>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> >>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>>> >>> >> > > >>>> >> > assigned.
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> +1
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>>> >>> >> > > >>>> >> > >> >
>>>> >>> >> > > >>>> >> > >> > Hi all,
>>>> >>> >> > > >>>> >> > >> >
>>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>>>> >>> >> > > >>>> >> > >> >
>>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>> >>> >> > > >>>> >> > wrote:
>>>> >>> >> > > >>>> >> > >> >
>>>> >>> >> > > >>>> >> > >> > 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
>>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>>> >>> >> > > >>>> >> > 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
>>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>>> >>> >> > > >>>> >> > >> >> >>
>>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>>>> >>> >> > > >>>> >> > <ji...@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
>>>> >>> >> > > >>>> >> > <ca...@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
>>>> >>> >> > > >>>> >> > <ji...@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
>>>> >>> >> > > >>>> >> > <ca...@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
>>>> >>> >> > > >>>> >> > <er...@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
>>>> >>> >> > > >>>> >> > <da...@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
>>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>>>> >>> >> > > >>>> >> > r%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
>>>> >>> >> > > >>>> >> > <jp...@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
>>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>> >>> >> > > >>>> >> > <ji...@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
>>>> >>> >> > > >>>> >> > <er...@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
>>>> >>> >> > > >>>> >> > <ca...@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
>>>> >>> >> > > >>>> >> > <ji...@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
>>>> >>> >> > > >>>> >> > <da...@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
>>>> >>> >> > > >>>> >> > <jp...@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
>>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>>>> >>> >> > > >>>> >> > <jp...@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
>>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
>>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>>>> >>> >> > > >>>> >> > ----------
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>>> >>> >> > > >>>> >> > help@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-
>>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>>> >>> >> > > >>>> >> > help@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-
>>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>>> >>> >> > > >>>> >> > >> >> >>> --
>>>> >>> >> > > >>>> >> > >> >> >>>
>>>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>>>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> >>
>>>> >>> >> > > >>>> >> > >> >
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> --
>>>> >>> >> > > >>>> >> > >> Adrien
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> ---------------------------------------------------------------------
>>>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>> >> > > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> --
>>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>>> >>> >> > > >>>> >> > >>
>>>> >>> >> > > >>>> >> > >> --
>>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>> >>> >> > > >>>> >> >
>
> --
>
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy  |  Elasticsearch
> Apache Lucene PMC Member and Committer
> nknize@apache.org



--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Nicholas Knize <nk...@gmail.com>]

Thank you Jim. LUCENE-8669
<https://issues.apache.org/jira/browse/LUCENE-8669>has been merged.

- Nick

On Wed, Jan 30, 2019 at 1:36 PM jim ferenczi <ji...@gmail.com> wrote:

> Sure Nick, I am not aware of other blockers for 7.7 so I'll start the
> first RC when your patch is merged.
> Kevin, this looks like a big change so I am not sure if it's a good idea
> to rush this in for 8.0. Would it be safer to target another version in
> order to take some time to ensure that it's not breaking anything ? I guess
> that your concern is that a change like this should happen in a major
> version but I wonder if it's worth the risk. I don't know this part of the
> code and the implications of such a change so I let you decide what we
> should do here but let's not delay the release if we realize that this
> change requires more than a few days to be merged.
>
> Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :
>
>> Hey Jim,
>>
>> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along
>> with a pretty straightforward patch. This is a critical one that I think
>> needs to be in for 7.7 and 8.0. Can I set this as a blocker?
>>
>> On Wed, Jan 30, 2019 at 1:07 PM Kevin Risden <kr...@apache.org> wrote:
>>
>>> Jim,
>>>
>>> Since 7.7 needs to be released before 8.0 does that leave time to get
>>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>>> currently under review.
>>>
>>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>>> feel this should make it into 8.0 or not.
>>>
>>> Kevin Risden
>>>
>>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
>>> wrote:
>>> >
>>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
>>> don't handle two concurrent releases in our tests (
>>> https://issues.apache.org/jira/browse/LUCENE-8665).
>>> > Since we want to release 7.7 first I created the Jenkins job for this
>>> version only and will build the first candidate for this version later this
>>> week if there are no objection.
>>> > I'll restore the version bump for 8.0 when 7.7 is out.
>>> >
>>> >
>>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com>
>>> a écrit :
>>> >>
>>> >> Hi,
>>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now
>>> create the Jenkins tasks for these versions, Uwe can you also add them to
>>> the Policeman's Jenkins job ?
>>> >> This also means that the feature freeze phase has started for both
>>> versions (7.7 and 8.0):
>>> >>
>>> >> No new features may be committed to the branch.
>>> >> Documentation patches, build patches and serious bug fixes may be
>>> committed to the branch. However, you should submit all patches you want to
>>> commit to Jira first to give others the chance to review and possibly vote
>>> against the patch. Keep in mind that it is our main intention to keep the
>>> branch as stable as possible.
>>> >> All patches that are intended for the branch should first be
>>> committed to the unstable branch, merged into the stable branch, and then
>>> into the current release branch.
>>> >> Normal unstable and stable branch development may continue as usual.
>>> However, if you plan to commit a big change to the unstable branch while
>>> the branch feature freeze is in effect, think twice: can't the addition
>>> wait a couple more days? Merges of bug fixes into the branch may become
>>> more difficult.
>>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will
>>> delay a release candidate build.
>>> >>
>>> >>
>>> >> Thanks,
>>> >> Jim
>>> >>
>>> >>
>>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>>
>>> >>> sure, thanks Jim!
>>> >>>
>>> >>> Tommaso
>>> >>>
>>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> >>> <ji...@gmail.com> ha scritto:
>>> >>> >
>>> >>> > Go ahead Tommaso the branch is not created yet.
>>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
>>> wednesday and to announce the feature freeze the same day.
>>> >>> > For blocker issues that are still open this leaves another week to
>>> work on a patch and we can update the status at the end of the week in
>>> order to decide if we can start the first build candidate
>>> >>> > early next week. Would that work for you ?
>>> >>> >
>>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>>> tommaso.teofili@gmail.com> a écrit :
>>> >>> >>
>>> >>> >> I'd like to backport
>>> https://issues.apache.org/jira/browse/LUCENE-8659
>>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>> >>> >>
>>> >>> >> Regards,
>>> >>> >> Tommaso
>>> >>> >>
>>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >>> >> <jp...@gmail.com> ha scritto:
>>> >>> >> >
>>> >>> >> > Hi Noble,
>>> >>> >> >
>>> >>> >> > No it hasn't created yet.
>>> >>> >> >
>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <
>>> noble.paul@gmail.com> wrote:
>>> >>> >> > >
>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>> >>> >> > >
>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>>> david.w.smiley@gmail.com> wrote:
>>> >>> >> > > >
>>> >>> >> > > > I finally have a patch up for
>>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>>> blocker) that I feel pretty good about.  This provides a key part of the
>>> nested document support.
>>> >>> >> > > > I will work on some documentation for it this week --
>>> SOLR-13129
>>> >>> >> > > >
>>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>>> jan.asf@cominvent.com> wrote:
>>> >>> >> > > >>
>>> >>> >> > > >> I don't think it is critical for this to be a blocker for
>>> 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>> >>> >> > > >> I think we should simply remove the buffering feature in
>>> the UI and replace it with an error message popup or something.
>>> >>> >> > > >> I'll try to take a look next week.
>>> >>> >> > > >>
>>> >>> >> > > >> --
>>> >>> >> > > >> Jan Høydahl, search solution architect
>>> >>> >> > > >> Cominvent AS - www.cominvent.com
>>> >>> >> > > >>
>>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>>> tomasflobbe@gmail.com>:
>>> >>> >> > > >>
>>> >>> >> > > >> I think the UI is an important Solr feature. As long as
>>> there is a reasonable time horizon for the issue being resolved I'm +1 on
>>> making it a blocker. I'm not familiar enough with the UI code to help
>>> either unfortunately.
>>> >>> >> > > >>
>>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>> >> > > >>>
>>> >>> >> > > >>> It looks like someone tried to make it a blocker once
>>> before... And it's actually a duplicate of an earlier issue (
>>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a
>>> question of whether or not overall quality has a bearing on the decision to
>>> release. As it turns out the screen shot I posted to the issue is less than
>>> half of the shards that eventually got created since there was an
>>> outstanding queue of requests still processing at the time. I'm now having
>>> to delete 50 or so cores, which luckily are small 100 Mb initial testing
>>> cores, not the 20GB cores we'll be testing on in the near future. It more
>>> or less makes it impossible to recommend the use of the admin UI for
>>> anything other than read only observation of the cluster. Now imagine
>>> someone leaves a browser window open and forgets about it rather than
>>> browsing away or closing the window, not knowing that it's silently pumping
>>> out requests after showing an error... would completely hose a node, and
>>> until they tracked down the source of the requests, (hope he didn't go
>>> home) it would be impossible to resolve...
>>> >>> >> > > >>>
>>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>>> jpountz@gmail.com> wrote:
>>> >>> >> > > >>>>
>>> >>> >> > > >>>> Releasing a new major is very challenging on its own,
>>> I'd rather not
>>> >>> >> > > >>>> call it a blocker and delay the release for it since
>>> this isn't a new
>>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has
>>> affected Solr
>>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at
>>> all, but
>>> >>> >> > > >>>> maybe this is something that could get fixed before we
>>> build a RC?
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>>
>>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>>> gus.heck@gmail.com> wrote:
>>> >>> >> > > >>>> >
>>> >>> >> > > >>>> > I'd like to suggest that
>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>> 8.0. I just got burned by it a second time.
>>> >>> >> > > >>>> >
>>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> Cool,
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> I am working on giving my best release time guess as
>>> possible on the FOSDEM conference!
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> Uwe
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> -----
>>> >>> >> > > >>>> >> Uwe Schindler
>>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>> >> > > >>>> >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> > -----Original Message-----
>>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the
>>> week of February 4th.
>>> >>> >> > > >>>> >> >
>>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>> jim.ferenczi@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > > Hi,
>>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on
>>> releasing 8.0. The branch is
>>> >>> >> > > >>>> >> > already created so we can start the process anytime
>>> now. Unless there are
>>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze
>>> next week in order to build the
>>> >>> >> > > >>>> >> > first candidate the week after.
>>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can
>>> handle both with Alan so
>>> >>> >> > > >>>> >> > the question now is whether we are ok to start the
>>> release process or if there
>>> >>> >> > > >>>> >> > are any blockers left ;).
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > >
>>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>> >> > > >>>> >> > a écrit :
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I’ve started to work through the various
>>> deprecations on the new master
>>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to
>>> need some assistance for
>>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to
>>> do.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one
>>> for lucene and one for Solr,
>>> >>> >> > > >>>> >> > with lists of the deprecations that need to be
>>> removed in each one.  I’ll create
>>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push
>>> the changes I’ve already
>>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA
>>> issues for any changes that
>>> >>> >> > > >>>> >> > are more involved than just deleting code.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly
>>> for the Solr deprecations
>>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release
>>> at the same time as 8.0, to
>>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s
>>> keep those jobs enabled
>>> >>> >> > > >>>> >> > for now.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>>> uwe@thetaphi.de> wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Hi,
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to
>>> Jenkins once I have some time
>>> >>> >> > > >>>> >> > later today.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x?
>>> Should we stop using it
>>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6
>>> only for bugfixes), or
>>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the
>>> latter case I would keep
>>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Uwe
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> -----
>>> >>> >> > > >>>> >> > >> Uwe Schindler
>>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just
>>> created a branch for 8x
>>> >>> >> > > >>>> >> > from master, and am in the process of updating the
>>> master branch to version
>>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0
>>> release should also be
>>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I
>>> know there are still some
>>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should
>>> let us clean up master by
>>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and
>>> give us an idea of any
>>> >>> >> > > >>>> >> > replacement work that needs to be done.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>>> david.w.smiley@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> January.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>>> sg.online.email@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon
>>> as there is an enhancement
>>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands
>>> on.
>>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Thx
>>> >>> >> > > >>>> >> > >> SG
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:
>>>  project in (SOLR, LUCENE) AND
>>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion
>>> = "master (8.0)"
>>> >>> >> > > >>>> >> > >>    click here:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> >
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >>> >> > > >>>> >> >
>>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >>> >> > > >>>> >> >
>>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on
>>> those issues not yet
>>> >>> >> > > >>>> >> > assigned.
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>>> jpountz@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> +1
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > Hi all,
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!)
>>> we should think about
>>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.
>>> I’ll volunteer to create the
>>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should
>>> have some time to
>>> >>> >> > > >>>> >> > clean up the master branch and uncover anything
>>> that still needs to be done
>>> >>> >> > > >>>> >> > on 8.0 before we start the release process next
>>> year.
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
>>> casstargett@gmail.com>
>>> >>> >> > > >>>> >> > wrote:
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >> > 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
>>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <
>>> jim.ferenczi@gmail.com>
>>> >>> >> > > >>>> >> > 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
>>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>> >>> >> > > >>>> >> > >> >> >>
>>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>>> Knize
>>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <er...@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
>>> >>> >> > > >>>> >> > <da...@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
>>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>>> >>> >> > > >>>> >> > r%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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36,
>>> jim ferenczi
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <er...@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
>>> >>> >> > > >>>> >> > <ca...@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
>>> >>> >> > > >>>> >> > <ji...@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
>>> >>> >> > > >>>> >> > <da...@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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>>> >>> >> > > >>>> >> > <jp...@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
>>> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional
>>> commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> -----------------------------------------------------------
>>> >>> >> > > >>>> >> > ----------
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe,
>>> e-mail: dev-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional
>>> commands, e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands,
>>> e-mail: dev-
>>> >>> >> > > >>>> >> > help@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-
>>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail:
>>> dev-
>>> >>> >> > > >>>> >> > help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> >>> >> > > >>>> >> > >> >> >>> --
>>> >>> >> > > >>>> >> > >> >> >>>
>>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >>> >> > > >>>> >> > >> >>
>>> >>> >> > > >>>> >> > >> >
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Adrien
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >>
>>> ---------------------------------------------------------------------
>>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail:
>>> dev-unsubscribe@lucene.apache.org
>>> >>> >> > > >>>> >> > >> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>>> Author, Speaker
>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
>>> Book:
>>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>> >>> >> > > >>>> >> > >>
>>> >>> >> > > >>>> >> > >> --
>>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>>> Author, Speaker
>>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
>>> Book:
>>> >>> >> > > >>>> >> > <http://www.solrenterprisesearchserver.com>
>>
>> --

Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene PMC Member and Committer
nknize@apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Sure Nick, I am not aware of other blockers for 7.7 so I'll start the first
RC when your patch is merged.
Kevin, this looks like a big change so I am not sure if it's a good idea to
rush this in for 8.0. Would it be safer to target another version in order
to take some time to ensure that it's not breaking anything ? I guess that
your concern is that a change like this should happen in a major version
but I wonder if it's worth the risk. I don't know this part of the code and
the implications of such a change so I let you decide what we should do
here but let's not delay the release if we realize that this change
requires more than a few days to be merged.

Le mer. 30 janv. 2019 à 20:25, Nicholas Knize <nk...@gmail.com> a écrit :

> Hey Jim,
>
> I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with
> a pretty straightforward patch. This is a critical one that I think needs
> to be in for 7.7 and 8.0. Can I set this as a blocker?
>
> On Wed, Jan 30, 2019 at 1:07 PM Kevin Risden <kr...@apache.org> wrote:
>
>> Jim,
>>
>> Since 7.7 needs to be released before 8.0 does that leave time to get
>> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
>> currently under review.
>>
>> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
>> feel this should make it into 8.0 or not.
>>
>> Kevin Risden
>>
>> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
>> wrote:
>> >
>> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
>> don't handle two concurrent releases in our tests (
>> https://issues.apache.org/jira/browse/LUCENE-8665).
>> > Since we want to release 7.7 first I created the Jenkins job for this
>> version only and will build the first candidate for this version later this
>> week if there are no objection.
>> > I'll restore the version bump for 8.0 when 7.7 is out.
>> >
>> >
>> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
>> écrit :
>> >>
>> >> Hi,
>> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now
>> create the Jenkins tasks for these versions, Uwe can you also add them to
>> the Policeman's Jenkins job ?
>> >> This also means that the feature freeze phase has started for both
>> versions (7.7 and 8.0):
>> >>
>> >> No new features may be committed to the branch.
>> >> Documentation patches, build patches and serious bug fixes may be
>> committed to the branch. However, you should submit all patches you want to
>> commit to Jira first to give others the chance to review and possibly vote
>> against the patch. Keep in mind that it is our main intention to keep the
>> branch as stable as possible.
>> >> All patches that are intended for the branch should first be committed
>> to the unstable branch, merged into the stable branch, and then into the
>> current release branch.
>> >> Normal unstable and stable branch development may continue as usual.
>> However, if you plan to commit a big change to the unstable branch while
>> the branch feature freeze is in effect, think twice: can't the addition
>> wait a couple more days? Merges of bug fixes into the branch may become
>> more difficult.
>> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will
>> delay a release candidate build.
>> >>
>> >>
>> >> Thanks,
>> >> Jim
>> >>
>> >>
>> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >>>
>> >>> sure, thanks Jim!
>> >>>
>> >>> Tommaso
>> >>>
>> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> >>> <ji...@gmail.com> ha scritto:
>> >>> >
>> >>> > Go ahead Tommaso the branch is not created yet.
>> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
>> wednesday and to announce the feature freeze the same day.
>> >>> > For blocker issues that are still open this leaves another week to
>> work on a patch and we can update the status at the end of the week in
>> order to decide if we can start the first build candidate
>> >>> > early next week. Would that work for you ?
>> >>> >
>> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >>> >>
>> >>> >> I'd like to backport
>> https://issues.apache.org/jira/browse/LUCENE-8659
>> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >>> >>
>> >>> >> Regards,
>> >>> >> Tommaso
>> >>> >>
>> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> >>> >> <jp...@gmail.com> ha scritto:
>> >>> >> >
>> >>> >> > Hi Noble,
>> >>> >> >
>> >>> >> > No it hasn't created yet.
>> >>> >> >
>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
>> wrote:
>> >>> >> > >
>> >>> >> > > Is the branch already cut for 8.0? which is it?
>> >>> >> > >
>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>> david.w.smiley@gmail.com> wrote:
>> >>> >> > > >
>> >>> >> > > > I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> >>> >> > > > I will work on some documentation for it this week --
>> SOLR-13129
>> >>> >> > > >
>> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>> jan.asf@cominvent.com> wrote:
>> >>> >> > > >>
>> >>> >> > > >> I don't think it is critical for this to be a blocker for
>> 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> >>> >> > > >> I think we should simply remove the buffering feature in
>> the UI and replace it with an error message popup or something.
>> >>> >> > > >> I'll try to take a look next week.
>> >>> >> > > >>
>> >>> >> > > >> --
>> >>> >> > > >> Jan Høydahl, search solution architect
>> >>> >> > > >> Cominvent AS - www.cominvent.com
>> >>> >> > > >>
>> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> >>> >> > > >>
>> >>> >> > > >> I think the UI is an important Solr feature. As long as
>> there is a reasonable time horizon for the issue being resolved I'm +1 on
>> making it a blocker. I'm not familiar enough with the UI code to help
>> either unfortunately.
>> >>> >> > > >>
>> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> >>> >> > > >>>
>> >>> >> > > >>> It looks like someone tried to make it a blocker once
>> before... And it's actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it rather than browsing away or closing the
>> window, not knowing that it's silently pumping out requests after showing
>> an error... would completely hose a node, and until they tracked down the
>> source of the requests, (hope he didn't go home) it would be impossible to
>> resolve...
>> >>> >> > > >>>
>> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>> jpountz@gmail.com> wrote:
>> >>> >> > > >>>>
>> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd
>> rather not
>> >>> >> > > >>>> call it a blocker and delay the release for it since this
>> isn't a new
>> >>> >> > > >>>> regression in 8.0: it looks like a problem that has
>> affected Solr
>> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at
>> all, but
>> >>> >> > > >>>> maybe this is something that could get fixed before we
>> build a RC?
>> >>> >> > > >>>>
>> >>> >> > > >>>>
>> >>> >> > > >>>>
>> >>> >> > > >>>>
>> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
>> gus.heck@gmail.com> wrote:
>> >>> >> > > >>>> >
>> >>> >> > > >>>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> >>> >> > > >>>> >
>> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >> Cool,
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >> I am working on giving my best release time guess as
>> possible on the FOSDEM conference!
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >> Uwe
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >> -----
>> >>> >> > > >>>> >> Uwe Schindler
>> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>> >>> >> > > >>>> >> http://www.thetaphi.de
>> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >> > -----Original Message-----
>> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> >>> >> > > >>>> >> >
>> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the
>> week of February 4th.
>> >>> >> > > >>>> >> >
>> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>> jim.ferenczi@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >
>> >>> >> > > >>>> >> > > Hi,
>> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on
>> releasing 8.0. The branch is
>> >>> >> > > >>>> >> > already created so we can start the process anytime
>> now. Unless there are
>> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next
>> week in order to build the
>> >>> >> > > >>>> >> > first candidate the week after.
>> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can
>> handle both with Alan so
>> >>> >> > > >>>> >> > the question now is whether we are ok to start the
>> release process or if there
>> >>> >> > > >>>> >> > are any blockers left ;).
>> >>> >> > > >>>> >> > >
>> >>> >> > > >>>> >> > >
>> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>> romseygeek@gmail.com>
>> >>> >> > > >>>> >> > a écrit :
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> I’ve started to work through the various
>> deprecations on the new master
>> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to
>> need some assistance for
>> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to
>> do.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for
>> lucene and one for Solr,
>> >>> >> > > >>>> >> > with lists of the deprecations that need to be
>> removed in each one.  I’ll create
>> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push
>> the changes I’ve already
>> >>> >> > > >>>> >> > done there.  We can then create individual JIRA
>> issues for any changes that
>> >>> >> > > >>>> >> > are more involved than just deleting code.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly
>> for the Solr deprecations
>> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>> romseygeek@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release
>> at the same time as 8.0, to
>> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s
>> keep those jobs enabled
>> >>> >> > > >>>> >> > for now.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> Hi,
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to
>> Jenkins once I have some time
>> >>> >> > > >>>> >> > later today.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x?
>> Should we stop using it
>> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6
>> only for bugfixes), or
>> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the
>> latter case I would keep
>> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> Uwe
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> -----
>> >>> >> > > >>>> >> > >> Uwe Schindler
>> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>> >>> >> > > >>>> >> > >> http://www.thetaphi.de
>> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just
>> created a branch for 8x
>> >>> >> > > >>>> >> > from master, and am in the process of updating the
>> master branch to version
>> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0
>> release should also be
>> >>> >> > > >>>> >> > back-ported to branch_8x from master.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I
>> know there are still some
>> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should
>> let us clean up master by
>> >>> >> > > >>>> >> > removing as much deprecated code as possible, and
>> give us an idea of any
>> >>> >> > > >>>> >> > replacement work that needs to be done.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>> david.w.smiley@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> January.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>> sg.online.email@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as
>> there is an enhancement
>> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands
>> on.
>> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> Thx
>> >>> >> > > >>>> >> > >> SG
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:
>>  project in (SOLR, LUCENE) AND
>> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion
>> = "master (8.0)"
>> >>> >> > > >>>> >> > >>    click here:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> >
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> >>> >> > > >>>> >> >
>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> >>> >> > > >>>> >> >
>> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on
>> those issues not yet
>> >>> >> > > >>>> >> > assigned.
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>> jpountz@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> +1
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>> >>> >> > > >>>> >> > >> >
>> >>> >> > > >>>> >> > >> > Hi all,
>> >>> >> > > >>>> >> > >> >
>> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!)
>> we should think about
>> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.
>> I’ll volunteer to create the
>> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should
>> have some time to
>> >>> >> > > >>>> >> > clean up the master branch and uncover anything that
>> still needs to be done
>> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>> >>> >> > > >>>> >> > >> >
>> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
>> casstargett@gmail.com>
>> >>> >> > > >>>> >> > wrote:
>> >>> >> > > >>>> >> > >> >
>> >>> >> > > >>>> >> > >> > 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
>> >>> >> > > >>>> >> > <er...@gmail.com> 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 <
>> jim.ferenczi@gmail.com>
>> >>> >> > > >>>> >> > 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
>> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>> >>> >> > > >>>> >> > >> >> >>
>> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
>> Knize
>> >>> >> > > >>>> >> > <nk...@gmail.com> 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
>> >>> >> > > >>>> >> > <ca...@gmail.com> 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
>> >>> >> > > >>>> >> > <ji...@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
>> >>> >> > > >>>> >> > <ca...@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
>> >>> >> > > >>>> >> > <ji...@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
>> >>> >> > > >>>> >> > <ca...@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
>> >>> >> > > >>>> >> > <er...@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
>> >>> >> > > >>>> >> > <da...@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
>> >>> >> > > >>>> >> > <ji...@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%3DBlocke
>> >>> >> > > >>>> >> > r%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
>> >>> >> > > >>>> >> > <jp...@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
>> >>> >> > > >>>> >> > <jp...@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%3DBlocke
>> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36,
>> jim ferenczi
>> >>> >> > > >>>> >> > <ji...@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
>> >>> >> > > >>>> >> > <er...@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
>> >>> >> > > >>>> >> > <ca...@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
>> >>> >> > > >>>> >> > <ji...@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
>> >>> >> > > >>>> >> > <da...@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
>> >>> >> > > >>>> >> > <jp...@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
>> >>> >> > > >>>> >> > <rc...@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 <jp...@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
>> >>> >> > > >>>> >> > <jp...@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
>> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional
>> commands, e-mail: dev-
>> >>> >> > > >>>> >> > help@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> -----------------------------------------------------------
>> >>> >> > > >>>> >> > ----------
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>> dev-
>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional
>> commands, e-mail: dev-
>> >>> >> > > >>>> >> > help@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-
>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands,
>> e-mail: dev-
>> >>> >> > > >>>> >> > help@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-
>> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>> >>> >> > > >>>> >> > help@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> >>>>>>>>>
>> >>> >> > > >>>> >> > >> >> >>> --
>> >>> >> > > >>>> >> > >> >> >>>
>> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> >> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >>> >> > > >>>> >> > >> >>
>> >>> >> > > >>>> >> > >> >
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> --
>> >>> >> > > >>>> >> > >> Adrien
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >>
>> ---------------------------------------------------------------------
>> >>> >> > > >>>> >> > >> To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > >> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> --
>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>> Author, Speaker
>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
>> Book:
>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >> --
>> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>> Author, Speaker
>> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
>> Book:
>> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> > >>
>> >>> >> > > >>>> >> >
>> >>> >> > > >>>> >> >
>> >>> >> > > >>>> >> > --
>> >>> >> > > >>>> >> > Adrien
>> >>> >> > > >>>> >> >
>> >>> >> > > >>>> >> >
>> ---------------------------------------------------------------------
>> >>> >> > > >>>> >> > To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >>> >> > > >>>> >> > For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >>> >> > > >>>> >>
>> >>> >> > > >>>> >>
>> >>> >> > > >
>
> --
>
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy  |  Elasticsearch
> Apache Lucene Committer
> nknize@apache.org
>

Re: Lucene/Solr 8.0

[Nicholas Knize <nk...@gmail.com>]

Hey Jim,

I just added https://issues.apache.org/jira/browse/LUCENE-8669 along with a
pretty straightforward patch. This is a critical one that I think needs to
be in for 7.7 and 8.0. Can I set this as a blocker?

On Wed, Jan 30, 2019 at 1:07 PM Kevin Risden <kr...@apache.org> wrote:

> Jim,
>
> Since 7.7 needs to be released before 8.0 does that leave time to get
> SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
> currently under review.
>
> Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
> feel this should make it into 8.0 or not.
>
> Kevin Risden
>
> On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> > I had to revert the version bump for 8.0 (8.1) on branch_8x because we
> don't handle two concurrent releases in our tests (
> https://issues.apache.org/jira/browse/LUCENE-8665).
> > Since we want to release 7.7 first I created the Jenkins job for this
> version only and will build the first candidate for this version later this
> week if there are no objection.
> > I'll restore the version bump for 8.0 when 7.7 is out.
> >
> >
> > Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
> écrit :
> >>
> >> Hi,
> >> Hearing no objection I created the branches for 8.0 and 7.7. I'll now
> create the Jenkins tasks for these versions, Uwe can you also add them to
> the Policeman's Jenkins job ?
> >> This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
> >>
> >> No new features may be committed to the branch.
> >> Documentation patches, build patches and serious bug fixes may be
> committed to the branch. However, you should submit all patches you want to
> commit to Jira first to give others the chance to review and possibly vote
> against the patch. Keep in mind that it is our main intention to keep the
> branch as stable as possible.
> >> All patches that are intended for the branch should first be committed
> to the unstable branch, merged into the stable branch, and then into the
> current release branch.
> >> Normal unstable and stable branch development may continue as usual.
> However, if you plan to commit a big change to the unstable branch while
> the branch feature freeze is in effect, think twice: can't the addition
> wait a couple more days? Merges of bug fixes into the branch may become
> more difficult.
> >> Only Jira issues with Fix version "X.Y" and priority "Blocker" will
> delay a release candidate build.
> >>
> >>
> >> Thanks,
> >> Jim
> >>
> >>
> >> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >>>
> >>> sure, thanks Jim!
> >>>
> >>> Tommaso
> >>>
> >>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> >>> <ji...@gmail.com> ha scritto:
> >>> >
> >>> > Go ahead Tommaso the branch is not created yet.
> >>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or
> wednesday and to announce the feature freeze the same day.
> >>> > For blocker issues that are still open this leaves another week to
> work on a patch and we can update the status at the end of the week in
> order to decide if we can start the first build candidate
> >>> > early next week. Would that work for you ?
> >>> >
> >>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >>> >>
> >>> >> I'd like to backport
> https://issues.apache.org/jira/browse/LUCENE-8659
> >>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >>> >>
> >>> >> Regards,
> >>> >> Tommaso
> >>> >>
> >>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> >>> >> <jp...@gmail.com> ha scritto:
> >>> >> >
> >>> >> > Hi Noble,
> >>> >> >
> >>> >> > No it hasn't created yet.
> >>> >> >
> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
> wrote:
> >>> >> > >
> >>> >> > > Is the branch already cut for 8.0? which is it?
> >>> >> > >
> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> >>> >> > > >
> >>> >> > > > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> >>> >> > > > I will work on some documentation for it this week --
> SOLR-13129
> >>> >> > > >
> >>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
> jan.asf@cominvent.com> wrote:
> >>> >> > > >>
> >>> >> > > >> I don't think it is critical for this to be a blocker for
> 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> >>> >> > > >> I think we should simply remove the buffering feature in the
> UI and replace it with an error message popup or something.
> >>> >> > > >> I'll try to take a look next week.
> >>> >> > > >>
> >>> >> > > >> --
> >>> >> > > >> Jan Høydahl, search solution architect
> >>> >> > > >> Cominvent AS - www.cominvent.com
> >>> >> > > >>
> >>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> >>> >> > > >>
> >>> >> > > >> I think the UI is an important Solr feature. As long as
> there is a reasonable time horizon for the issue being resolved I'm +1 on
> making it a blocker. I'm not familiar enough with the UI code to help
> either unfortunately.
> >>> >> > > >>
> >>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <
> gus.heck@gmail.com> wrote:
> >>> >> > > >>>
> >>> >> > > >>> It looks like someone tried to make it a blocker once
> before... And it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> >>> >> > > >>>
> >>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
> jpountz@gmail.com> wrote:
> >>> >> > > >>>>
> >>> >> > > >>>> Releasing a new major is very challenging on its own, I'd
> rather not
> >>> >> > > >>>> call it a blocker and delay the release for it since this
> isn't a new
> >>> >> > > >>>> regression in 8.0: it looks like a problem that has
> affected Solr
> >>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at
> all, but
> >>> >> > > >>>> maybe this is something that could get fixed before we
> build a RC?
> >>> >> > > >>>>
> >>> >> > > >>>>
> >>> >> > > >>>>
> >>> >> > > >>>>
> >>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <
> gus.heck@gmail.com> wrote:
> >>> >> > > >>>> >
> >>> >> > > >>>> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >>> >> > > >>>> >
> >>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >>> >> > > >>>> >>
> >>> >> > > >>>> >> Cool,
> >>> >> > > >>>> >>
> >>> >> > > >>>> >> I am working on giving my best release time guess as
> possible on the FOSDEM conference!
> >>> >> > > >>>> >>
> >>> >> > > >>>> >> Uwe
> >>> >> > > >>>> >>
> >>> >> > > >>>> >> -----
> >>> >> > > >>>> >> Uwe Schindler
> >>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> >>> >> > > >>>> >> http://www.thetaphi.de
> >>> >> > > >>>> >> eMail: uwe@thetaphi.de
> >>> >> > > >>>> >>
> >>> >> > > >>>> >> > -----Original Message-----
> >>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> >>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> >>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> >>> >> > > >>>> >> >
> >>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the
> week of February 4th.
> >>> >> > > >>>> >> >
> >>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >
> >>> >> > > >>>> >> > > Hi,
> >>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on
> releasing 8.0. The branch is
> >>> >> > > >>>> >> > already created so we can start the process anytime
> now. Unless there are
> >>> >> > > >>>> >> > objections I'd like to start the feature freeze next
> week in order to build the
> >>> >> > > >>>> >> > first candidate the week after.
> >>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can
> handle both with Alan so
> >>> >> > > >>>> >> > the question now is whether we are ok to start the
> release process or if there
> >>> >> > > >>>> >> > are any blockers left ;).
> >>> >> > > >>>> >> > >
> >>> >> > > >>>> >> > >
> >>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
> romseygeek@gmail.com>
> >>> >> > > >>>> >> > a écrit :
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> I’ve started to work through the various
> deprecations on the new master
> >>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to
> need some assistance for
> >>> >> > > >>>> >> > several of them, as it’s not entirely clear what to
> do.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for
> lucene and one for Solr,
> >>> >> > > >>>> >> > with lists of the deprecations that need to be
> removed in each one.  I’ll create
> >>> >> > > >>>> >> > a shared branch on gitbox to work against, and push
> the changes I’ve already
> >>> >> > > >>>> >> > done there.  We can then create individual JIRA
> issues for any changes that
> >>> >> > > >>>> >> > are more involved than just deleting code.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> All assistance gratefully received, particularly
> for the Solr deprecations
> >>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
> romseygeek@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at
> the same time as 8.0, to
> >>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s
> keep those jobs enabled
> >>> >> > > >>>> >> > for now.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> Hi,
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins
> once I have some time
> >>> >> > > >>>> >> > later today.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> The question: How to proceed with branch_7x?
> Should we stop using it
> >>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6
> only for bugfixes), or
> >>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the
> latter case I would keep
> >>> >> > > >>>> >> > the jenkins jobs enabled for a while.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> Uwe
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> -----
> >>> >> > > >>>> >> > >> Uwe Schindler
> >>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> >>> >> > > >>>> >> > >> http://www.thetaphi.de
> >>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> >>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >>> >> > > >>>> >> > >> To: dev@lucene.apache.org
> >>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just
> created a branch for 8x
> >>> >> > > >>>> >> > from master, and am in the process of updating the
> master branch to version
> >>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0
> release should also be
> >>> >> > > >>>> >> > back-ported to branch_8x from master.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I
> know there are still some
> >>> >> > > >>>> >> > things being worked on for 8.0; however, it should
> let us clean up master by
> >>> >> > > >>>> >> > removing as much deprecated code as possible, and
> give us an idea of any
> >>> >> > > >>>> >> > replacement work that needs to be done.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> January.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
> sg.online.email@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as
> there is an enhancement
> >>> >> > > >>>> >> > on nested-documents we are waiting to get our hands
> on.
> >>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> Thx
> >>> >> > > >>>> >> > >> SG
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >>> >> > > >>>> >> > <da...@gmail.com> wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:
>  project in (SOLR, LUCENE) AND
> >>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion =
> "master (8.0)"
> >>> >> > > >>>> >> > >>    click here:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >>> >> > > >>>> >> >
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >>> >> > > >>>> >> >
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on
> those issues not yet
> >>> >> > > >>>> >> > assigned.
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
> jpountz@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> +1
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >>> >> > > >>>> >> > <ro...@gmail.com> wrote:
> >>> >> > > >>>> >> > >> >
> >>> >> > > >>>> >> > >> > Hi all,
> >>> >> > > >>>> >> > >> >
> >>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!)
> we should think about
> >>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.
> I’ll volunteer to create the
> >>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should
> have some time to
> >>> >> > > >>>> >> > clean up the master branch and uncover anything that
> still needs to be done
> >>> >> > > >>>> >> > on 8.0 before we start the release process next year.
> >>> >> > > >>>> >> > >> >
> >>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> >>> >> > > >>>> >> > wrote:
> >>> >> > > >>>> >> > >> >
> >>> >> > > >>>> >> > >> > 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
> >>> >> > > >>>> >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> >>> >> > > >>>> >> > 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
> >>> >> > > >>>> >> > <da...@gmail.com> a écrit :
> >>> >> > > >>>> >> > >> >> >>
> >>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas
> Knize
> >>> >> > > >>>> >> > <nk...@gmail.com> 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
> >>> >> > > >>>> >> > <ca...@gmail.com> 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
> >>> >> > > >>>> >> > <ji...@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
> >>> >> > > >>>> >> > <ca...@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
> >>> >> > > >>>> >> > <ji...@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
> >>> >> > > >>>> >> > <ca...@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
> >>> >> > > >>>> >> > <er...@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
> >>> >> > > >>>> >> > <da...@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
> >>> >> > > >>>> >> > <ji...@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%3DBlocke
> >>> >> > > >>>> >> > r%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
> >>> >> > > >>>> >> > <jp...@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
> >>> >> > > >>>> >> > <jp...@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%3DBlocke
> >>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36,
> jim ferenczi
> >>> >> > > >>>> >> > <ji...@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
> >>> >> > > >>>> >> > <er...@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
> >>> >> > > >>>> >> > <ca...@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
> >>> >> > > >>>> >> > <ji...@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
> >>> >> > > >>>> >> > <da...@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
> >>> >> > > >>>> >> > <jp...@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
> >>> >> > > >>>> >> > <rc...@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 <jp...@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
> >>> >> > > >>>> >> > <jp...@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
> >>> >> > > >>>> >> > <rc...@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 <jp...@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-
> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional
> commands, e-mail: dev-
> >>> >> > > >>>> >> > help@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> -----------------------------------------------------------
> >>> >> > > >>>> >> > ----------
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
> dev-
> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands,
> e-mail: dev-
> >>> >> > > >>>> >> > help@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-
> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands,
> e-mail: dev-
> >>> >> > > >>>> >> > help@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-
> >>> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >>> >> > > >>>> >> > help@lucene.apache.org
> >>> >> > > >>>> >> > >> >> >>>>>>>>>
> >>> >> > > >>>> >> > >> >> >>> --
> >>> >> > > >>>> >> > >> >> >>>
> >>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
> >>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>> >> > > >>>> >> > >> >>
> >>> >> > > >>>> >> > >> >
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> --
> >>> >> > > >>>> >> > >> Adrien
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >>
> ---------------------------------------------------------------------
> >>> >> > > >>>> >> > >> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> --
> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
> Author, Speaker
> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
> Book:
> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >> --
> >>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
> Author, Speaker
> >>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley |
> Book:
> >>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> > >>
> >>> >> > > >>>> >> >
> >>> >> > > >>>> >> >
> >>> >> > > >>>> >> > --
> >>> >> > > >>>> >> > Adrien
> >>> >> > > >>>> >> >
> >>> >> > > >>>> >> >
> ---------------------------------------------------------------------
> >>> >> > > >>>> >> > To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >>> >> > > >>>> >> > For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>> >> > > >>>> >>
> >>> >> > > >>>> >>
> >>> >> > > >

-- 

Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene Committer
nknize@apache.org

Re: Lucene/Solr 8.0

[Kevin Risden <kr...@apache.org>]

Jim,

Since 7.7 needs to be released before 8.0 does that leave time to get
SOLR-9515 - Hadoop 3 upgrade into 8.0? I have a PR updated and it is
currently under review.

Should I set the SOLR-9515 as a blocker for 8.0? I'm curious if others
feel this should make it into 8.0 or not.

Kevin Risden

On Tue, Jan 29, 2019 at 11:15 AM jim ferenczi <ji...@gmail.com> wrote:
>
> I had to revert the version bump for 8.0 (8.1) on branch_8x because we don't handle two concurrent releases in our tests (https://issues.apache.org/jira/browse/LUCENE-8665).
> Since we want to release 7.7 first I created the Jenkins job for this version only and will build the first candidate for this version later this week if there are no objection.
> I'll restore the version bump for 8.0 when 7.7 is out.
>
>
> Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a écrit :
>>
>> Hi,
>> Hearing no objection I created the branches for 8.0 and 7.7. I'll now create the Jenkins tasks for these versions, Uwe can you also add them to the Policeman's Jenkins job ?
>> This also means that the feature freeze phase has started for both versions (7.7 and 8.0):
>>
>> No new features may be committed to the branch.
>> Documentation patches, build patches and serious bug fixes may be committed to the branch. However, you should submit all patches you want to commit to Jira first to give others the chance to review and possibly vote against the patch. Keep in mind that it is our main intention to keep the branch as stable as possible.
>> All patches that are intended for the branch should first be committed to the unstable branch, merged into the stable branch, and then into the current release branch.
>> Normal unstable and stable branch development may continue as usual. However, if you plan to commit a big change to the unstable branch while the branch feature freeze is in effect, think twice: can't the addition wait a couple more days? Merges of bug fixes into the branch may become more difficult.
>> Only Jira issues with Fix version "X.Y" and priority "Blocker" will delay a release candidate build.
>>
>>
>> Thanks,
>> Jim
>>
>>
>> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com> a écrit :
>>>
>>> sure, thanks Jim!
>>>
>>> Tommaso
>>>
>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>> <ji...@gmail.com> ha scritto:
>>> >
>>> > Go ahead Tommaso the branch is not created yet.
>>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
>>> > For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
>>> > early next week. Would that work for you ?
>>> >
>>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>> >>
>>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>> >>
>>> >> Regards,
>>> >> Tommaso
>>> >>
>>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>>> >> <jp...@gmail.com> ha scritto:
>>> >> >
>>> >> > Hi Noble,
>>> >> >
>>> >> > No it hasn't created yet.
>>> >> >
>>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>>> >> > >
>>> >> > > Is the branch already cut for 8.0? which is it?
>>> >> > >
>>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>>> >> > > >
>>> >> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>>> >> > > >
>>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>> >> > > >>
>>> >> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>>> >> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>>> >> > > >> I'll try to take a look next week.
>>> >> > > >>
>>> >> > > >> --
>>> >> > > >> Jan Høydahl, search solution architect
>>> >> > > >> Cominvent AS - www.cominvent.com
>>> >> > > >>
>>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>> >> > > >>
>>> >> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>> >> > > >>
>>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>> >> > > >>>
>>> >> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>> >> > > >>>
>>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>> >> > > >>>>
>>> >> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>>> >> > > >>>> call it a blocker and delay the release for it since this isn't a new
>>> >> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> >> > > >>>> maybe this is something that could get fixed before we build a RC?
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>> >> > > >>>> >
>>> >> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>> >> > > >>>> >
>>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >> > > >>>> >>
>>> >> > > >>>> >> Cool,
>>> >> > > >>>> >>
>>> >> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>> >> > > >>>> >>
>>> >> > > >>>> >> Uwe
>>> >> > > >>>> >>
>>> >> > > >>>> >> -----
>>> >> > > >>>> >> Uwe Schindler
>>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>>> >> > > >>>> >> http://www.thetaphi.de
>>> >> > > >>>> >> eMail: uwe@thetaphi.de
>>> >> > > >>>> >>
>>> >> > > >>>> >> > -----Original Message-----
>>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>>> >> > > >>>> >> >
>>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>> >> > > >>>> >> >
>>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >
>>> >> > > >>>> >> > > Hi,
>>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>> >> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>>> >> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>> >> > > >>>> >> > first candidate the week after.
>>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>> >> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>>> >> > > >>>> >> > are any blockers left ;).
>>> >> > > >>>> >> > >
>>> >> > > >>>> >> > >
>>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>> >> > > >>>> >> > a écrit :
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>> >> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>> >> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>> >> > > >>>> >> > are more involved than just deleting code.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>> >> > > >>>> >> > for now.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> Hi,
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>> >> > > >>>> >> > later today.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> Uwe
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> -----
>>> >> > > >>>> >> > >> Uwe Schindler
>>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> >> > > >>>> >> > >> http://www.thetaphi.de
>>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>> >> > > >>>> >> > from master, and am in the process of updating the master branch to version
>>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>> >> > > >>>> >> > back-ported to branch_8x from master.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>> >> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>> >> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>> >> > > >>>> >> > replacement work that needs to be done.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> January.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> Thx
>>> >> > > >>>> >> > >> SG
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >> > > >>>> >> > <da...@gmail.com> wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> >> > > >>>> >> > >>    click here:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>> >> > > >>>> >> > assigned.
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> +1
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>>> >> > > >>>> >> > >> >
>>> >> > > >>>> >> > >> > Hi all,
>>> >> > > >>>> >> > >> >
>>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>> >> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>>> >> > > >>>> >> > >> >
>>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>> >> > > >>>> >> > wrote:
>>> >> > > >>>> >> > >> >
>>> >> > > >>>> >> > >> > 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
>>> >> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>> >> > > >>>> >> > 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
>>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>>> >> > > >>>> >> > >> >> >>
>>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> >> > > >>>> >> > <nk...@gmail.com> 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
>>> >> > > >>>> >> > <ca...@gmail.com> 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
>>> >> > > >>>> >> > <ji...@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
>>> >> > > >>>> >> > <ca...@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
>>> >> > > >>>> >> > <ji...@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
>>> >> > > >>>> >> > <ca...@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
>>> >> > > >>>> >> > <er...@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
>>> >> > > >>>> >> > <da...@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
>>> >> > > >>>> >> > <ji...@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%3DBlocke
>>> >> > > >>>> >> > r%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
>>> >> > > >>>> >> > <jp...@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
>>> >> > > >>>> >> > <jp...@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%3DBlocke
>>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> >> > > >>>> >> > <ji...@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
>>> >> > > >>>> >> > <er...@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
>>> >> > > >>>> >> > <ca...@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
>>> >> > > >>>> >> > <ji...@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
>>> >> > > >>>> >> > <da...@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
>>> >> > > >>>> >> > <jp...@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
>>> >> > > >>>> >> > <rc...@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 <jp...@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
>>> >> > > >>>> >> > <jp...@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
>>> >> > > >>>> >> > <rc...@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 <jp...@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-
>>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>>> >> > > >>>> >> > help@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>>> >> > > >>>> >> > ----------
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>> >> > > >>>> >> > help@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-
>>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>> >> > > >>>> >> > help@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-
>>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>> >> > > >>>> >> > help@lucene.apache.org
>>> >> > > >>>> >> > >> >> >>>>>>>>>
>>> >> > > >>>> >> > >> >> >>> --
>>> >> > > >>>> >> > >> >> >>>
>>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > > >>>> >> > >> >>
>>> >> > > >>>> >> > >> >
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> --
>>> >> > > >>>> >> > >> Adrien
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> ---------------------------------------------------------------------
>>> >> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> --
>>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >> --
>>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> > >>
>>> >> > > >>>> >> >
>>> >> > > >>>> >> >
>>> >> > > >>>> >> > --
>>> >> > > >>>> >> > Adrien
>>> >> > > >>>> >> >
>>> >> > > >>>> >> > ---------------------------------------------------------------------
>>> >> > > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > > >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > > >>>> >>
>>> >> > > >>>> >>
>>> >> > > >>>> >> ---------------------------------------------------------------------
>>> >> > > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > > >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > > >>>> >>
>>> >> > > >>>> >
>>> >> > > >>>> >
>>> >> > > >>>> > --
>>> >> > > >>>> > http://www.the111shift.com
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>> --
>>> >> > > >>>> Adrien
>>> >> > > >>>>
>>> >> > > >>>> ---------------------------------------------------------------------
>>> >> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > > >>>>
>>> >> > > >>>
>>> >> > > >>>
>>> >> > > >>> --
>>> >> > > >>> http://www.the111shift.com
>>> >> > > >>
>>> >> > > >>
>>> >> > > > --
>>> >> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>>> >> > >
>>> >> > >
>>> >> > >
>>> >> > > --
>>> >> > > -----------------------------------------------------
>>> >> > > Noble Paul
>>> >> > >
>>> >> > >
>>> >> > > ---------------------------------------------------------------------
>>> >> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > >
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Adrien
>>> >> >
>>> >> >
>>> >> > ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> >
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

I had to revert the version bump for 8.0 (8.1) on branch_8x because we
don't handle two concurrent releases in our tests (
https://issues.apache.org/jira/browse/LUCENE-8665).
Since we want to release 7.7 first I created the Jenkins job for this
version only and will build the first candidate for this version later this
week if there are no objection.
I'll restore the version bump for 8.0 when 7.7 is out.


Le mar. 29 janv. 2019 à 14:43, jim ferenczi <ji...@gmail.com> a
écrit :

> Hi,
> Hearing no objection I created the branches for 8.0 and 7.7. I'll now
> create the Jenkins tasks for these versions, Uwe can you also add them to
> the Policeman's Jenkins job ?
> This also means that the feature freeze phase has started for both
> versions (7.7 and 8.0):
>
>    - No new features may be committed to the branch.
>    - Documentation patches, build patches and serious bug fixes may be
>    committed to the branch. However, you should submit all patches you want to
>    commit to Jira first to give others the chance to review and possibly vote
>    against the patch. Keep in mind that it is our main intention to keep the
>    branch as stable as possible.
>    - All patches that are intended for the branch should first be
>    committed to the unstable branch, merged into the stable branch, and then
>    into the current release branch.
>    - Normal unstable and stable branch development may continue as usual.
>    However, if you plan to commit a big change to the unstable branch while
>    the branch feature freeze is in effect, think twice: can't the addition
>    wait a couple more days? Merges of bug fixes into the branch may become
>    more difficult.
>    - Only Jira issues with Fix version "X.Y" and priority "Blocker" will
>    delay a release candidate build.
>
>
> Thanks,
> Jim
>
>
> Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com>
> a écrit :
>
>> sure, thanks Jim!
>>
>> Tommaso
>>
>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>> <ji...@gmail.com> ha scritto:
>> >
>> > Go ahead Tommaso the branch is not created yet.
>> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
>> and to announce the feature freeze the same day.
>> > For blocker issues that are still open this leaves another week to work
>> on a patch and we can update the status at the end of the week in order to
>> decide if we can start the first build candidate
>> > early next week. Would that work for you ?
>> >
>> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
>> tommaso.teofili@gmail.com> a écrit :
>> >>
>> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>> >>
>> >> Regards,
>> >> Tommaso
>> >>
>> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> >> <jp...@gmail.com> ha scritto:
>> >> >
>> >> > Hi Noble,
>> >> >
>> >> > No it hasn't created yet.
>> >> >
>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
>> wrote:
>> >> > >
>> >> > > Is the branch already cut for 8.0? which is it?
>> >> > >
>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
>> david.w.smiley@gmail.com> wrote:
>> >> > > >
>> >> > > > I finally have a patch up for
>> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
>> blocker) that I feel pretty good about.  This provides a key part of the
>> nested document support.
>> >> > > > I will work on some documentation for it this week -- SOLR-13129
>> >> > > >
>> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
>> jan.asf@cominvent.com> wrote:
>> >> > > >>
>> >> > > >> I don't think it is critical for this to be a blocker for 8.0.
>> If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> >> > > >> I think we should simply remove the buffering feature in the UI
>> and replace it with an error message popup or something.
>> >> > > >> I'll try to take a look next week.
>> >> > > >>
>> >> > > >> --
>> >> > > >> Jan Høydahl, search solution architect
>> >> > > >> Cominvent AS - www.cominvent.com
>> >> > > >>
>> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
>> tomasflobbe@gmail.com>:
>> >> > > >>
>> >> > > >> I think the UI is an important Solr feature. As long as there
>> is a reasonable time horizon for the issue being resolved I'm +1 on making
>> it a blocker. I'm not familiar enough with the UI code to help either
>> unfortunately.
>> >> > > >>
>> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com>
>> wrote:
>> >> > > >>>
>> >> > > >>> It looks like someone tried to make it a blocker once
>> before... And it's actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it rather than browsing away or closing the
>> window, not knowing that it's silently pumping out requests after showing
>> an error... would completely hose a node, and until they tracked down the
>> source of the requests, (hope he didn't go home) it would be impossible to
>> resolve...
>> >> > > >>>
>> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <
>> jpountz@gmail.com> wrote:
>> >> > > >>>>
>> >> > > >>>> Releasing a new major is very challenging on its own, I'd
>> rather not
>> >> > > >>>> call it a blocker and delay the release for it since this
>> isn't a new
>> >> > > >>>> regression in 8.0: it looks like a problem that has affected
>> Solr
>> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all,
>> but
>> >> > > >>>> maybe this is something that could get fixed before we build
>> a RC?
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com>
>> wrote:
>> >> > > >>>> >
>> >> > > >>>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> >> > > >>>> >
>> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >> > > >>>> >>
>> >> > > >>>> >> Cool,
>> >> > > >>>> >>
>> >> > > >>>> >> I am working on giving my best release time guess as
>> possible on the FOSDEM conference!
>> >> > > >>>> >>
>> >> > > >>>> >> Uwe
>> >> > > >>>> >>
>> >> > > >>>> >> -----
>> >> > > >>>> >> Uwe Schindler
>> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
>> >> > > >>>> >> http://www.thetaphi.de
>> >> > > >>>> >> eMail: uwe@thetaphi.de
>> >> > > >>>> >>
>> >> > > >>>> >> > -----Original Message-----
>> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> >> > > >>>> >> >
>> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week
>> of February 4th.
>> >> > > >>>> >> >
>> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>> jim.ferenczi@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >
>> >> > > >>>> >> > > Hi,
>> >> > > >>>> >> > > As we agreed some time ago I'd like to start on
>> releasing 8.0. The branch is
>> >> > > >>>> >> > already created so we can start the process anytime now.
>> Unless there are
>> >> > > >>>> >> > objections I'd like to start the feature freeze next
>> week in order to build the
>> >> > > >>>> >> > first candidate the week after.
>> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can
>> handle both with Alan so
>> >> > > >>>> >> > the question now is whether we are ok to start the
>> release process or if there
>> >> > > >>>> >> > are any blockers left ;).
>> >> > > >>>> >> > >
>> >> > > >>>> >> > >
>> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>> romseygeek@gmail.com>
>> >> > > >>>> >> > a écrit :
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> I’ve started to work through the various deprecations
>> on the new master
>> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need
>> some assistance for
>> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for
>> lucene and one for Solr,
>> >> > > >>>> >> > with lists of the deprecations that need to be removed
>> in each one.  I’ll create
>> >> > > >>>> >> > a shared branch on gitbox to work against, and push the
>> changes I’ve already
>> >> > > >>>> >> > done there.  We can then create individual JIRA issues
>> for any changes that
>> >> > > >>>> >> > are more involved than just deleting code.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> All assistance gratefully received, particularly for
>> the Solr deprecations
>> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
>> romseygeek@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at
>> the same time as 8.0, to
>> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep
>> those jobs enabled
>> >> > > >>>> >> > for now.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
>> uwe@thetaphi.de> wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> Hi,
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins
>> once I have some time
>> >> > > >>>> >> > later today.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should
>> we stop using it
>> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only
>> for bugfixes), or
>> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the
>> latter case I would keep
>> >> > > >>>> >> > the jenkins jobs enabled for a while.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> Uwe
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> -----
>> >> > > >>>> >> > >> Uwe Schindler
>> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>> >> > > >>>> >> > >> http://www.thetaphi.de
>> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> >> > > >>>> >> > >> To: dev@lucene.apache.org
>> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just
>> created a branch for 8x
>> >> > > >>>> >> > from master, and am in the process of updating the
>> master branch to version
>> >> > > >>>> >> > 9.  New commits that should be included in the 8.0
>> release should also be
>> >> > > >>>> >> > back-ported to branch_8x from master.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know
>> there are still some
>> >> > > >>>> >> > things being worked on for 8.0; however, it should let
>> us clean up master by
>> >> > > >>>> >> > removing as much deprecated code as possible, and give
>> us an idea of any
>> >> > > >>>> >> > replacement work that needs to be done.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
>> david.w.smiley@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> January.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
>> sg.online.email@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as
>> there is an enhancement
>> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> Thx
>> >> > > >>>> >> > >> SG
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >> > > >>>> >> > <da...@gmail.com> wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project
>> in (SOLR, LUCENE) AND
>> >> > > >>>> >> > priority = Blocker and status = open and fixVersion =
>> "master (8.0)"
>> >> > > >>>> >> > >>    click here:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> >
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> >> > > >>>> >> >
>> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those
>> issues not yet
>> >> > > >>>> >> > assigned.
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
>> jpountz@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> +1
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >> > > >>>> >> > <ro...@gmail.com> wrote:
>> >> > > >>>> >> > >> >
>> >> > > >>>> >> > >> > Hi all,
>> >> > > >>>> >> > >> >
>> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we
>> should think about
>> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll
>> volunteer to create the
>> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have
>> some time to
>> >> > > >>>> >> > clean up the master branch and uncover anything that
>> still needs to be done
>> >> > > >>>> >> > on 8.0 before we start the release process next year.
>> >> > > >>>> >> > >> >
>> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
>> casstargett@gmail.com>
>> >> > > >>>> >> > wrote:
>> >> > > >>>> >> > >> >
>> >> > > >>>> >> > >> > 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
>> >> > > >>>> >> > <er...@gmail.com> 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 <
>> jim.ferenczi@gmail.com>
>> >> > > >>>> >> > 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
>> >> > > >>>> >> > <da...@gmail.com> a écrit :
>> >> > > >>>> >> > >> >> >>
>> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >> > > >>>> >> > <nk...@gmail.com> 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
>> >> > > >>>> >> > <ca...@gmail.com> 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
>> >> > > >>>> >> > <ji...@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
>> >> > > >>>> >> > <ca...@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
>> >> > > >>>> >> > <ji...@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
>> >> > > >>>> >> > <ca...@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
>> >> > > >>>> >> > <er...@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
>> >> > > >>>> >> > <da...@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
>> >> > > >>>> >> > <ji...@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%3DBlocke
>> >> > > >>>> >> > r%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
>> >> > > >>>> >> > <jp...@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
>> >> > > >>>> >> > <jp...@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%3DBlocke
>> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim
>> ferenczi
>> >> > > >>>> >> > <ji...@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
>> >> > > >>>> >> > <er...@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
>> >> > > >>>> >> > <ca...@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
>> >> > > >>>> >> > <ji...@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
>> >> > > >>>> >> > <da...@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
>> >> > > >>>> >> > <jp...@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
>> >> > > >>>> >> > <rc...@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 <jp...@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
>> >> > > >>>> >> > <jp...@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
>> >> > > >>>> >> > <rc...@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 <jp...@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-
>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional
>> commands, e-mail: dev-
>> >> > > >>>> >> > help@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> -----------------------------------------------------------
>> >> > > >>>> >> > ----------
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands,
>> e-mail: dev-
>> >> > > >>>> >> > help@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-
>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
>> dev-
>> >> > > >>>> >> > help@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-
>> >> > > >>>> >> > unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>> >> > > >>>> >> > help@lucene.apache.org
>> >> > > >>>> >> > >> >> >>>>>>>>>
>> >> > > >>>> >> > >> >> >>> --
>> >> > > >>>> >> > >> >> >>>
>> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
>> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> >> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >> > > >>>> >> > >> >>
>> >> > > >>>> >> > >> >
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> --
>> >> > > >>>> >> > >> Adrien
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >>
>> ---------------------------------------------------------------------
>> >> > > >>>> >> > >> To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >> > > >>>> >> > >> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> --
>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>> Author, Speaker
>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >> --
>> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer,
>> Author, Speaker
>> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >>
>> >> > > >>>> >> > >>
>> >> > > >>>> >> >
>> >> > > >>>> >> >
>> >> > > >>>> >> > --
>> >> > > >>>> >> > Adrien
>> >> > > >>>> >> >
>> >> > > >>>> >> >
>> ---------------------------------------------------------------------
>> >> > > >>>> >> > To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >> > > >>>> >> > For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >> > > >>>> >>
>> >> > > >>>> >>
>> >> > > >>>> >>
>> ---------------------------------------------------------------------
>> >> > > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > > >>>> >> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >> > > >>>> >>
>> >> > > >>>> >
>> >> > > >>>> >
>> >> > > >>>> > --
>> >> > > >>>> > http://www.the111shift.com
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>> --
>> >> > > >>>> Adrien
>> >> > > >>>>
>> >> > > >>>>
>> ---------------------------------------------------------------------
>> >> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> > > >>>>
>> >> > > >>>
>> >> > > >>>
>> >> > > >>> --
>> >> > > >>> http://www.the111shift.com
>> >> > > >>
>> >> > > >>
>> >> > > > --
>> >> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> >> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>> >> > >
>> >> > >
>> >> > >
>> >> > > --
>> >> > > -----------------------------------------------------
>> >> > > Noble Paul
>> >> > >
>> >> > >
>> >> > >
>> ---------------------------------------------------------------------
>> >> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> >> > >
>> >> >
>> >> >
>> >> > --
>> >> > Adrien
>> >> >
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Hi,
Hearing no objection I created the branches for 8.0 and 7.7. I'll now
create the Jenkins tasks for these versions, Uwe can you also add them to
the Policeman's Jenkins job ?
This also means that the feature freeze phase has started for both versions
(7.7 and 8.0):

   - No new features may be committed to the branch.
   - Documentation patches, build patches and serious bug fixes may be
   committed to the branch. However, you should submit all patches you want to
   commit to Jira first to give others the chance to review and possibly vote
   against the patch. Keep in mind that it is our main intention to keep the
   branch as stable as possible.
   - All patches that are intended for the branch should first be committed
   to the unstable branch, merged into the stable branch, and then into the
   current release branch.
   - Normal unstable and stable branch development may continue as usual.
   However, if you plan to commit a big change to the unstable branch while
   the branch feature freeze is in effect, think twice: can't the addition
   wait a couple more days? Merges of bug fixes into the branch may become
   more difficult.
   - Only Jira issues with Fix version "X.Y" and priority "Blocker" will
   delay a release candidate build.


Thanks,
Jim


Le lun. 28 janv. 2019 à 13:54, Tommaso Teofili <to...@gmail.com>
a écrit :

> sure, thanks Jim!
>
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> <ji...@gmail.com> ha scritto:
> >
> > Go ahead Tommaso the branch is not created yet.
> > The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday
> and to announce the feature freeze the same day.
> > For blocker issues that are still open this leaves another week to work
> on a patch and we can update the status at the end of the week in order to
> decide if we can start the first build candidate
> > early next week. Would that work for you ?
> >
> > Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <
> tommaso.teofili@gmail.com> a écrit :
> >>
> >> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> >> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
> >>
> >> Regards,
> >> Tommaso
> >>
> >> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> >> <jp...@gmail.com> ha scritto:
> >> >
> >> > Hi Noble,
> >> >
> >> > No it hasn't created yet.
> >> >
> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com>
> wrote:
> >> > >
> >> > > Is the branch already cut for 8.0? which is it?
> >> > >
> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <
> david.w.smiley@gmail.com> wrote:
> >> > > >
> >> > > > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> >> > > > I will work on some documentation for it this week -- SOLR-13129
> >> > > >
> >> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <
> jan.asf@cominvent.com> wrote:
> >> > > >>
> >> > > >> I don't think it is critical for this to be a blocker for 8.0.
> If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> >> > > >> I think we should simply remove the buffering feature in the UI
> and replace it with an error message popup or something.
> >> > > >> I'll try to take a look next week.
> >> > > >>
> >> > > >> --
> >> > > >> Jan Høydahl, search solution architect
> >> > > >> Cominvent AS - www.cominvent.com
> >> > > >>
> >> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> >> > > >>
> >> > > >> I think the UI is an important Solr feature. As long as there is
> a reasonable time horizon for the issue being resolved I'm +1 on making it
> a blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> >> > > >>
> >> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com>
> wrote:
> >> > > >>>
> >> > > >>> It looks like someone tried to make it a blocker once before...
> And it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> >> > > >>>
> >> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com>
> wrote:
> >> > > >>>>
> >> > > >>>> Releasing a new major is very challenging on its own, I'd
> rather not
> >> > > >>>> call it a blocker and delay the release for it since this
> isn't a new
> >> > > >>>> regression in 8.0: it looks like a problem that has affected
> Solr
> >> > > >>>> since at least 6.3? I'm not familiar with the UI code at all,
> but
> >> > > >>>> maybe this is something that could get fixed before we build a
> RC?
> >> > > >>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com>
> wrote:
> >> > > >>>> >
> >> > > >>>> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >> > > >>>> >
> >> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >> > > >>>> >>
> >> > > >>>> >> Cool,
> >> > > >>>> >>
> >> > > >>>> >> I am working on giving my best release time guess as
> possible on the FOSDEM conference!
> >> > > >>>> >>
> >> > > >>>> >> Uwe
> >> > > >>>> >>
> >> > > >>>> >> -----
> >> > > >>>> >> Uwe Schindler
> >> > > >>>> >> Achterdiek 19, D-28357 Bremen
> >> > > >>>> >> http://www.thetaphi.de
> >> > > >>>> >> eMail: uwe@thetaphi.de
> >> > > >>>> >>
> >> > > >>>> >> > -----Original Message-----
> >> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> >> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> >> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> >> > > >>>> >> >
> >> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week
> of February 4th.
> >> > > >>>> >> >
> >> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >
> >> > > >>>> >> > > Hi,
> >> > > >>>> >> > > As we agreed some time ago I'd like to start on
> releasing 8.0. The branch is
> >> > > >>>> >> > already created so we can start the process anytime now.
> Unless there are
> >> > > >>>> >> > objections I'd like to start the feature freeze next week
> in order to build the
> >> > > >>>> >> > first candidate the week after.
> >> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle
> both with Alan so
> >> > > >>>> >> > the question now is whether we are ok to start the
> release process or if there
> >> > > >>>> >> > are any blockers left ;).
> >> > > >>>> >> > >
> >> > > >>>> >> > >
> >> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
> romseygeek@gmail.com>
> >> > > >>>> >> > a écrit :
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> I’ve started to work through the various deprecations
> on the new master
> >> > > >>>> >> > branch.  There are a lot of them, and I’m going to need
> some assistance for
> >> > > >>>> >> > several of them, as it’s not entirely clear what to do.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for
> lucene and one for Solr,
> >> > > >>>> >> > with lists of the deprecations that need to be removed in
> each one.  I’ll create
> >> > > >>>> >> > a shared branch on gitbox to work against, and push the
> changes I’ve already
> >> > > >>>> >> > done there.  We can then create individual JIRA issues
> for any changes that
> >> > > >>>> >> > are more involved than just deleting code.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> All assistance gratefully received, particularly for
> the Solr deprecations
> >> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
> romseygeek@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the
> same time as 8.0, to
> >> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep
> those jobs enabled
> >> > > >>>> >> > for now.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <
> uwe@thetaphi.de> wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> Hi,
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins
> once I have some time
> >> > > >>>> >> > later today.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we
> stop using it
> >> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only
> for bugfixes), or
> >> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the
> latter case I would keep
> >> > > >>>> >> > the jenkins jobs enabled for a while.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> Uwe
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> -----
> >> > > >>>> >> > >> Uwe Schindler
> >> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> >> > > >>>> >> > >> http://www.thetaphi.de
> >> > > >>>> >> > >> eMail: uwe@thetaphi.de
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> >> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >> > > >>>> >> > >> To: dev@lucene.apache.org
> >> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just
> created a branch for 8x
> >> > > >>>> >> > from master, and am in the process of updating the master
> branch to version
> >> > > >>>> >> > 9.  New commits that should be included in the 8.0
> release should also be
> >> > > >>>> >> > back-ported to branch_8x from master.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> This is not intended as a feature freeze, as I know
> there are still some
> >> > > >>>> >> > things being worked on for 8.0; however, it should let us
> clean up master by
> >> > > >>>> >> > removing as much deprecated code as possible, and give us
> an idea of any
> >> > > >>>> >> > replacement work that needs to be done.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> January.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
> sg.online.email@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as
> there is an enhancement
> >> > > >>>> >> > on nested-documents we are waiting to get our hands on.
> >> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> Thx
> >> > > >>>> >> > >> SG
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >> > > >>>> >> > <da...@gmail.com> wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project
> in (SOLR, LUCENE) AND
> >> > > >>>> >> > priority = Blocker and status = open and fixVersion =
> "master (8.0)"
> >> > > >>>> >> > >>    click here:
> >> > > >>>> >> > >>
> >> > > >>>> >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >> > > >>>> >> >
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> Thru the end of the month, I intend to work on those
> issues not yet
> >> > > >>>> >> > assigned.
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
> jpountz@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> +1
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >> > > >>>> >> > <ro...@gmail.com> wrote:
> >> > > >>>> >> > >> >
> >> > > >>>> >> > >> > Hi all,
> >> > > >>>> >> > >> >
> >> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we
> should think about
> >> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll
> volunteer to create the
> >> > > >>>> >> > branch this week - say Wednesday?  Then we should have
> some time to
> >> > > >>>> >> > clean up the master branch and uncover anything that
> still needs to be done
> >> > > >>>> >> > on 8.0 before we start the release process next year.
> >> > > >>>> >> > >> >
> >> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> >> > > >>>> >> > wrote:
> >> > > >>>> >> > >> >
> >> > > >>>> >> > >> > 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
> >> > > >>>> >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> >> > > >>>> >> > 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
> >> > > >>>> >> > <da...@gmail.com> a écrit :
> >> > > >>>> >> > >> >> >>
> >> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >> > > >>>> >> > <nk...@gmail.com> 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
> >> > > >>>> >> > <ca...@gmail.com> 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
> >> > > >>>> >> > <ji...@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
> >> > > >>>> >> > <ca...@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
> >> > > >>>> >> > <ji...@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
> >> > > >>>> >> > <ca...@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
> >> > > >>>> >> > <er...@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
> >> > > >>>> >> > <da...@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
> >> > > >>>> >> > <ji...@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%3DBlocke
> >> > > >>>> >> > r%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
> >> > > >>>> >> > <jp...@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
> >> > > >>>> >> > <jp...@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%3DBlocke
> >> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>
> >> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim
> ferenczi
> >> > > >>>> >> > <ji...@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
> >> > > >>>> >> > <er...@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
> >> > > >>>> >> > <ca...@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
> >> > > >>>> >> > <ji...@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
> >> > > >>>> >> > <da...@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
> >> > > >>>> >> > <jp...@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
> >> > > >>>> >> > <rc...@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 <jp...@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
> >> > > >>>> >> > <jp...@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
> >> > > >>>> >> > <rc...@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 <jp...@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-
> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands,
> e-mail: dev-
> >> > > >>>> >> > help@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> -----------------------------------------------------------
> >> > > >>>> >> > ----------
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands,
> e-mail: dev-
> >> > > >>>> >> > help@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-
> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
> dev-
> >> > > >>>> >> > help@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-
> >> > > >>>> >> > unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >> > > >>>> >> > help@lucene.apache.org
> >> > > >>>> >> > >> >> >>>>>>>>>
> >> > > >>>> >> > >> >> >>> --
> >> > > >>>> >> > >> >> >>>
> >> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> > > >>>> >> > >> >> >>> Apache Lucene Committer
> >> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> > > >>>> >> > >> >>
> >> > > >>>> >> > >> >
> >> > > >>>> >> > >>
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> --
> >> > > >>>> >> > >> Adrien
> >> > > >>>> >> > >>
> >> > > >>>> >> > >>
> ---------------------------------------------------------------------
> >> > > >>>> >> > >> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >> > > >>>> >> > >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> --
> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author,
> Speaker
> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
> >> > > >>>> >> > >>
> >> > > >>>> >> > >> --
> >> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author,
> Speaker
> >> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> > > >>>> >> > http://www.solrenterprisesearchserver.com
> >> > > >>>> >> > >>
> >> > > >>>> >> > >>
> >> > > >>>> >> > >>
> >> > > >>>> >> >
> >> > > >>>> >> >
> >> > > >>>> >> > --
> >> > > >>>> >> > Adrien
> >> > > >>>> >> >
> >> > > >>>> >> >
> ---------------------------------------------------------------------
> >> > > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > > >>>> >> > For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> > > >>>> >>
> >> > > >>>> >>
> >> > > >>>> >>
> ---------------------------------------------------------------------
> >> > > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > > >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> > > >>>> >>
> >> > > >>>> >
> >> > > >>>> >
> >> > > >>>> > --
> >> > > >>>> > http://www.the111shift.com
> >> > > >>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> --
> >> > > >>>> Adrien
> >> > > >>>>
> >> > > >>>>
> ---------------------------------------------------------------------
> >> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> > > >>>>
> >> > > >>>
> >> > > >>>
> >> > > >>> --
> >> > > >>> http://www.the111shift.com
> >> > > >>
> >> > > >>
> >> > > > --
> >> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > -----------------------------------------------------
> >> > > Noble Paul
> >> > >
> >> > >
> >> > >
> ---------------------------------------------------------------------
> >> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > > For additional commands, e-mail: dev-help@lucene.apache.org
> >> > >
> >> >
> >> >
> >> > --
> >> > Adrien
> >> >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >> >
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Tommaso Teofili <to...@gmail.com>]

sure, thanks Jim!

Tommaso

Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
<ji...@gmail.com> ha scritto:
>
> Go ahead Tommaso the branch is not created yet.
> The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and to announce the feature freeze the same day.
> For blocker issues that are still open this leaves another week to work on a patch and we can update the status at the end of the week in order to decide if we can start the first build candidate
> early next week. Would that work for you ?
>
> Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com> a écrit :
>>
>> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
>> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>>
>> Regards,
>> Tommaso
>>
>> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
>> <jp...@gmail.com> ha scritto:
>> >
>> > Hi Noble,
>> >
>> > No it hasn't created yet.
>> >
>> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>> > >
>> > > Is the branch already cut for 8.0? which is it?
>> > >
>> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>> > > >
>> > > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
>> > > > I will work on some documentation for it this week -- SOLR-13129
>> > > >
>> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>> > > >>
>> > > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> > > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> > > >> I'll try to take a look next week.
>> > > >>
>> > > >> --
>> > > >> Jan Høydahl, search solution architect
>> > > >> Cominvent AS - www.cominvent.com
>> > > >>
>> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>> > > >>
>> > > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>> > > >>
>> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>> > > >>>
>> > > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>> > > >>>
>> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>> > > >>>>
>> > > >>>> Releasing a new major is very challenging on its own, I'd rather not
>> > > >>>> call it a blocker and delay the release for it since this isn't a new
>> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
>> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
>> > > >>>> maybe this is something that could get fixed before we build a RC?
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>> > > >>>> >
>> > > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>> > > >>>> >
>> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>> > > >>>> >>
>> > > >>>> >> Cool,
>> > > >>>> >>
>> > > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>> > > >>>> >>
>> > > >>>> >> Uwe
>> > > >>>> >>
>> > > >>>> >> -----
>> > > >>>> >> Uwe Schindler
>> > > >>>> >> Achterdiek 19, D-28357 Bremen
>> > > >>>> >> http://www.thetaphi.de
>> > > >>>> >> eMail: uwe@thetaphi.de
>> > > >>>> >>
>> > > >>>> >> > -----Original Message-----
>> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
>> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
>> > > >>>> >> >
>> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> > > >>>> >> >
>> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >
>> > > >>>> >> > > Hi,
>> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> > > >>>> >> > already created so we can start the process anytime now. Unless there are
>> > > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
>> > > >>>> >> > first candidate the week after.
>> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>> > > >>>> >> > the question now is whether we are ok to start the release process or if there
>> > > >>>> >> > are any blockers left ;).
>> > > >>>> >> > >
>> > > >>>> >> > >
>> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>> > > >>>> >> > a écrit :
>> > > >>>> >> > >>
>> > > >>>> >> > >> I’ve started to work through the various deprecations on the new master
>> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>> > > >>>> >> > several of them, as it’s not entirely clear what to do.
>> > > >>>> >> > >>
>> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> > > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>> > > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>> > > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
>> > > >>>> >> > are more involved than just deleting code.
>> > > >>>> >> > >>
>> > > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
>> > > >>>> >> > >>
>> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> > > >>>> >> > for now.
>> > > >>>> >> > >>
>> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> Hi,
>> > > >>>> >> > >>
>> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>> > > >>>> >> > later today.
>> > > >>>> >> > >>
>> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> > > >>>> >> > the jenkins jobs enabled for a while.
>> > > >>>> >> > >>
>> > > >>>> >> > >> Uwe
>> > > >>>> >> > >>
>> > > >>>> >> > >> -----
>> > > >>>> >> > >> Uwe Schindler
>> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
>> > > >>>> >> > >> http://www.thetaphi.de
>> > > >>>> >> > >> eMail: uwe@thetaphi.de
>> > > >>>> >> > >>
>> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> > > >>>> >> > >> To: dev@lucene.apache.org
>> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
>> > > >>>> >> > >>
>> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> > > >>>> >> > from master, and am in the process of updating the master branch to version
>> > > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>> > > >>>> >> > back-ported to branch_8x from master.
>> > > >>>> >> > >>
>> > > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>> > > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>> > > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
>> > > >>>> >> > replacement work that needs to be done.
>> > > >>>> >> > >>
>> > > >>>> >> > >>
>> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> January.
>> > > >>>> >> > >>
>> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>> > > >>>> >> > on nested-documents we are waiting to get our hands on.
>> > > >>>> >> > >> Any idea when Solr 8 would be out ?
>> > > >>>> >> > >>
>> > > >>>> >> > >> Thx
>> > > >>>> >> > >> SG
>> > > >>>> >> > >>
>> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> > > >>>> >> > <da...@gmail.com> wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> > > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> > > >>>> >> > >>    click here:
>> > > >>>> >> > >>
>> > > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> > > >>>> >> > >>
>> > > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>> > > >>>> >> > assigned.
>> > > >>>> >> > >>
>> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >>
>> > > >>>> >> > >> +1
>> > > >>>> >> > >>
>> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> > > >>>> >> > <ro...@gmail.com> wrote:
>> > > >>>> >> > >> >
>> > > >>>> >> > >> > Hi all,
>> > > >>>> >> > >> >
>> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> > > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
>> > > >>>> >> > clean up the master branch and uncover anything that still needs to be done
>> > > >>>> >> > on 8.0 before we start the release process next year.
>> > > >>>> >> > >> >
>> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> > > >>>> >> > wrote:
>> > > >>>> >> > >> >
>> > > >>>> >> > >> > 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
>> > > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>> > > >>>> >> > 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
>> > > >>>> >> > <da...@gmail.com> a écrit :
>> > > >>>> >> > >> >> >>
>> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> > > >>>> >> > <nk...@gmail.com> 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
>> > > >>>> >> > <ca...@gmail.com> 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
>> > > >>>> >> > <ji...@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
>> > > >>>> >> > <ca...@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
>> > > >>>> >> > <ji...@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
>> > > >>>> >> > <ca...@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
>> > > >>>> >> > <er...@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
>> > > >>>> >> > <da...@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
>> > > >>>> >> > <ji...@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%3DBlocke
>> > > >>>> >> > r%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
>> > > >>>> >> > <jp...@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
>> > > >>>> >> > <jp...@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%3DBlocke
>> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> > > >>>> >> > >> >> >>>>>>>>> >>>>
>> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> > > >>>> >> > <ji...@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
>> > > >>>> >> > <er...@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
>> > > >>>> >> > <ca...@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
>> > > >>>> >> > <ji...@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
>> > > >>>> >> > <da...@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
>> > > >>>> >> > <jp...@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
>> > > >>>> >> > <rc...@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 <jp...@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
>> > > >>>> >> > <jp...@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
>> > > >>>> >> > <rc...@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 <jp...@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-
>> > > >>>> >> > unsubscribe@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>> > > >>>> >> > help@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>> > > >>>> >> > ----------
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>> > > >>>> >> > unsubscribe@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>> > > >>>> >> > help@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-
>> > > >>>> >> > unsubscribe@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>> > > >>>> >> > help@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-
>> > > >>>> >> > unsubscribe@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>> > > >>>> >> > help@lucene.apache.org
>> > > >>>> >> > >> >> >>>>>>>>>
>> > > >>>> >> > >> >> >>> --
>> > > >>>> >> > >> >> >>>
>> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>> > > >>>> >> > >> >> >>> Apache Lucene Committer
>> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> > > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>> >> > >> >>
>> > > >>>> >> > >> >
>> > > >>>> >> > >>
>> > > >>>> >> > >>
>> > > >>>> >> > >> --
>> > > >>>> >> > >> Adrien
>> > > >>>> >> > >>
>> > > >>>> >> > >> ---------------------------------------------------------------------
>> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>> >> > >>
>> > > >>>> >> > >> --
>> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> > > >>>> >> > >>
>> > > >>>> >> > >> --
>> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > > >>>> >> > http://www.solrenterprisesearchserver.com
>> > > >>>> >> > >>
>> > > >>>> >> > >>
>> > > >>>> >> > >>
>> > > >>>> >> >
>> > > >>>> >> >
>> > > >>>> >> > --
>> > > >>>> >> > Adrien
>> > > >>>> >> >
>> > > >>>> >> > ---------------------------------------------------------------------
>> > > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>> >>
>> > > >>>> >>
>> > > >>>> >> ---------------------------------------------------------------------
>> > > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>> >>
>> > > >>>> >
>> > > >>>> >
>> > > >>>> > --
>> > > >>>> > http://www.the111shift.com
>> > > >>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> --
>> > > >>>> Adrien
>> > > >>>>
>> > > >>>> ---------------------------------------------------------------------
>> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> > > >>>>
>> > > >>>
>> > > >>>
>> > > >>> --
>> > > >>> http://www.the111shift.com
>> > > >>
>> > > >>
>> > > > --
>> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>> > >
>> > >
>> > >
>> > > --
>> > > -----------------------------------------------------
>> > > Noble Paul
>> > >
>> > >
>> > > ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > > For additional commands, e-mail: dev-help@lucene.apache.org
>> > >
>> >
>> >
>> > --
>> > Adrien
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Go ahead Tommaso the branch is not created yet.
The plan is to create the branches (7.7 and 8.0)  tomorrow or wednesday and
to announce the feature freeze the same day.
For blocker issues that are still open this leaves another week to work on
a patch and we can update the status at the end of the week in order to
decide if we can start the first build candidate
early next week. Would that work for you ?

Le lun. 28 janv. 2019 à 10:19, Tommaso Teofili <to...@gmail.com>
a écrit :

> I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
> (upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.
>
> Regards,
> Tommaso
>
> Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
> <jp...@gmail.com> ha scritto:
> >
> > Hi Noble,
> >
> > No it hasn't created yet.
> >
> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> > >
> > > Is the branch already cut for 8.0? which is it?
> > >
> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com>
> wrote:
> > > >
> > > > I finally have a patch up for
> https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
> blocker) that I feel pretty good about.  This provides a key part of the
> nested document support.
> > > > I will work on some documentation for it this week -- SOLR-13129
> > > >
> > > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com>
> wrote:
> > > >>
> > > >> I don't think it is critical for this to be a blocker for 8.0. If
> it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > > >> I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> > > >> I'll try to take a look next week.
> > > >>
> > > >> --
> > > >> Jan Høydahl, search solution architect
> > > >> Cominvent AS - www.cominvent.com
> > > >>
> > > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <
> tomasflobbe@gmail.com>:
> > > >>
> > > >> I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
> > > >>
> > > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com>
> wrote:
> > > >>>
> > > >>> It looks like someone tried to make it a blocker once before...
> And it's actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
> > > >>>
> > > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com>
> wrote:
> > > >>>>
> > > >>>> Releasing a new major is very challenging on its own, I'd rather
> not
> > > >>>> call it a blocker and delay the release for it since this isn't a
> new
> > > >>>> regression in 8.0: it looks like a problem that has affected Solr
> > > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> > > >>>> maybe this is something that could get fixed before we build a RC?
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com>
> wrote:
> > > >>>> >
> > > >>>> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> > > >>>> >
> > > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > > >>>> >>
> > > >>>> >> Cool,
> > > >>>> >>
> > > >>>> >> I am working on giving my best release time guess as possible
> on the FOSDEM conference!
> > > >>>> >>
> > > >>>> >> Uwe
> > > >>>> >>
> > > >>>> >> -----
> > > >>>> >> Uwe Schindler
> > > >>>> >> Achterdiek 19, D-28357 Bremen
> > > >>>> >> http://www.thetaphi.de
> > > >>>> >> eMail: uwe@thetaphi.de
> > > >>>> >>
> > > >>>> >> > -----Original Message-----
> > > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> > > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> > > >>>> >> > Subject: Re: Lucene/Solr 8.0
> > > >>>> >> >
> > > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of
> February 4th.
> > > >>>> >> >
> > > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
> jim.ferenczi@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >
> > > >>>> >> > > Hi,
> > > >>>> >> > > As we agreed some time ago I'd like to start on releasing
> 8.0. The branch is
> > > >>>> >> > already created so we can start the process anytime now.
> Unless there are
> > > >>>> >> > objections I'd like to start the feature freeze next week in
> order to build the
> > > >>>> >> > first candidate the week after.
> > > >>>> >> > > We'll also need a 7.7 release but I think we can handle
> both with Alan so
> > > >>>> >> > the question now is whether we are ok to start the release
> process or if there
> > > >>>> >> > are any blockers left ;).
> > > >>>> >> > >
> > > >>>> >> > >
> > > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
> romseygeek@gmail.com>
> > > >>>> >> > a écrit :
> > > >>>> >> > >>
> > > >>>> >> > >> I’ve started to work through the various deprecations on
> the new master
> > > >>>> >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> > > >>>> >> > several of them, as it’s not entirely clear what to do.
> > > >>>> >> > >>
> > > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene
> and one for Solr,
> > > >>>> >> > with lists of the deprecations that need to be removed in
> each one.  I’ll create
> > > >>>> >> > a shared branch on gitbox to work against, and push the
> changes I’ve already
> > > >>>> >> > done there.  We can then create individual JIRA issues for
> any changes that
> > > >>>> >> > are more involved than just deleting code.
> > > >>>> >> > >>
> > > >>>> >> > >> All assistance gratefully received, particularly for the
> Solr deprecations
> > > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> > > >>>> >> > >>
> > > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <
> romseygeek@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> I think the current plan is to do a 7.7 release at the
> same time as 8.0, to
> > > >>>> >> > handle any last-minute deprecations etc.  So let’s keep
> those jobs enabled
> > > >>>> >> > for now.
> > > >>>> >> > >>
> > > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de>
> wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> Hi,
> > > >>>> >> > >>
> > > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I
> have some time
> > > >>>> >> > later today.
> > > >>>> >> > >>
> > > >>>> >> > >> The question: How to proceed with branch_7x? Should we
> stop using it
> > > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> > > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter
> case I would keep
> > > >>>> >> > the jenkins jobs enabled for a while.
> > > >>>> >> > >>
> > > >>>> >> > >> Uwe
> > > >>>> >> > >>
> > > >>>> >> > >> -----
> > > >>>> >> > >> Uwe Schindler
> > > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> > > >>>> >> > >> http://www.thetaphi.de
> > > >>>> >> > >> eMail: uwe@thetaphi.de
> > > >>>> >> > >>
> > > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> > > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> > > >>>> >> > >> To: dev@lucene.apache.org
> > > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> > > >>>> >> > >>
> > > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created
> a branch for 8x
> > > >>>> >> > from master, and am in the process of updating the master
> branch to version
> > > >>>> >> > 9.  New commits that should be included in the 8.0 release
> should also be
> > > >>>> >> > back-ported to branch_8x from master.
> > > >>>> >> > >>
> > > >>>> >> > >> This is not intended as a feature freeze, as I know there
> are still some
> > > >>>> >> > things being worked on for 8.0; however, it should let us
> clean up master by
> > > >>>> >> > removing as much deprecated code as possible, and give us an
> idea of any
> > > >>>> >> > replacement work that needs to be done.
> > > >>>> >> > >>
> > > >>>> >> > >>
> > > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <
> david.w.smiley@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> January.
> > > >>>> >> > >>
> > > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <
> sg.online.email@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> It would be nice to see Solr 8 in January soon as there
> is an enhancement
> > > >>>> >> > on nested-documents we are waiting to get our hands on.
> > > >>>> >> > >> Any idea when Solr 8 would be out ?
> > > >>>> >> > >>
> > > >>>> >> > >> Thx
> > > >>>> >> > >> SG
> > > >>>> >> > >>
> > > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > > >>>> >> > <da...@gmail.com> wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in
> (SOLR, LUCENE) AND
> > > >>>> >> > priority = Blocker and status = open and fixVersion =
> "master (8.0)"
> > > >>>> >> > >>    click here:
> > > >>>> >> > >>
> > > >>>> >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > > >>>> >> > >>
> > > >>>> >> > >> Thru the end of the month, I intend to work on those
> issues not yet
> > > >>>> >> > assigned.
> > > >>>> >> > >>
> > > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <
> jpountz@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >>
> > > >>>> >> > >> +1
> > > >>>> >> > >>
> > > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > > >>>> >> > <ro...@gmail.com> wrote:
> > > >>>> >> > >> >
> > > >>>> >> > >> > Hi all,
> > > >>>> >> > >> >
> > > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we
> should think about
> > > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll
> volunteer to create the
> > > >>>> >> > branch this week - say Wednesday?  Then we should have some
> time to
> > > >>>> >> > clean up the master branch and uncover anything that still
> needs to be done
> > > >>>> >> > on 8.0 before we start the release process next year.
> > > >>>> >> > >> >
> > > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> > > >>>> >> > wrote:
> > > >>>> >> > >> >
> > > >>>> >> > >> > 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
> > > >>>> >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> > > >>>> >> > 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
> > > >>>> >> > <da...@gmail.com> a écrit :
> > > >>>> >> > >> >> >>
> > > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > > >>>> >> > <nk...@gmail.com> 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
> > > >>>> >> > <ca...@gmail.com> 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
> > > >>>> >> > <ji...@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
> > > >>>> >> > <ca...@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
> > > >>>> >> > <ji...@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
> > > >>>> >> > <ca...@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
> > > >>>> >> > <er...@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
> > > >>>> >> > <da...@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
> > > >>>> >> > <ji...@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%3DBlocke
> > > >>>> >> > r%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
> > > >>>> >> > <jp...@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
> > > >>>> >> > <jp...@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%3DBlocke
> > > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> > > >>>> >> > >> >> >>>>>>>>> >>>>
> > > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim
> ferenczi
> > > >>>> >> > <ji...@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
> > > >>>> >> > <er...@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
> > > >>>> >> > <ca...@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
> > > >>>> >> > <ji...@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
> > > >>>> >> > <da...@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
> > > >>>> >> > <jp...@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
> > > >>>> >> > <rc...@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 <jp...@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
> > > >>>> >> > <jp...@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
> > > >>>> >> > <rc...@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 <jp...@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-
> > > >>>> >> > unsubscribe@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands,
> e-mail: dev-
> > > >>>> >> > help@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> -----------------------------------------------------------
> > > >>>> >> > ----------
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> > > >>>> >> > unsubscribe@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands,
> e-mail: dev-
> > > >>>> >> > help@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-
> > > >>>> >> > unsubscribe@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> > > >>>> >> > help@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-
> > > >>>> >> > unsubscribe@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> > > >>>> >> > help@lucene.apache.org
> > > >>>> >> > >> >> >>>>>>>>>
> > > >>>> >> > >> >> >>> --
> > > >>>> >> > >> >> >>>
> > > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> > > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> > > >>>> >> > >> >> >>> Apache Lucene Committer
> > > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> > > >>>> >> > >> >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> > > >>>> >> > >> >>
> > > >>>> >> > >> >
> > > >>>> >> > >>
> > > >>>> >> > >>
> > > >>>> >> > >> --
> > > >>>> >> > >> Adrien
> > > >>>> >> > >>
> > > >>>> >> > >>
> ---------------------------------------------------------------------
> > > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> >> > >> For additional commands, e-mail:
> dev-help@lucene.apache.org
> > > >>>> >> > >>
> > > >>>> >> > >> --
> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author,
> Speaker
> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > > >>>> >> > http://www.solrenterprisesearchserver.com
> > > >>>> >> > >>
> > > >>>> >> > >> --
> > > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author,
> Speaker
> > > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > > >>>> >> > http://www.solrenterprisesearchserver.com
> > > >>>> >> > >>
> > > >>>> >> > >>
> > > >>>> >> > >>
> > > >>>> >> >
> > > >>>> >> >
> > > >>>> >> > --
> > > >>>> >> > Adrien
> > > >>>> >> >
> > > >>>> >> >
> ---------------------------------------------------------------------
> > > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>> >>
> > > >>>> >>
> > > >>>> >>
> ---------------------------------------------------------------------
> > > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>> >>
> > > >>>> >
> > > >>>> >
> > > >>>> > --
> > > >>>> > http://www.the111shift.com
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Adrien
> > > >>>>
> > > >>>>
> ---------------------------------------------------------------------
> > > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > > >>>>
> > > >>>
> > > >>>
> > > >>> --
> > > >>> http://www.the111shift.com
> > > >>
> > > >>
> > > > --
> > > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
> > >
> > >
> > >
> > > --
> > > -----------------------------------------------------
> > > Noble Paul
> > >
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > > For additional commands, e-mail: dev-help@lucene.apache.org
> > >
> >
> >
> > --
> > Adrien
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Tommaso Teofili <to...@gmail.com>]

I'd like to backport https://issues.apache.org/jira/browse/LUCENE-8659
(upgrade to OpenNLP 1.9.1) to 8x branch, if there's still time.

Regards,
Tommaso

Il giorno lun 28 gen 2019 alle ore 07:59 Adrien Grand
<jp...@gmail.com> ha scritto:
>
> Hi Noble,
>
> No it hasn't created yet.
>
> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
> >
> > Is the branch already cut for 8.0? which is it?
> >
> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> > >
> > > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > > I will work on some documentation for it this week -- SOLR-13129
> > >
> > > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> > >>
> > >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> > >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> > >> I'll try to take a look next week.
> > >>
> > >> --
> > >> Jan Høydahl, search solution architect
> > >> Cominvent AS - www.cominvent.com
> > >>
> > >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> > >>
> > >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> > >>
> > >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> > >>>
> > >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> > >>>
> > >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> > >>>>
> > >>>> Releasing a new major is very challenging on its own, I'd rather not
> > >>>> call it a blocker and delay the release for it since this isn't a new
> > >>>> regression in 8.0: it looks like a problem that has affected Solr
> > >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> > >>>> maybe this is something that could get fixed before we build a RC?
> > >>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> > >>>> >
> > >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> > >>>> >
> > >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> > >>>> >>
> > >>>> >> Cool,
> > >>>> >>
> > >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> > >>>> >>
> > >>>> >> Uwe
> > >>>> >>
> > >>>> >> -----
> > >>>> >> Uwe Schindler
> > >>>> >> Achterdiek 19, D-28357 Bremen
> > >>>> >> http://www.thetaphi.de
> > >>>> >> eMail: uwe@thetaphi.de
> > >>>> >>
> > >>>> >> > -----Original Message-----
> > >>>> >> > From: Adrien Grand <jp...@gmail.com>
> > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> > >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> > >>>> >> > Subject: Re: Lucene/Solr 8.0
> > >>>> >> >
> > >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> > >>>> >> >
> > >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >
> > >>>> >> > > Hi,
> > >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> > >>>> >> > already created so we can start the process anytime now. Unless there are
> > >>>> >> > objections I'd like to start the feature freeze next week in order to build the
> > >>>> >> > first candidate the week after.
> > >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> > >>>> >> > the question now is whether we are ok to start the release process or if there
> > >>>> >> > are any blockers left ;).
> > >>>> >> > >
> > >>>> >> > >
> > >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > >>>> >> > a écrit :
> > >>>> >> > >>
> > >>>> >> > >> I’ve started to work through the various deprecations on the new master
> > >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> > >>>> >> > several of them, as it’s not entirely clear what to do.
> > >>>> >> > >>
> > >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> > >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> > >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> > >>>> >> > done there.  We can then create individual JIRA issues for any changes that
> > >>>> >> > are more involved than just deleting code.
> > >>>> >> > >>
> > >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> > >>>> >> > where there’s a lot of code I’m unfamiliar with.
> > >>>> >> > >>
> > >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >>
> > >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> > >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> > >>>> >> > for now.
> > >>>> >> > >>
> > >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > >>>> >> > >>
> > >>>> >> > >> Hi,
> > >>>> >> > >>
> > >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> > >>>> >> > later today.
> > >>>> >> > >>
> > >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> > >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> > >>>> >> > the jenkins jobs enabled for a while.
> > >>>> >> > >>
> > >>>> >> > >> Uwe
> > >>>> >> > >>
> > >>>> >> > >> -----
> > >>>> >> > >> Uwe Schindler
> > >>>> >> > >> Achterdiek 19, D-28357 Bremen
> > >>>> >> > >> http://www.thetaphi.de
> > >>>> >> > >> eMail: uwe@thetaphi.de
> > >>>> >> > >>
> > >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> > >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> > >>>> >> > >> To: dev@lucene.apache.org
> > >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> > >>>> >> > >>
> > >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> > >>>> >> > from master, and am in the process of updating the master branch to version
> > >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
> > >>>> >> > back-ported to branch_8x from master.
> > >>>> >> > >>
> > >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
> > >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
> > >>>> >> > removing as much deprecated code as possible, and give us an idea of any
> > >>>> >> > replacement work that needs to be done.
> > >>>> >> > >>
> > >>>> >> > >>
> > >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >>
> > >>>> >> > >> January.
> > >>>> >> > >>
> > >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >>
> > >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> > >>>> >> > on nested-documents we are waiting to get our hands on.
> > >>>> >> > >> Any idea when Solr 8 would be out ?
> > >>>> >> > >>
> > >>>> >> > >> Thx
> > >>>> >> > >> SG
> > >>>> >> > >>
> > >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > >>>> >> > <da...@gmail.com> wrote:
> > >>>> >> > >>
> > >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> > >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >>>> >> > >>    click here:
> > >>>> >> > >>
> > >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >>>> >> > >>
> > >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
> > >>>> >> > assigned.
> > >>>> >> > >>
> > >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >>
> > >>>> >> > >> +1
> > >>>> >> > >>
> > >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > >>>> >> > <ro...@gmail.com> wrote:
> > >>>> >> > >> >
> > >>>> >> > >> > Hi all,
> > >>>> >> > >> >
> > >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> > >>>> >> > branch this week - say Wednesday?  Then we should have some time to
> > >>>> >> > clean up the master branch and uncover anything that still needs to be done
> > >>>> >> > on 8.0 before we start the release process next year.
> > >>>> >> > >> >
> > >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > >>>> >> > wrote:
> > >>>> >> > >> >
> > >>>> >> > >> > 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
> > >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> > >>>> >> > 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
> > >>>> >> > <da...@gmail.com> a écrit :
> > >>>> >> > >> >> >>
> > >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > >>>> >> > <nk...@gmail.com> 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
> > >>>> >> > <ca...@gmail.com> 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
> > >>>> >> > <ji...@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
> > >>>> >> > <ca...@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
> > >>>> >> > <ji...@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
> > >>>> >> > <ca...@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
> > >>>> >> > <er...@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
> > >>>> >> > <da...@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
> > >>>> >> > <ji...@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%3DBlocke
> > >>>> >> > r%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
> > >>>> >> > <jp...@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
> > >>>> >> > <jp...@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%3DBlocke
> > >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> > >>>> >> > >> >> >>>>>>>>> >>>>
> > >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > >>>> >> > <ji...@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
> > >>>> >> > <er...@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
> > >>>> >> > <ca...@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
> > >>>> >> > <ji...@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
> > >>>> >> > <da...@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
> > >>>> >> > <jp...@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
> > >>>> >> > <rc...@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 <jp...@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
> > >>>> >> > <jp...@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
> > >>>> >> > <rc...@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 <jp...@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-
> > >>>> >> > unsubscribe@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> > >>>> >> > help@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
> > >>>> >> > ----------
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> > >>>> >> > unsubscribe@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> > >>>> >> > help@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-
> > >>>> >> > unsubscribe@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> > >>>> >> > help@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-
> > >>>> >> > unsubscribe@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> > >>>> >> > help@lucene.apache.org
> > >>>> >> > >> >> >>>>>>>>>
> > >>>> >> > >> >> >>> --
> > >>>> >> > >> >> >>>
> > >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> > >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> > >>>> >> > >> >> >>> Apache Lucene Committer
> > >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> > >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>> >> > >> >>
> > >>>> >> > >> >
> > >>>> >> > >>
> > >>>> >> > >>
> > >>>> >> > >> --
> > >>>> >> > >> Adrien
> > >>>> >> > >>
> > >>>> >> > >> ---------------------------------------------------------------------
> > >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>> >> > >>
> > >>>> >> > >> --
> > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > >>>> >> > http://www.solrenterprisesearchserver.com
> > >>>> >> > >>
> > >>>> >> > >> --
> > >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > >>>> >> > http://www.solrenterprisesearchserver.com
> > >>>> >> > >>
> > >>>> >> > >>
> > >>>> >> > >>
> > >>>> >> >
> > >>>> >> >
> > >>>> >> > --
> > >>>> >> > Adrien
> > >>>> >> >
> > >>>> >> > ---------------------------------------------------------------------
> > >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>> >>
> > >>>> >>
> > >>>> >> ---------------------------------------------------------------------
> > >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>> >>
> > >>>> >
> > >>>> >
> > >>>> > --
> > >>>> > http://www.the111shift.com
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Adrien
> > >>>>
> > >>>> ---------------------------------------------------------------------
> > >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>>>
> > >>>
> > >>>
> > >>> --
> > >>> http://www.the111shift.com
> > >>
> > >>
> > > --
> > > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
> >
> >
> >
> > --
> > -----------------------------------------------------
> > Noble Paul
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
> >
>
>
> --
> Adrien
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

Hi Noble,

No it hasn't created yet.

On Mon, Jan 28, 2019 at 3:55 AM Noble Paul <no...@gmail.com> wrote:
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
> >
> > I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> > I will work on some documentation for it this week -- SOLR-13129
> >
> > On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
> >>
> >> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
> >> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
> >> I'll try to take a look next week.
> >>
> >> --
> >> Jan Høydahl, search solution architect
> >> Cominvent AS - www.cominvent.com
> >>
> >> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> >>
> >> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> >>
> >> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
> >>>
> >>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> >>>
> >>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
> >>>>
> >>>> Releasing a new major is very challenging on its own, I'd rather not
> >>>> call it a blocker and delay the release for it since this isn't a new
> >>>> regression in 8.0: it looks like a problem that has affected Solr
> >>>> since at least 6.3? I'm not familiar with the UI code at all, but
> >>>> maybe this is something that could get fixed before we build a RC?
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >>>> >
> >>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
> >>>> >
> >>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >>>> >>
> >>>> >> Cool,
> >>>> >>
> >>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> >>>> >>
> >>>> >> Uwe
> >>>> >>
> >>>> >> -----
> >>>> >> Uwe Schindler
> >>>> >> Achterdiek 19, D-28357 Bremen
> >>>> >> http://www.thetaphi.de
> >>>> >> eMail: uwe@thetaphi.de
> >>>> >>
> >>>> >> > -----Original Message-----
> >>>> >> > From: Adrien Grand <jp...@gmail.com>
> >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >>>> >> > To: Lucene Dev <de...@lucene.apache.org>
> >>>> >> > Subject: Re: Lucene/Solr 8.0
> >>>> >> >
> >>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >>>> >> >
> >>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >
> >>>> >> > > Hi,
> >>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> >>>> >> > already created so we can start the process anytime now. Unless there are
> >>>> >> > objections I'd like to start the feature freeze next week in order to build the
> >>>> >> > first candidate the week after.
> >>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> >>>> >> > the question now is whether we are ok to start the release process or if there
> >>>> >> > are any blockers left ;).
> >>>> >> > >
> >>>> >> > >
> >>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >>>> >> > a écrit :
> >>>> >> > >>
> >>>> >> > >> I’ve started to work through the various deprecations on the new master
> >>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> >>>> >> > several of them, as it’s not entirely clear what to do.
> >>>> >> > >>
> >>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> >>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> >>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> >>>> >> > done there.  We can then create individual JIRA issues for any changes that
> >>>> >> > are more involved than just deleting code.
> >>>> >> > >>
> >>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> >>>> >> > where there’s a lot of code I’m unfamiliar with.
> >>>> >> > >>
> >>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >>
> >>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> >>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> >>>> >> > for now.
> >>>> >> > >>
> >>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >>>> >> > >>
> >>>> >> > >> Hi,
> >>>> >> > >>
> >>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> >>>> >> > later today.
> >>>> >> > >>
> >>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> >>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> >>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> >>>> >> > the jenkins jobs enabled for a while.
> >>>> >> > >>
> >>>> >> > >> Uwe
> >>>> >> > >>
> >>>> >> > >> -----
> >>>> >> > >> Uwe Schindler
> >>>> >> > >> Achterdiek 19, D-28357 Bremen
> >>>> >> > >> http://www.thetaphi.de
> >>>> >> > >> eMail: uwe@thetaphi.de
> >>>> >> > >>
> >>>> >> > >> From: Alan Woodward <ro...@gmail.com>
> >>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >>>> >> > >> To: dev@lucene.apache.org
> >>>> >> > >> Subject: Re: Lucene/Solr 8.0
> >>>> >> > >>
> >>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >>>> >> > from master, and am in the process of updating the master branch to version
> >>>> >> > 9.  New commits that should be included in the 8.0 release should also be
> >>>> >> > back-ported to branch_8x from master.
> >>>> >> > >>
> >>>> >> > >> This is not intended as a feature freeze, as I know there are still some
> >>>> >> > things being worked on for 8.0; however, it should let us clean up master by
> >>>> >> > removing as much deprecated code as possible, and give us an idea of any
> >>>> >> > replacement work that needs to be done.
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >>
> >>>> >> > >> January.
> >>>> >> > >>
> >>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >>
> >>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> >>>> >> > on nested-documents we are waiting to get our hands on.
> >>>> >> > >> Any idea when Solr 8 would be out ?
> >>>> >> > >>
> >>>> >> > >> Thx
> >>>> >> > >> SG
> >>>> >> > >>
> >>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >>>> >> > <da...@gmail.com> wrote:
> >>>> >> > >>
> >>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> >>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >>>> >> > >>    click here:
> >>>> >> > >>
> >>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >>>> >> > >>
> >>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
> >>>> >> > assigned.
> >>>> >> > >>
> >>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >>
> >>>> >> > >> +1
> >>>> >> > >>
> >>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >>>> >> > <ro...@gmail.com> wrote:
> >>>> >> > >> >
> >>>> >> > >> > Hi all,
> >>>> >> > >> >
> >>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> >>>> >> > branch this week - say Wednesday?  Then we should have some time to
> >>>> >> > clean up the master branch and uncover anything that still needs to be done
> >>>> >> > on 8.0 before we start the release process next year.
> >>>> >> > >> >
> >>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> >>>> >> > wrote:
> >>>> >> > >> >
> >>>> >> > >> > 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
> >>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
> >>>> >> > 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
> >>>> >> > <da...@gmail.com> a écrit :
> >>>> >> > >> >> >>
> >>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >>>> >> > <nk...@gmail.com> 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
> >>>> >> > <ca...@gmail.com> 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
> >>>> >> > <ji...@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
> >>>> >> > <ca...@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
> >>>> >> > <ji...@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
> >>>> >> > <ca...@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
> >>>> >> > <er...@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
> >>>> >> > <da...@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
> >>>> >> > <ji...@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%3DBlocke
> >>>> >> > r%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
> >>>> >> > <jp...@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
> >>>> >> > <jp...@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%3DBlocke
> >>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >>>> >> > >> >> >>>>>>>>> >>>>
> >>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >>>> >> > <ji...@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
> >>>> >> > <er...@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
> >>>> >> > <ca...@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
> >>>> >> > <ji...@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
> >>>> >> > <da...@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
> >>>> >> > <jp...@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
> >>>> >> > <rc...@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 <jp...@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
> >>>> >> > <jp...@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
> >>>> >> > <rc...@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 <jp...@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-
> >>>> >> > unsubscribe@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> >>>> >> > help@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
> >>>> >> > ----------
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> >>>> >> > unsubscribe@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> >>>> >> > help@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-
> >>>> >> > unsubscribe@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> >>>> >> > help@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-
> >>>> >> > unsubscribe@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >>>> >> > help@lucene.apache.org
> >>>> >> > >> >> >>>>>>>>>
> >>>> >> > >> >> >>> --
> >>>> >> > >> >> >>>
> >>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >>>> >> > >> >> >>> Apache Lucene Committer
> >>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >> > >> >>
> >>>> >> > >> >
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >> --
> >>>> >> > >> Adrien
> >>>> >> > >>
> >>>> >> > >> ---------------------------------------------------------------------
> >>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >> > >>
> >>>> >> > >> --
> >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >>>> >> > http://www.solrenterprisesearchserver.com
> >>>> >> > >>
> >>>> >> > >> --
> >>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >>>> >> > http://www.solrenterprisesearchserver.com
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> > >>
> >>>> >> >
> >>>> >> >
> >>>> >> > --
> >>>> >> > Adrien
> >>>> >> >
> >>>> >> > ---------------------------------------------------------------------
> >>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >>
> >>>> >>
> >>>> >> ---------------------------------------------------------------------
> >>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>> >>
> >>>> >
> >>>> >
> >>>> > --
> >>>> > http://www.the111shift.com
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Adrien
> >>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>
> >>>
> >>>
> >>> --
> >>> http://www.the111shift.com
> >>
> >>
> > --
> > Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>
>
>
> --
> -----------------------------------------------------
> Noble Paul
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>


-- 
Adrien


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Noble Paul <no...@gmail.com>]

Is the branch already cut for 8.0? which is it?

On Mon, Jan 28, 2019 at 4:03 AM David Smiley <da...@gmail.com> wrote:
>
> I finally have a patch up for https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0 blocker) that I feel pretty good about.  This provides a key part of the nested document support.
> I will work on some documentation for it this week -- SOLR-13129
>
> On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:
>>
>> I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
>> I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
>> I'll try to take a look next week.
>>
>> --
>> Jan Høydahl, search solution architect
>> Cominvent AS - www.cominvent.com
>>
>> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
>>
>> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
>>
>> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>>>
>>> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
>>>
>>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>>>
>>>> Releasing a new major is very challenging on its own, I'd rather not
>>>> call it a blocker and delay the release for it since this isn't a new
>>>> regression in 8.0: it looks like a problem that has affected Solr
>>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>>> maybe this is something that could get fixed before we build a RC?
>>>>
>>>>
>>>>
>>>>
>>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>>> >
>>>> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>>>> >
>>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> >>
>>>> >> Cool,
>>>> >>
>>>> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>>> >>
>>>> >> Uwe
>>>> >>
>>>> >> -----
>>>> >> Uwe Schindler
>>>> >> Achterdiek 19, D-28357 Bremen
>>>> >> http://www.thetaphi.de
>>>> >> eMail: uwe@thetaphi.de
>>>> >>
>>>> >> > -----Original Message-----
>>>> >> > From: Adrien Grand <jp...@gmail.com>
>>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>>> >> > Subject: Re: Lucene/Solr 8.0
>>>> >> >
>>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>>>> >> >
>>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>>>> >> > wrote:
>>>> >> > >
>>>> >> > > Hi,
>>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>>>> >> > already created so we can start the process anytime now. Unless there are
>>>> >> > objections I'd like to start the feature freeze next week in order to build the
>>>> >> > first candidate the week after.
>>>> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>>>> >> > the question now is whether we are ok to start the release process or if there
>>>> >> > are any blockers left ;).
>>>> >> > >
>>>> >> > >
>>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>>>> >> > a écrit :
>>>> >> > >>
>>>> >> > >> I’ve started to work through the various deprecations on the new master
>>>> >> > branch.  There are a lot of them, and I’m going to need some assistance for
>>>> >> > several of them, as it’s not entirely clear what to do.
>>>> >> > >>
>>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>>>> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
>>>> >> > a shared branch on gitbox to work against, and push the changes I’ve already
>>>> >> > done there.  We can then create individual JIRA issues for any changes that
>>>> >> > are more involved than just deleting code.
>>>> >> > >>
>>>> >> > >> All assistance gratefully received, particularly for the Solr deprecations
>>>> >> > where there’s a lot of code I’m unfamiliar with.
>>>> >> > >>
>>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>>> >> > wrote:
>>>> >> > >>
>>>> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>>>> >> > for now.
>>>> >> > >>
>>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>>> >> > >>
>>>> >> > >> Hi,
>>>> >> > >>
>>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>>>> >> > later today.
>>>> >> > >>
>>>> >> > >> The question: How to proceed with branch_7x? Should we stop using it
>>>> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>>>> >> > the jenkins jobs enabled for a while.
>>>> >> > >>
>>>> >> > >> Uwe
>>>> >> > >>
>>>> >> > >> -----
>>>> >> > >> Uwe Schindler
>>>> >> > >> Achterdiek 19, D-28357 Bremen
>>>> >> > >> http://www.thetaphi.de
>>>> >> > >> eMail: uwe@thetaphi.de
>>>> >> > >>
>>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>>> >> > >> To: dev@lucene.apache.org
>>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>>> >> > >>
>>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>>>> >> > from master, and am in the process of updating the master branch to version
>>>> >> > 9.  New commits that should be included in the 8.0 release should also be
>>>> >> > back-ported to branch_8x from master.
>>>> >> > >>
>>>> >> > >> This is not intended as a feature freeze, as I know there are still some
>>>> >> > things being worked on for 8.0; however, it should let us clean up master by
>>>> >> > removing as much deprecated code as possible, and give us an idea of any
>>>> >> > replacement work that needs to be done.
>>>> >> > >>
>>>> >> > >>
>>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>>>> >> > wrote:
>>>> >> > >>
>>>> >> > >> January.
>>>> >> > >>
>>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>>> >> > wrote:
>>>> >> > >>
>>>> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>>>> >> > on nested-documents we are waiting to get our hands on.
>>>> >> > >> Any idea when Solr 8 would be out ?
>>>> >> > >>
>>>> >> > >> Thx
>>>> >> > >> SG
>>>> >> > >>
>>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>>> >> > <da...@gmail.com> wrote:
>>>> >> > >>
>>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>>> >> > >>    click here:
>>>> >> > >>
>>>> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>>> >> > >>
>>>> >> > >> Thru the end of the month, I intend to work on those issues not yet
>>>> >> > assigned.
>>>> >> > >>
>>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>>> >> > wrote:
>>>> >> > >>
>>>> >> > >> +1
>>>> >> > >>
>>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>>> >> > <ro...@gmail.com> wrote:
>>>> >> > >> >
>>>> >> > >> > Hi all,
>>>> >> > >> >
>>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>>> >> > clean up the master branch and uncover anything that still needs to be done
>>>> >> > on 8.0 before we start the release process next year.
>>>> >> > >> >
>>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>>> >> > wrote:
>>>> >> > >> >
>>>> >> > >> > 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
>>>> >> > <er...@gmail.com> 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 <ji...@gmail.com>
>>>> >> > 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
>>>> >> > <da...@gmail.com> a écrit :
>>>> >> > >> >> >>
>>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>>> >> > <nk...@gmail.com> 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
>>>> >> > <ca...@gmail.com> 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
>>>> >> > <ji...@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
>>>> >> > <ca...@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
>>>> >> > <ji...@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
>>>> >> > <ca...@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
>>>> >> > <er...@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
>>>> >> > <da...@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
>>>> >> > <ji...@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%3DBlocke
>>>> >> > r%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
>>>> >> > <jp...@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
>>>> >> > <jp...@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%3DBlocke
>>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>>> >> > >> >> >>>>>>>>> >>>>
>>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>>> >> > <ji...@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
>>>> >> > <er...@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
>>>> >> > <ca...@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
>>>> >> > <ji...@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
>>>> >> > <da...@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
>>>> >> > <jp...@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
>>>> >> > <rc...@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 <jp...@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
>>>> >> > <jp...@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
>>>> >> > <rc...@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 <jp...@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-
>>>> >> > unsubscribe@lucene.apache.org
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>>>> >> > help@lucene.apache.org
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>>>> >> > ----------
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>>> >> > unsubscribe@lucene.apache.org
>>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>>> >> > help@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-
>>>> >> > unsubscribe@lucene.apache.org
>>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>>> >> > help@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-
>>>> >> > unsubscribe@lucene.apache.org
>>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>>> >> > help@lucene.apache.org
>>>> >> > >> >> >>>>>>>>>
>>>> >> > >> >> >>> --
>>>> >> > >> >> >>>
>>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>>> >> > >> >> >>> Apache Lucene Committer
>>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >> > >> >>
>>>> >> > >> >
>>>> >> > >>
>>>> >> > >>
>>>> >> > >> --
>>>> >> > >> Adrien
>>>> >> > >>
>>>> >> > >> ---------------------------------------------------------------------
>>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >> > >>
>>>> >> > >> --
>>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>> >> > http://www.solrenterprisesearchserver.com
>>>> >> > >>
>>>> >> > >> --
>>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>>> >> > http://www.solrenterprisesearchserver.com
>>>> >> > >>
>>>> >> > >>
>>>> >> > >>
>>>> >> >
>>>> >> >
>>>> >> > --
>>>> >> > Adrien
>>>> >> >
>>>> >> > ---------------------------------------------------------------------
>>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>
>>>> >>
>>>> >> ---------------------------------------------------------------------
>>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>>> >>
>>>> >
>>>> >
>>>> > --
>>>> > http://www.the111shift.com
>>>>
>>>>
>>>>
>>>> --
>>>> Adrien
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>
>>>
>>> --
>>> http://www.the111shift.com
>>
>>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com



-- 
-----------------------------------------------------
Noble Paul


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

I finally have a patch up for
https://issues.apache.org/jira/browse/SOLR-12768 (already marked as 8.0
blocker) that I feel pretty good about.  This provides a key part of the
nested document support.
I will work on some documentation for it this week -- SOLR-13129

On Fri, Jan 25, 2019 at 3:07 PM Jan Høydahl <ja...@cominvent.com> wrote:

> I don't think it is critical for this to be a blocker for 8.0. If it gets
> fixed in 8.0.1 that's ok too, given this is an ooold bug.
> I think we should simply remove the buffering feature in the UI and
> replace it with an error message popup or something.
> I'll try to take a look next week.
>
> --
> Jan Høydahl, search solution architect
> Cominvent AS - www.cominvent.com
>
> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <tomasflobbe@gmail.com
> >:
>
> I think the UI is an important Solr feature. As long as there is a
> reasonable time horizon for the issue being resolved I'm +1 on making it a
> blocker. I'm not familiar enough with the UI code to help either
> unfortunately.
>
> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:
>
>> It looks like someone tried to make it a blocker once before... And it's
>> actually a duplicate of an earlier issue (
>> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
>> of whether or not overall quality has a bearing on the decision to release.
>> As it turns out the screen shot I posted to the issue is less than half of
>> the shards that eventually got created since there was an outstanding queue
>> of requests still processing at the time. I'm now having to delete 50 or so
>> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
>> cores we'll be testing on in the near future. It more or less makes it
>> impossible to recommend the use of the admin UI for anything other than
>> read only observation of the cluster. Now imagine someone leaves a browser
>> window open and forgets about it rather than browsing away or closing the
>> window, not knowing that it's silently pumping out requests after showing
>> an error... would completely hose a node, and until they tracked down the
>> source of the requests, (hope he didn't go home) it would be impossible to
>> resolve...
>>
>> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>>
>>> Releasing a new major is very challenging on its own, I'd rather not
>>> call it a blocker and delay the release for it since this isn't a new
>>> regression in 8.0: it looks like a problem that has affected Solr
>>> since at least 6.3? I'm not familiar with the UI code at all, but
>>> maybe this is something that could get fixed before we build a RC?
>>>
>>>
>>>
>>>
>>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>>> >
>>> > I'd like to suggest that
>>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>>> 8.0. I just got burned by it a second time.
>>> >
>>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >>
>>> >> Cool,
>>> >>
>>> >> I am working on giving my best release time guess as possible on the
>>> FOSDEM conference!
>>> >>
>>> >> Uwe
>>> >>
>>> >> -----
>>> >> Uwe Schindler
>>> >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >> http://www.thetaphi.de
>>> >> eMail: uwe@thetaphi.de
>>> >>
>>> >> > -----Original Message-----
>>> >> > From: Adrien Grand <jp...@gmail.com>
>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >> > To: Lucene Dev <de...@lucene.apache.org>
>>> >> > Subject: Re: Lucene/Solr 8.0
>>> >> >
>>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
>>> 4th.
>>> >> >
>>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <
>>> jim.ferenczi@gmail.com>
>>> >> > wrote:
>>> >> > >
>>> >> > > Hi,
>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0.
>>> The branch is
>>> >> > already created so we can start the process anytime now. Unless
>>> there are
>>> >> > objections I'd like to start the feature freeze next week in order
>>> to build the
>>> >> > first candidate the week after.
>>> >> > > We'll also need a 7.7 release but I think we can handle both with
>>> Alan so
>>> >> > the question now is whether we are ok to start the release process
>>> or if there
>>> >> > are any blockers left ;).
>>> >> > >
>>> >> > >
>>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <
>>> romseygeek@gmail.com>
>>> >> > a écrit :
>>> >> > >>
>>> >> > >> I’ve started to work through the various deprecations on the new
>>> master
>>> >> > branch.  There are a lot of them, and I’m going to need some
>>> assistance for
>>> >> > several of them, as it’s not entirely clear what to do.
>>> >> > >>
>>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one
>>> for Solr,
>>> >> > with lists of the deprecations that need to be removed in each
>>> one.  I’ll create
>>> >> > a shared branch on gitbox to work against, and push the changes
>>> I’ve already
>>> >> > done there.  We can then create individual JIRA issues for any
>>> changes that
>>> >> > are more involved than just deleting code.
>>> >> > >>
>>> >> > >> All assistance gratefully received, particularly for the Solr
>>> deprecations
>>> >> > where there’s a lot of code I’m unfamiliar with.
>>> >> > >>
>>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> I think the current plan is to do a 7.7 release at the same time
>>> as 8.0, to
>>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs
>>> enabled
>>> >> > for now.
>>> >> > >>
>>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>> >> > >>
>>> >> > >> Hi,
>>> >> > >>
>>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have
>>> some time
>>> >> > later today.
>>> >> > >>
>>> >> > >> The question: How to proceed with branch_7x? Should we stop
>>> using it
>>> >> > and release 7.6.x only (so we would use branch_7_6 only for
>>> bugfixes), or
>>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
>>> would keep
>>> >> > the jenkins jobs enabled for a while.
>>> >> > >>
>>> >> > >> Uwe
>>> >> > >>
>>> >> > >> -----
>>> >> > >> Uwe Schindler
>>> >> > >> Achterdiek 19, D-28357 Bremen
>>> <https://maps.google.com/?q=Achterdiek+19,+D-28357+Bremen&entry=gmail&source=g>
>>> >> > >> http://www.thetaphi.de
>>> >> > >> eMail: uwe@thetaphi.de
>>> >> > >>
>>> >> > >> From: Alan Woodward <ro...@gmail.com>
>>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>>> >> > >> To: dev@lucene.apache.org
>>> >> > >> Subject: Re: Lucene/Solr 8.0
>>> >> > >>
>>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a
>>> branch for 8x
>>> >> > from master, and am in the process of updating the master branch to
>>> version
>>> >> > 9.  New commits that should be included in the 8.0 release should
>>> also be
>>> >> > back-ported to branch_8x from master.
>>> >> > >>
>>> >> > >> This is not intended as a feature freeze, as I know there are
>>> still some
>>> >> > things being worked on for 8.0; however, it should let us clean up
>>> master by
>>> >> > removing as much deprecated code as possible, and give us an idea
>>> of any
>>> >> > replacement work that needs to be done.
>>> >> > >>
>>> >> > >>
>>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com
>>> >
>>> >> > wrote:
>>> >> > >>
>>> >> > >> January.
>>> >> > >>
>>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> It would be nice to see Solr 8 in January soon as there is an
>>> enhancement
>>> >> > on nested-documents we are waiting to get our hands on.
>>> >> > >> Any idea when Solr 8 would be out ?
>>> >> > >>
>>> >> > >> Thx
>>> >> > >> SG
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>>> >> > <da...@gmail.com> wrote:
>>> >> > >>
>>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR,
>>> LUCENE) AND
>>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>>> >> > >>    click here:
>>> >> > >>
>>> >> >
>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>> >> > >>
>>> >> > >> Thru the end of the month, I intend to work on those issues not
>>> yet
>>> >> > assigned.
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>>> >> > wrote:
>>> >> > >>
>>> >> > >> +1
>>> >> > >>
>>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>>> >> > <ro...@gmail.com> wrote:
>>> >> > >> >
>>> >> > >> > Hi all,
>>> >> > >> >
>>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think
>>> about
>>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
>>> create the
>>> >> > branch this week - say Wednesday?  Then we should have some time to
>>> >> > clean up the master branch and uncover anything that still needs to
>>> be done
>>> >> > on 8.0 before we start the release process next year.
>>> >> > >> >
>>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
>>> casstargett@gmail.com>
>>> >> > wrote:
>>> >> > >> >
>>> >> > >> > 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
>>> >> > <er...@gmail.com> 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 <
>>> jim.ferenczi@gmail.com>
>>> >> > 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
>>> >> > <da...@gmail.com> a écrit :
>>> >> > >> >> >>
>>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>>> >> > <nk...@gmail.com> 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
>>> >> > <ca...@gmail.com> 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
>>> >> > <ji...@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
>>> >> > <ca...@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
>>> >> > <ji...@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
>>> >> > <ca...@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
>>> >> > <er...@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
>>> >> > <da...@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
>>> >> > <ji...@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%3DBlocke
>>> >> > r%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
>>> >> > <jp...@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
>>> >> > <jp...@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%3DBlocke
>>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>>> >> > >> >> >>>>>>>>> >>>>
>>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>>> >> > <ji...@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
>>> >> > <er...@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
>>> >> > <ca...@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
>>> >> > <ji...@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
>>> >> > <da...@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
>>> >> > <jp...@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
>>> >> > <rc...@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 <jp...@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
>>> >> > <jp...@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
>>> >> > <rc...@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 <jp...@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>> dev-
>>> >> > help@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>>> -----------------------------------------------------------
>>> >> > ----------
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>>> >> > help@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>>> >> > help@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-
>>> >> > unsubscribe@lucene.apache.org
>>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>>> >> > help@lucene.apache.org
>>> >> > >> >> >>>>>>>>>
>>> >> > >> >> >>> --
>>> >> > >> >> >>>
>>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >> > >> >> >>> Apache Lucene Committer
>>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > >> >>
>>> >> > >> >
>>> >> > >>
>>> >> > >>
>>> >> > >> --
>>> >> > >> Adrien
>>> >> > >>
>>> >> > >>
>>> ---------------------------------------------------------------------
>>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> > >>
>>> >> > >> --
>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > >>
>>> >> > >> --
>>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>>> >> > http://www.solrenterprisesearchserver.com
>>> >> > >>
>>> >> > >>
>>> >> > >>
>>> >> >
>>> >> >
>>> >> > --
>>> >> > Adrien
>>> >> >
>>> >> >
>>> ---------------------------------------------------------------------
>>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >>
>>> >> ---------------------------------------------------------------------
>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >
>>> >
>>> > --
>>> > http://www.the111shift.com
>>>
>>>
>>>
>>> --
>>> Adrien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>
>>
>> --
>> http://www.the111shift.com
>>
>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Jan Høydahl <ja...@cominvent.com>]

I don't think it is critical for this to be a blocker for 8.0. If it gets fixed in 8.0.1 that's ok too, given this is an ooold bug.
I think we should simply remove the buffering feature in the UI and replace it with an error message popup or something.
I'll try to take a look next week.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

> 25. jan. 2019 kl. 20:39 skrev Tomás Fernández Löbbe <to...@gmail.com>:
> 
> I think the UI is an important Solr feature. As long as there is a reasonable time horizon for the issue being resolved I'm +1 on making it a blocker. I'm not familiar enough with the UI code to help either unfortunately.
> 
> On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
> It looks like someone tried to make it a blocker once before... And it's actually a duplicate of an earlier issue (https://issues.apache.org/jira/browse/SOLR-9818 <https://issues.apache.org/jira/browse/SOLR-9818>). I guess its a question of whether or not overall quality has a bearing on the decision to release. As it turns out the screen shot I posted to the issue is less than half of the shards that eventually got created since there was an outstanding queue of requests still processing at the time. I'm now having to delete 50 or so cores, which luckily are small 100 Mb initial testing cores, not the 20GB cores we'll be testing on in the near future. It more or less makes it impossible to recommend the use of the admin UI for anything other than read only observation of the cluster. Now imagine someone leaves a browser window open and forgets about it rather than browsing away or closing the window, not knowing that it's silently pumping out requests after showing an error... would completely hose a node, and until they tracked down the source of the requests, (hope he didn't go home) it would be impossible to resolve...
> 
> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
> Releasing a new major is very challenging on its own, I'd rather not
> call it a blocker and delay the release for it since this isn't a new
> regression in 8.0: it looks like a problem that has affected Solr
> since at least 6.3? I'm not familiar with the UI code at all, but
> maybe this is something that could get fixed before we build a RC?
> 
> 
> 
> 
> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gus.heck@gmail.com <ma...@gmail.com>> wrote:
> >
> > I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 <https://issues.apache.org/jira/browse/SOLR-10211> be promoted to block 8.0. I just got burned by it a second time.
> >
> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
> >>
> >> Cool,
> >>
> >> I am working on giving my best release time guess as possible on the FOSDEM conference!
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> http://www.thetaphi.de <http://www.thetaphi.de/>
> >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
> >>
> >> > -----Original Message-----
> >> > From: Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > To: Lucene Dev <dev@lucene.apache.org <ma...@lucene.apache.org>>
> >> > Subject: Re: Lucene/Solr 8.0
> >> >
> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >> >
> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >
> >> > > Hi,
> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> >> > already created so we can start the process anytime now. Unless there are
> >> > objections I'd like to start the feature freeze next week in order to build the
> >> > first candidate the week after.
> >> > > We'll also need a 7.7 release but I think we can handle both with Alan so
> >> > the question now is whether we are ok to start the release process or if there
> >> > are any blockers left ;).
> >> > >
> >> > >
> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> >> > a écrit :
> >> > >>
> >> > >> I’ve started to work through the various deprecations on the new master
> >> > branch.  There are a lot of them, and I’m going to need some assistance for
> >> > several of them, as it’s not entirely clear what to do.
> >> > >>
> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> >> > with lists of the deprecations that need to be removed in each one.  I’ll create
> >> > a shared branch on gitbox to work against, and push the changes I’ve already
> >> > done there.  We can then create individual JIRA issues for any changes that
> >> > are more involved than just deleting code.
> >> > >>
> >> > >> All assistance gratefully received, particularly for the Solr deprecations
> >> > where there’s a lot of code I’m unfamiliar with.
> >> > >>
> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >>
> >> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> >> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> >> > for now.
> >> > >>
> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
> >> > later today.
> >> > >>
> >> > >> The question: How to proceed with branch_7x? Should we stop using it
> >> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> >> > the jenkins jobs enabled for a while.
> >> > >>
> >> > >> Uwe
> >> > >>
> >> > >> -----
> >> > >> Uwe Schindler
> >> > >> Achterdiek 19, D-28357 Bremen
> >> > >> http://www.thetaphi.de <http://www.thetaphi.de/>
> >> > >> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
> >> > >>
> >> > >> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>>
> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >> > >> To: dev@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> Subject: Re: Lucene/Solr 8.0
> >> > >>
> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> >> > from master, and am in the process of updating the master branch to version
> >> > 9.  New commits that should be included in the 8.0 release should also be
> >> > back-ported to branch_8x from master.
> >> > >>
> >> > >> This is not intended as a feature freeze, as I know there are still some
> >> > things being worked on for 8.0; however, it should let us clean up master by
> >> > removing as much deprecated code as possible, and give us an idea of any
> >> > replacement work that needs to be done.
> >> > >>
> >> > >>
> >> > >> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >>
> >> > >> January.
> >> > >>
> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >>
> >> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
> >> > on nested-documents we are waiting to get our hands on.
> >> > >> Any idea when Solr 8 would be out ?
> >> > >>
> >> > >> Thx
> >> > >> SG
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
> >> > >>
> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >> > >>    click here:
> >> > >>
> >> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU>
> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >> > >>
> >> > >> Thru the end of the month, I intend to work on those issues not yet
> >> > assigned.
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >>
> >> > >> +1
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >> > <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> >> > >> >
> >> > >> > Hi all,
> >> > >> >
> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> >> > branch this week - say Wednesday?  Then we should have some time to
> >> > clean up the master branch and uncover anything that still needs to be done
> >> > on 8.0 before we start the release process next year.
> >> > >> >
> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>>
> >> > wrote:
> >> > >> >
> >> > >> > 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
> >> > <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>>
> >> > 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
> >> > <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
> >> > >> >> >>
> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >> > <nknize@gmail.com <ma...@gmail.com>> 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
> >> > <caomanhdat317@gmail.com <ma...@gmail.com>> 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
> >> > <jim.ferenczi@gmail.com <ma...@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
> >> > <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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
> >> > <casstargett@gmail.com <ma...@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
> >> > <erickerickson@gmail.com <ma...@gmail.com>> wrote:
> >> > >> >> >>>>>>>>>
> >> > >> >> >>>>>>>>> I find 9 open blockers for 8.0:
> >> > >> >> >>>>>>>>>
> >> > >> >> >>>>>>>>>
> >> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@gmail.com>> wrote:
> >> > >> >> >>>>>>>>> >>
> >> > >> >> >>>>>>>>> >> Hi,
> >> > >> >> >>>>>>>>> >> We still have two blockers for the Lucene 8 release:
> >> > >> >> >>>>>>>>> >> https://issues.apache.org/jira/browse/LUCENE- <https://issues.apache.org/jira/browse/LUCENE->
> >> > 7075?jql=(project%3D%22Lucene%20-
> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
> >> > r%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
> >> > <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> >> > >> >> >>>>>>>>> >>>
> >> > >> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR- <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
> >> > <jpountz@gmail.com <ma...@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- <https://issues.apache.org/jira/browse/SOLR->
> >> > 12720?jql=(project%3D%22Lucene%20-
> >> > %20Core%22%20%20OR%20project%3DSOLR)%20AND%20priority%3DBlocke
> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >> > >> >> >>>>>>>>> >>>>
> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >> > <jim.ferenczi@gmail.com <ma...@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
> >> > <erickerickson@gmail.com <ma...@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
> >> > <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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
> >> > <jpountz@gmail.com <ma...@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
> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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
> >> > <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir
> >> > <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [2]
> >> > https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [3]
> >> > https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [4]
> >> > https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [5]
> >> > https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> > [7]
> >> > https://issues.apache.org/jira/browse/LUCENE-8134 <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-
> >> > unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
> >> > ----------
> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> >> > unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >> > >> >> >>>>>>>>> >>>>>> >>> --
> >> > >> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant,
> >> > Developer, Author, Speaker
> >> > >> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley>
> >> > | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> > >> >> >>>>>>>>> >>>>>>
> >> > >> >> >>>>>>>>> >>>>>> --------------------------------------------------------------------
> >> > -
> >> > >> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-
> >> > unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> >>>>>>
> >> > >> >> >>>>>>>>> > --
> >> > >> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer,
> >> > Author, Speaker
> >> > >> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book:
> >> > http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> > >> >> >>>>>>>>>
> >> > >> >> >>>>>>>>> ---------------------------------------------------------------------
> >> > >> >> >>>>>>>>> To unsubscribe, e-mail: dev-
> >> > unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> >>>>>>>>>
> >> > >> >> >>> --
> >> > >> >> >>>
> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> > >> >> >>> Apache Lucene Committer
> >> > >> >> >>> nknize@apache.org <ma...@apache.org>
> >> > >> >> >>
> >> > >> >> >> --
> >> > >> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author,
> >> > Speaker
> >> > >> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book:
> >> > http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> > >> >>
> >> > >> >> ---------------------------------------------------------------------
> >> > >> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> >>
> >> > >> >
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Adrien
> >> > >>
> >> > >> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> > >>
> >> > >> --
> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book:
> >> > http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> > >>
> >> > >> --
> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book:
> >> > http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> > >>
> >> > >>
> >> > >>
> >> >
> >> >
> >> > --
> >> > Adrien
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> > For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>
> >
> >
> > --
> > http://www.the111shift.com <http://www.the111shift.com/>
> 
> 
> 
> --
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> 
> 
> 
> -- 
> http://www.the111shift.com <http://www.the111shift.com/>

Re: Lucene/Solr 8.0

[Tomás Fernández Löbbe <to...@gmail.com>]

I think the UI is an important Solr feature. As long as there is a
reasonable time horizon for the issue being resolved I'm +1 on making it a
blocker. I'm not familiar enough with the UI code to help either
unfortunately.

On Fri, Jan 25, 2019 at 11:24 AM Gus Heck <gu...@gmail.com> wrote:

> It looks like someone tried to make it a blocker once before... And it's
> actually a duplicate of an earlier issue (
> https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question
> of whether or not overall quality has a bearing on the decision to release.
> As it turns out the screen shot I posted to the issue is less than half of
> the shards that eventually got created since there was an outstanding queue
> of requests still processing at the time. I'm now having to delete 50 or so
> cores, which luckily are small 100 Mb initial testing cores, not the 20GB
> cores we'll be testing on in the near future. It more or less makes it
> impossible to recommend the use of the admin UI for anything other than
> read only observation of the cluster. Now imagine someone leaves a browser
> window open and forgets about it rather than browsing away or closing the
> window, not knowing that it's silently pumping out requests after showing
> an error... would completely hose a node, and until they tracked down the
> source of the requests, (hope he didn't go home) it would be impossible to
> resolve...
>
> On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:
>
>> Releasing a new major is very challenging on its own, I'd rather not
>> call it a blocker and delay the release for it since this isn't a new
>> regression in 8.0: it looks like a problem that has affected Solr
>> since at least 6.3? I'm not familiar with the UI code at all, but
>> maybe this is something that could get fixed before we build a RC?
>>
>>
>>
>>
>> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>> >
>> > I'd like to suggest that
>> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
>> 8.0. I just got burned by it a second time.
>> >
>> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>> >>
>> >> Cool,
>> >>
>> >> I am working on giving my best release time guess as possible on the
>> FOSDEM conference!
>> >>
>> >> Uwe
>> >>
>> >> -----
>> >> Uwe Schindler
>> >> Achterdiek 19, D-28357 Bremen
>> >> http://www.thetaphi.de
>> >> eMail: uwe@thetaphi.de
>> >>
>> >> > -----Original Message-----
>> >> > From: Adrien Grand <jp...@gmail.com>
>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> >> > To: Lucene Dev <de...@lucene.apache.org>
>> >> > Subject: Re: Lucene/Solr 8.0
>> >> >
>> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
>> 4th.
>> >> >
>> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <jim.ferenczi@gmail.com
>> >
>> >> > wrote:
>> >> > >
>> >> > > Hi,
>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The
>> branch is
>> >> > already created so we can start the process anytime now. Unless
>> there are
>> >> > objections I'd like to start the feature freeze next week in order
>> to build the
>> >> > first candidate the week after.
>> >> > > We'll also need a 7.7 release but I think we can handle both with
>> Alan so
>> >> > the question now is whether we are ok to start the release process
>> or if there
>> >> > are any blockers left ;).
>> >> > >
>> >> > >
>> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <romseygeek@gmail.com
>> >
>> >> > a écrit :
>> >> > >>
>> >> > >> I’ve started to work through the various deprecations on the new
>> master
>> >> > branch.  There are a lot of them, and I’m going to need some
>> assistance for
>> >> > several of them, as it’s not entirely clear what to do.
>> >> > >>
>> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one
>> for Solr,
>> >> > with lists of the deprecations that need to be removed in each one.
>> I’ll create
>> >> > a shared branch on gitbox to work against, and push the changes I’ve
>> already
>> >> > done there.  We can then create individual JIRA issues for any
>> changes that
>> >> > are more involved than just deleting code.
>> >> > >>
>> >> > >> All assistance gratefully received, particularly for the Solr
>> deprecations
>> >> > where there’s a lot of code I’m unfamiliar with.
>> >> > >>
>> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >> I think the current plan is to do a 7.7 release at the same time
>> as 8.0, to
>> >> > handle any last-minute deprecations etc.  So let’s keep those jobs
>> enabled
>> >> > for now.
>> >> > >>
>> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> >> > >>
>> >> > >> Hi,
>> >> > >>
>> >> > >> I will start and add the branch_8x jobs to Jenkins once I have
>> some time
>> >> > later today.
>> >> > >>
>> >> > >> The question: How to proceed with branch_7x? Should we stop using
>> it
>> >> > and release 7.6.x only (so we would use branch_7_6 only for
>> bugfixes), or
>> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
>> would keep
>> >> > the jenkins jobs enabled for a while.
>> >> > >>
>> >> > >> Uwe
>> >> > >>
>> >> > >> -----
>> >> > >> Uwe Schindler
>> >> > >> Achterdiek 19, D-28357 Bremen
>> >> > >> http://www.thetaphi.de
>> >> > >> eMail: uwe@thetaphi.de
>> >> > >>
>> >> > >> From: Alan Woodward <ro...@gmail.com>
>> >> > >> Sent: Monday, January 7, 2019 11:30 AM
>> >> > >> To: dev@lucene.apache.org
>> >> > >> Subject: Re: Lucene/Solr 8.0
>> >> > >>
>> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch
>> for 8x
>> >> > from master, and am in the process of updating the master branch to
>> version
>> >> > 9.  New commits that should be included in the 8.0 release should
>> also be
>> >> > back-ported to branch_8x from master.
>> >> > >>
>> >> > >> This is not intended as a feature freeze, as I know there are
>> still some
>> >> > things being worked on for 8.0; however, it should let us clean up
>> master by
>> >> > removing as much deprecated code as possible, and give us an idea of
>> any
>> >> > replacement work that needs to be done.
>> >> > >>
>> >> > >>
>> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >> January.
>> >> > >>
>> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >> It would be nice to see Solr 8 in January soon as there is an
>> enhancement
>> >> > on nested-documents we are waiting to get our hands on.
>> >> > >> Any idea when Solr 8 would be out ?
>> >> > >>
>> >> > >> Thx
>> >> > >> SG
>> >> > >>
>> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> >> > <da...@gmail.com> wrote:
>> >> > >>
>> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR,
>> LUCENE) AND
>> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> >> > >>    click here:
>> >> > >>
>> >> >
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> >> > >>
>> >> > >> Thru the end of the month, I intend to work on those issues not
>> yet
>> >> > assigned.
>> >> > >>
>> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> >> > wrote:
>> >> > >>
>> >> > >> +1
>> >> > >>
>> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> >> > <ro...@gmail.com> wrote:
>> >> > >> >
>> >> > >> > Hi all,
>> >> > >> >
>> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think
>> about
>> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
>> create the
>> >> > branch this week - say Wednesday?  Then we should have some time to
>> >> > clean up the master branch and uncover anything that still needs to
>> be done
>> >> > on 8.0 before we start the release process next year.
>> >> > >> >
>> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
>> casstargett@gmail.com>
>> >> > wrote:
>> >> > >> >
>> >> > >> > 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
>> >> > <er...@gmail.com> 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 <
>> jim.ferenczi@gmail.com>
>> >> > 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
>> >> > <da...@gmail.com> a écrit :
>> >> > >> >> >>
>> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> >> > <nk...@gmail.com> 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
>> >> > <ca...@gmail.com> 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
>> >> > <ji...@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
>> >> > <ca...@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
>> >> > <ji...@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
>> >> > <ca...@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
>> >> > <er...@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
>> >> > <da...@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
>> >> > <ji...@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%3DBlocke
>> >> > r%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
>> >> > <jp...@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
>> >> > <jp...@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%3DBlocke
>> >> > r%20and%20resolution%20%3D%20Unresolved%20
>> >> > >> >> >>>>>>>>> >>>>
>> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> >> > <ji...@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
>> >> > <er...@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
>> >> > <ca...@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
>> >> > <ji...@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
>> >> > <da...@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
>> >> > <jp...@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
>> >> > <rc...@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 <jp...@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
>> >> > <jp...@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
>> >> > <rc...@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 <jp...@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-
>> >> > unsubscribe@lucene.apache.org
>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>> dev-
>> >> > help@lucene.apache.org
>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> >> > >> >> >>>>>>>>> >>>>>> >>>>>
>> -----------------------------------------------------------
>> >> > ----------
>> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>> >> > unsubscribe@lucene.apache.org
>> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>> >> > help@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-
>> >> > unsubscribe@lucene.apache.org
>> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>> >> > help@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-
>> >> > unsubscribe@lucene.apache.org
>> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>> >> > help@lucene.apache.org
>> >> > >> >> >>>>>>>>>
>> >> > >> >> >>> --
>> >> > >> >> >>>
>> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
>> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>> >> > >> >> >>> Apache Lucene Committer
>> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> > >> >>
>> >> > >> >
>> >> > >>
>> >> > >>
>> >> > >> --
>> >> > >> Adrien
>> >> > >>
>> >> > >>
>> ---------------------------------------------------------------------
>> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> > >>
>> >> > >> --
>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> >> > http://www.solrenterprisesearchserver.com
>> >> > >>
>> >> > >> --
>> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> >> > http://www.solrenterprisesearchserver.com
>> >> > >>
>> >> > >>
>> >> > >>
>> >> >
>> >> >
>> >> > --
>> >> > Adrien
>> >> >
>> >> > ---------------------------------------------------------------------
>> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> > For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >>
>> >> ---------------------------------------------------------------------
>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>> >
>> > --
>> > http://www.the111shift.com
>>
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>
> --
> http://www.the111shift.com
>

Re: Lucene/Solr 8.0

[Gus Heck <gu...@gmail.com>]

It looks like someone tried to make it a blocker once before... And it's
actually a duplicate of an earlier issue (
https://issues.apache.org/jira/browse/SOLR-9818). I guess its a question of
whether or not overall quality has a bearing on the decision to release. As
it turns out the screen shot I posted to the issue is less than half of the
shards that eventually got created since there was an outstanding queue of
requests still processing at the time. I'm now having to delete 50 or so
cores, which luckily are small 100 Mb initial testing cores, not the 20GB
cores we'll be testing on in the near future. It more or less makes it
impossible to recommend the use of the admin UI for anything other than
read only observation of the cluster. Now imagine someone leaves a browser
window open and forgets about it rather than browsing away or closing the
window, not knowing that it's silently pumping out requests after showing
an error... would completely hose a node, and until they tracked down the
source of the requests, (hope he didn't go home) it would be impossible to
resolve...

On Fri, Jan 25, 2019 at 1:25 PM Adrien Grand <jp...@gmail.com> wrote:

> Releasing a new major is very challenging on its own, I'd rather not
> call it a blocker and delay the release for it since this isn't a new
> regression in 8.0: it looks like a problem that has affected Solr
> since at least 6.3? I'm not familiar with the UI code at all, but
> maybe this is something that could get fixed before we build a RC?
>
>
>
>
> On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
> >
> > I'd like to suggest that
> https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block
> 8.0. I just got burned by it a second time.
> >
> > On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
> >>
> >> Cool,
> >>
> >> I am working on giving my best release time guess as possible on the
> FOSDEM conference!
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> http://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >> > -----Original Message-----
> >> > From: Adrien Grand <jp...@gmail.com>
> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > To: Lucene Dev <de...@lucene.apache.org>
> >> > Subject: Re: Lucene/Solr 8.0
> >> >
> >> > +1 to release 7.7 and 8.0 in a row starting on the week of February
> 4th.
> >> >
> >> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> >> > wrote:
> >> > >
> >> > > Hi,
> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> >> > already created so we can start the process anytime now. Unless there
> are
> >> > objections I'd like to start the feature freeze next week in order to
> build the
> >> > first candidate the week after.
> >> > > We'll also need a 7.7 release but I think we can handle both with
> Alan so
> >> > the question now is whether we are ok to start the release process or
> if there
> >> > are any blockers left ;).
> >> > >
> >> > >
> >> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> >> > a écrit :
> >> > >>
> >> > >> I’ve started to work through the various deprecations on the new
> master
> >> > branch.  There are a lot of them, and I’m going to need some
> assistance for
> >> > several of them, as it’s not entirely clear what to do.
> >> > >>
> >> > >> I’ll open two overarching issues in JIRA, one for lucene and one
> for Solr,
> >> > with lists of the deprecations that need to be removed in each one.
> I’ll create
> >> > a shared branch on gitbox to work against, and push the changes I’ve
> already
> >> > done there.  We can then create individual JIRA issues for any
> changes that
> >> > are more involved than just deleting code.
> >> > >>
> >> > >> All assistance gratefully received, particularly for the Solr
> deprecations
> >> > where there’s a lot of code I’m unfamiliar with.
> >> > >>
> >> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >> I think the current plan is to do a 7.7 release at the same time
> as 8.0, to
> >> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> >> > for now.
> >> > >>
> >> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >> > >>
> >> > >> Hi,
> >> > >>
> >> > >> I will start and add the branch_8x jobs to Jenkins once I have
> some time
> >> > later today.
> >> > >>
> >> > >> The question: How to proceed with branch_7x? Should we stop using
> it
> >> > and release 7.6.x only (so we would use branch_7_6 only for
> bugfixes), or
> >> > are we planning to one more Lucene/Solr 7.7? In the latter case I
> would keep
> >> > the jenkins jobs enabled for a while.
> >> > >>
> >> > >> Uwe
> >> > >>
> >> > >> -----
> >> > >> Uwe Schindler
> >> > >> Achterdiek 19, D-28357 Bremen
> >> > >> http://www.thetaphi.de
> >> > >> eMail: uwe@thetaphi.de
> >> > >>
> >> > >> From: Alan Woodward <ro...@gmail.com>
> >> > >> Sent: Monday, January 7, 2019 11:30 AM
> >> > >> To: dev@lucene.apache.org
> >> > >> Subject: Re: Lucene/Solr 8.0
> >> > >>
> >> > >> OK, Christmas caught up with me a bit… I’ve just created a branch
> for 8x
> >> > from master, and am in the process of updating the master branch to
> version
> >> > 9.  New commits that should be included in the 8.0 release should
> also be
> >> > back-ported to branch_8x from master.
> >> > >>
> >> > >> This is not intended as a feature freeze, as I know there are
> still some
> >> > things being worked on for 8.0; however, it should let us clean up
> master by
> >> > removing as much deprecated code as possible, and give us an idea of
> any
> >> > replacement work that needs to be done.
> >> > >>
> >> > >>
> >> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >> January.
> >> > >>
> >> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >> It would be nice to see Solr 8 in January soon as there is an
> enhancement
> >> > on nested-documents we are waiting to get our hands on.
> >> > >> Any idea when Solr 8 would be out ?
> >> > >>
> >> > >> Thx
> >> > >> SG
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> >> > <da...@gmail.com> wrote:
> >> > >>
> >> > >> I see 10 JIRA issues matching this filter:   project in (SOLR,
> LUCENE) AND
> >> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> >> > >>    click here:
> >> > >>
> >> >
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> >> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> >> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >> > >>
> >> > >> Thru the end of the month, I intend to work on those issues not yet
> >> > assigned.
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> >> > wrote:
> >> > >>
> >> > >> +1
> >> > >>
> >> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> >> > <ro...@gmail.com> wrote:
> >> > >> >
> >> > >> > Hi all,
> >> > >> >
> >> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think
> about
> >> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> >> > branch this week - say Wednesday?  Then we should have some time to
> >> > clean up the master branch and uncover anything that still needs to
> be done
> >> > on 8.0 before we start the release process next year.
> >> > >> >
> >> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <
> casstargett@gmail.com>
> >> > wrote:
> >> > >> >
> >> > >> > 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
> >> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> >> > 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
> >> > <da...@gmail.com> a écrit :
> >> > >> >> >>
> >> > >> >> >> +1 to a 7.6 —lots of stuff in there
> >> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> >> > <nk...@gmail.com> 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
> >> > <ca...@gmail.com> 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
> >> > <ji...@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
> >> > <ca...@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
> >> > <ji...@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
> >> > <ca...@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
> >> > <er...@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
> >> > <da...@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
> >> > <ji...@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%3DBlocke
> >> > r%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
> >> > <jp...@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
> >> > <jp...@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%3DBlocke
> >> > r%20and%20resolution%20%3D%20Unresolved%20
> >> > >> >> >>>>>>>>> >>>>
> >> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> >> > <ji...@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
> >> > <er...@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
> >> > <ca...@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
> >> > <ji...@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
> >> > <da...@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
> >> > <jp...@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
> >> > <rc...@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 <jp...@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
> >> > <jp...@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
> >> > <rc...@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 <jp...@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-
> >> > unsubscribe@lucene.apache.org
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> > >> >> >>>>>>>>> >>>>>> >>>>> >
> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> >> > >> >> >>>>>>>>> >>>>>> >>>>>
> -----------------------------------------------------------
> >> > ----------
> >> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> >> > unsubscribe@lucene.apache.org
> >> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> >> > help@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-
> >> > unsubscribe@lucene.apache.org
> >> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> >> > help@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-
> >> > unsubscribe@lucene.apache.org
> >> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> >> > help@lucene.apache.org
> >> > >> >> >>>>>>>>>
> >> > >> >> >>> --
> >> > >> >> >>>
> >> > >> >> >>> Nicholas Knize, Ph.D., GISP
> >> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> > >> >> >>> Apache Lucene Committer
> >> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> > >> >>
> >> > >> >
> >> > >>
> >> > >>
> >> > >> --
> >> > >> Adrien
> >> > >>
> >> > >>
> ---------------------------------------------------------------------
> >> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> > >>
> >> > >> --
> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> > http://www.solrenterprisesearchserver.com
> >> > >>
> >> > >> --
> >> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> >> > http://www.solrenterprisesearchserver.com
> >> > >>
> >> > >>
> >> > >>
> >> >
> >> >
> >> > --
> >> > Adrien
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> > For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
> >
> > --
> > http://www.the111shift.com
>
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

-- 
http://www.the111shift.com

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

Releasing a new major is very challenging on its own, I'd rather not
call it a blocker and delay the release for it since this isn't a new
regression in 8.0: it looks like a problem that has affected Solr
since at least 6.3? I'm not familiar with the UI code at all, but
maybe this is something that could get fixed before we build a RC?




On Fri, Jan 25, 2019 at 6:06 PM Gus Heck <gu...@gmail.com> wrote:
>
> I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211 be promoted to block 8.0. I just got burned by it a second time.
>
> On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:
>>
>> Cool,
>>
>> I am working on giving my best release time guess as possible on the FOSDEM conference!
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>> > -----Original Message-----
>> > From: Adrien Grand <jp...@gmail.com>
>> > Sent: Thursday, January 24, 2019 5:33 PM
>> > To: Lucene Dev <de...@lucene.apache.org>
>> > Subject: Re: Lucene/Solr 8.0
>> >
>> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
>> >
>> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
>> > wrote:
>> > >
>> > > Hi,
>> > > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
>> > already created so we can start the process anytime now. Unless there are
>> > objections I'd like to start the feature freeze next week in order to build the
>> > first candidate the week after.
>> > > We'll also need a 7.7 release but I think we can handle both with Alan so
>> > the question now is whether we are ok to start the release process or if there
>> > are any blockers left ;).
>> > >
>> > >
>> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
>> > a écrit :
>> > >>
>> > >> I’ve started to work through the various deprecations on the new master
>> > branch.  There are a lot of them, and I’m going to need some assistance for
>> > several of them, as it’s not entirely clear what to do.
>> > >>
>> > >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
>> > with lists of the deprecations that need to be removed in each one.  I’ll create
>> > a shared branch on gitbox to work against, and push the changes I’ve already
>> > done there.  We can then create individual JIRA issues for any changes that
>> > are more involved than just deleting code.
>> > >>
>> > >> All assistance gratefully received, particularly for the Solr deprecations
>> > where there’s a lot of code I’m unfamiliar with.
>> > >>
>> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
>> > wrote:
>> > >>
>> > >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
>> > handle any last-minute deprecations etc.  So let’s keep those jobs enabled
>> > for now.
>> > >>
>> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>> > >>
>> > >> Hi,
>> > >>
>> > >> I will start and add the branch_8x jobs to Jenkins once I have some time
>> > later today.
>> > >>
>> > >> The question: How to proceed with branch_7x? Should we stop using it
>> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
>> > are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
>> > the jenkins jobs enabled for a while.
>> > >>
>> > >> Uwe
>> > >>
>> > >> -----
>> > >> Uwe Schindler
>> > >> Achterdiek 19, D-28357 Bremen
>> > >> http://www.thetaphi.de
>> > >> eMail: uwe@thetaphi.de
>> > >>
>> > >> From: Alan Woodward <ro...@gmail.com>
>> > >> Sent: Monday, January 7, 2019 11:30 AM
>> > >> To: dev@lucene.apache.org
>> > >> Subject: Re: Lucene/Solr 8.0
>> > >>
>> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
>> > from master, and am in the process of updating the master branch to version
>> > 9.  New commits that should be included in the 8.0 release should also be
>> > back-ported to branch_8x from master.
>> > >>
>> > >> This is not intended as a feature freeze, as I know there are still some
>> > things being worked on for 8.0; however, it should let us clean up master by
>> > removing as much deprecated code as possible, and give us an idea of any
>> > replacement work that needs to be done.
>> > >>
>> > >>
>> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
>> > wrote:
>> > >>
>> > >> January.
>> > >>
>> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
>> > wrote:
>> > >>
>> > >> It would be nice to see Solr 8 in January soon as there is an enhancement
>> > on nested-documents we are waiting to get our hands on.
>> > >> Any idea when Solr 8 would be out ?
>> > >>
>> > >> Thx
>> > >> SG
>> > >>
>> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
>> > <da...@gmail.com> wrote:
>> > >>
>> > >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
>> > priority = Blocker and status = open and fixVersion = "master (8.0)"
>> > >>    click here:
>> > >>
>> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
>> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
>> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>> > >>
>> > >> Thru the end of the month, I intend to work on those issues not yet
>> > assigned.
>> > >>
>> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
>> > wrote:
>> > >>
>> > >> +1
>> > >>
>> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
>> > <ro...@gmail.com> wrote:
>> > >> >
>> > >> > Hi all,
>> > >> >
>> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
>> > branch this week - say Wednesday?  Then we should have some time to
>> > clean up the master branch and uncover anything that still needs to be done
>> > on 8.0 before we start the release process next year.
>> > >> >
>> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> > wrote:
>> > >> >
>> > >> > 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
>> > <er...@gmail.com> 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 <ji...@gmail.com>
>> > 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
>> > <da...@gmail.com> a écrit :
>> > >> >> >>
>> > >> >> >> +1 to a 7.6 —lots of stuff in there
>> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
>> > <nk...@gmail.com> 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
>> > <ca...@gmail.com> 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
>> > <ji...@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
>> > <ca...@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
>> > <ji...@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
>> > <ca...@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
>> > <er...@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
>> > <da...@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
>> > <ji...@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%3DBlocke
>> > r%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
>> > <jp...@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
>> > <jp...@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%3DBlocke
>> > r%20and%20resolution%20%3D%20Unresolved%20
>> > >> >> >>>>>>>>> >>>>
>> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
>> > <ji...@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
>> > <er...@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
>> > <ca...@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
>> > <ji...@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
>> > <da...@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
>> > <jp...@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
>> > <rc...@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 <jp...@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
>> > <jp...@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
>> > <rc...@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 <jp...@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-
>> > unsubscribe@lucene.apache.org
>> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
>> > help@lucene.apache.org
>> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
>> > >> >> >>>>>>>>> >>>>>> >>>>> >
>> > >> >> >>>>>>>>> >>>>>> >>>>>
>> > >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
>> > ----------
>> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
>> > unsubscribe@lucene.apache.org
>> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
>> > help@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-
>> > unsubscribe@lucene.apache.org
>> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
>> > help@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-
>> > unsubscribe@lucene.apache.org
>> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
>> > help@lucene.apache.org
>> > >> >> >>>>>>>>>
>> > >> >> >>> --
>> > >> >> >>>
>> > >> >> >>> Nicholas Knize, Ph.D., GISP
>> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
>> > >> >> >>> Apache Lucene Committer
>> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > >> >>
>> > >> >
>> > >>
>> > >>
>> > >> --
>> > >> Adrien
>> > >>
>> > >> ---------------------------------------------------------------------
>> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > >> For additional commands, e-mail: dev-help@lucene.apache.org
>> > >>
>> > >> --
>> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > http://www.solrenterprisesearchserver.com
>> > >>
>> > >> --
>> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> > http://www.solrenterprisesearchserver.com
>> > >>
>> > >>
>> > >>
>> >
>> >
>> > --
>> > Adrien
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> > For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>
>
> --
> http://www.the111shift.com



--
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Gus Heck <gu...@gmail.com>]

I'd like to suggest that https://issues.apache.org/jira/browse/SOLR-10211
be promoted to block 8.0. I just got burned by it a second time.

On Thu, Jan 24, 2019 at 1:05 PM Uwe Schindler <uw...@thetaphi.de> wrote:

> Cool,
>
> I am working on giving my best release time guess as possible on the
> FOSDEM conference!
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> > -----Original Message-----
> > From: Adrien Grand <jp...@gmail.com>
> > Sent: Thursday, January 24, 2019 5:33 PM
> > To: Lucene Dev <de...@lucene.apache.org>
> > Subject: Re: Lucene/Solr 8.0
> >
> > +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> >
> > On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> > wrote:
> > >
> > > Hi,
> > > As we agreed some time ago I'd like to start on releasing 8.0. The
> branch is
> > already created so we can start the process anytime now. Unless there are
> > objections I'd like to start the feature freeze next week in order to
> build the
> > first candidate the week after.
> > > We'll also need a 7.7 release but I think we can handle both with Alan
> so
> > the question now is whether we are ok to start the release process or if
> there
> > are any blockers left ;).
> > >
> > >
> > > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> > a écrit :
> > >>
> > >> I’ve started to work through the various deprecations on the new
> master
> > branch.  There are a lot of them, and I’m going to need some assistance
> for
> > several of them, as it’s not entirely clear what to do.
> > >>
> > >> I’ll open two overarching issues in JIRA, one for lucene and one for
> Solr,
> > with lists of the deprecations that need to be removed in each one.
> I’ll create
> > a shared branch on gitbox to work against, and push the changes I’ve
> already
> > done there.  We can then create individual JIRA issues for any changes
> that
> > are more involved than just deleting code.
> > >>
> > >> All assistance gratefully received, particularly for the Solr
> deprecations
> > where there’s a lot of code I’m unfamiliar with.
> > >>
> > >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> > wrote:
> > >>
> > >> I think the current plan is to do a 7.7 release at the same time as
> 8.0, to
> > handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled
> > for now.
> > >>
> > >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I will start and add the branch_8x jobs to Jenkins once I have some
> time
> > later today.
> > >>
> > >> The question: How to proceed with branch_7x? Should we stop using it
> > and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> > are we planning to one more Lucene/Solr 7.7? In the latter case I would
> keep
> > the jenkins jobs enabled for a while.
> > >>
> > >> Uwe
> > >>
> > >> -----
> > >> Uwe Schindler
> > >> Achterdiek 19, D-28357 Bremen
> > >> http://www.thetaphi.de
> > >> eMail: uwe@thetaphi.de
> > >>
> > >> From: Alan Woodward <ro...@gmail.com>
> > >> Sent: Monday, January 7, 2019 11:30 AM
> > >> To: dev@lucene.apache.org
> > >> Subject: Re: Lucene/Solr 8.0
> > >>
> > >> OK, Christmas caught up with me a bit… I’ve just created a branch for
> 8x
> > from master, and am in the process of updating the master branch to
> version
> > 9.  New commits that should be included in the 8.0 release should also be
> > back-ported to branch_8x from master.
> > >>
> > >> This is not intended as a feature freeze, as I know there are still
> some
> > things being worked on for 8.0; however, it should let us clean up
> master by
> > removing as much deprecated code as possible, and give us an idea of any
> > replacement work that needs to be done.
> > >>
> > >>
> > >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> > wrote:
> > >>
> > >> January.
> > >>
> > >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> > wrote:
> > >>
> > >> It would be nice to see Solr 8 in January soon as there is an
> enhancement
> > on nested-documents we are waiting to get our hands on.
> > >> Any idea when Solr 8 would be out ?
> > >>
> > >> Thx
> > >> SG
> > >>
> > >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> > <da...@gmail.com> wrote:
> > >>
> > >> I see 10 JIRA issues matching this filter:   project in (SOLR,
> LUCENE) AND
> > priority = Blocker and status = open and fixVersion = "master (8.0)"
> > >>    click here:
> > >>
> > https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> > CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> > 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> > >>
> > >> Thru the end of the month, I intend to work on those issues not yet
> > assigned.
> > >>
> > >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> > wrote:
> > >>
> > >> +1
> > >>
> > >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> > <ro...@gmail.com> wrote:
> > >> >
> > >> > Hi all,
> > >> >
> > >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> > cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to
> create the
> > branch this week - say Wednesday?  Then we should have some time to
> > clean up the master branch and uncover anything that still needs to be
> done
> > on 8.0 before we start the release process next year.
> > >> >
> > >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> > wrote:
> > >> >
> > >> > 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
> > <er...@gmail.com> 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 <
> jim.ferenczi@gmail.com>
> > 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
> > <da...@gmail.com> a écrit :
> > >> >> >>
> > >> >> >> +1 to a 7.6 —lots of stuff in there
> > >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> > <nk...@gmail.com> 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
> > <ca...@gmail.com> 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
> > <ji...@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
> > <ca...@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
> > <ji...@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
> > <ca...@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
> > <er...@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
> > <da...@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
> > <ji...@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%3DBlocke
> > r%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
> > <jp...@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
> > <jp...@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%3DBlocke
> > r%20and%20resolution%20%3D%20Unresolved%20
> > >> >> >>>>>>>>> >>>>
> > >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> > <ji...@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
> > <er...@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
> > <ca...@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
> > <ji...@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
> > <da...@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
> > <jp...@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
> > <rc...@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 <jp...@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
> > <jp...@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
> > <rc...@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 <jp...@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-
> > unsubscribe@lucene.apache.org
> > >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> > help@lucene.apache.org
> > >> >> >>>>>>>>> >>>>>> >>>>> >>>
> > >> >> >>>>>>>>> >>>>>> >>>>> >
> > >> >> >>>>>>>>> >>>>>> >>>>>
> > >> >> >>>>>>>>> >>>>>> >>>>>
> -----------------------------------------------------------
> > ----------
> > >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> > unsubscribe@lucene.apache.org
> > >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> > help@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-
> > unsubscribe@lucene.apache.org
> > >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> > help@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-
> > unsubscribe@lucene.apache.org
> > >> >> >>>>>>>>> For additional commands, e-mail: dev-
> > help@lucene.apache.org
> > >> >> >>>>>>>>>
> > >> >> >>> --
> > >> >> >>>
> > >> >> >>> Nicholas Knize, Ph.D., GISP
> > >> >> >>> Geospatial Software Guy  |  Elasticsearch
> > >> >> >>> Apache Lucene Committer
> > >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> > >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >> >>
> > >> >
> > >>
> > >>
> > >> --
> > >> Adrien
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > >> For additional commands, e-mail: dev-help@lucene.apache.org
> > >>
> > >> --
> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> > >>
> > >> --
> > >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> > >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> > http://www.solrenterprisesearchserver.com
> > >>
> > >>
> > >>
> >
> >
> > --
> > Adrien
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> > For additional commands, e-mail: dev-help@lucene.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

-- 
http://www.the111shift.com

RE: Lucene/Solr 8.0

[Uwe Schindler <uw...@thetaphi.de>]

Cool,

I am working on giving my best release time guess as possible on the FOSDEM conference!

Uwe

-----
Uwe Schindler
Achterdiek 19, D-28357 Bremen
http://www.thetaphi.de
eMail: uwe@thetaphi.de

> -----Original Message-----
> From: Adrien Grand <jp...@gmail.com>
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev <de...@lucene.apache.org>
> Subject: Re: Lucene/Solr 8.0
> 
> +1 to release 7.7 and 8.0 in a row starting on the week of February 4th.
> 
> On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com>
> wrote:
> >
> > Hi,
> > As we agreed some time ago I'd like to start on releasing 8.0. The branch is
> already created so we can start the process anytime now. Unless there are
> objections I'd like to start the feature freeze next week in order to build the
> first candidate the week after.
> > We'll also need a 7.7 release but I think we can handle both with Alan so
> the question now is whether we are ok to start the release process or if there
> are any blockers left ;).
> >
> >
> > Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com>
> a écrit :
> >>
> >> I’ve started to work through the various deprecations on the new master
> branch.  There are a lot of them, and I’m going to need some assistance for
> several of them, as it’s not entirely clear what to do.
> >>
> >> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> with lists of the deprecations that need to be removed in each one.  I’ll create
> a shared branch on gitbox to work against, and push the changes I’ve already
> done there.  We can then create individual JIRA issues for any changes that
> are more involved than just deleting code.
> >>
> >> All assistance gratefully received, particularly for the Solr deprecations
> where there’s a lot of code I’m unfamiliar with.
> >>
> >> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com>
> wrote:
> >>
> >> I think the current plan is to do a 7.7 release at the same time as 8.0, to
> handle any last-minute deprecations etc.  So let’s keep those jobs enabled
> for now.
> >>
> >> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> >>
> >> Hi,
> >>
> >> I will start and add the branch_8x jobs to Jenkins once I have some time
> later today.
> >>
> >> The question: How to proceed with branch_7x? Should we stop using it
> and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or
> are we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> the jenkins jobs enabled for a while.
> >>
> >> Uwe
> >>
> >> -----
> >> Uwe Schindler
> >> Achterdiek 19, D-28357 Bremen
> >> http://www.thetaphi.de
> >> eMail: uwe@thetaphi.de
> >>
> >> From: Alan Woodward <ro...@gmail.com>
> >> Sent: Monday, January 7, 2019 11:30 AM
> >> To: dev@lucene.apache.org
> >> Subject: Re: Lucene/Solr 8.0
> >>
> >> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> from master, and am in the process of updating the master branch to version
> 9.  New commits that should be included in the 8.0 release should also be
> back-ported to branch_8x from master.
> >>
> >> This is not intended as a feature freeze, as I know there are still some
> things being worked on for 8.0; however, it should let us clean up master by
> removing as much deprecated code as possible, and give us an idea of any
> replacement work that needs to be done.
> >>
> >>
> >> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com>
> wrote:
> >>
> >> January.
> >>
> >> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com>
> wrote:
> >>
> >> It would be nice to see Solr 8 in January soon as there is an enhancement
> on nested-documents we are waiting to get our hands on.
> >> Any idea when Solr 8 would be out ?
> >>
> >> Thx
> >> SG
> >>
> >> On Mon, Dec 17, 2018 at 1:34 PM David Smiley
> <da...@gmail.com> wrote:
> >>
> >> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> priority = Blocker and status = open and fixVersion = "master (8.0)"
> >>    click here:
> >>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LU
> CENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%2
> 0open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
> >>
> >> Thru the end of the month, I intend to work on those issues not yet
> assigned.
> >>
> >> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com>
> wrote:
> >>
> >> +1
> >>
> >> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward
> <ro...@gmail.com> wrote:
> >> >
> >> > Hi all,
> >> >
> >> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the
> branch this week - say Wednesday?  Then we should have some time to
> clean up the master branch and uncover anything that still needs to be done
> on 8.0 before we start the release process next year.
> >> >
> >> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> wrote:
> >> >
> >> > 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
> <er...@gmail.com> 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 <ji...@gmail.com>
> 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
> <da...@gmail.com> a écrit :
> >> >> >>
> >> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize
> <nk...@gmail.com> 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
> <ca...@gmail.com> 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
> <ji...@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
> <ca...@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
> <ji...@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
> <ca...@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
> <er...@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
> <da...@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
> <ji...@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%3DBlocke
> r%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
> <jp...@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
> <jp...@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%3DBlocke
> r%20and%20resolution%20%3D%20Unresolved%20
> >> >> >>>>>>>>> >>>>
> >> >> >>>>>>>>> >>>> Le lun. 3 sept. 2018 à 10:36, jim ferenczi
> <ji...@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
> <er...@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
> <ca...@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
> <ji...@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
> <da...@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
> <jp...@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
> <rc...@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 <jp...@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
> <jp...@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
> <rc...@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 <jp...@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-
> unsubscribe@lucene.apache.org
> >> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-
> help@lucene.apache.org
> >> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> >> >>>>>>>>> >>>>>> >>>>> >
> >> >> >>>>>>>>> >>>>>> >>>>>
> >> >> >>>>>>>>> >>>>>> >>>>> -----------------------------------------------------------
> ----------
> >> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-
> unsubscribe@lucene.apache.org
> >> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-
> help@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-
> unsubscribe@lucene.apache.org
> >> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-
> help@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-
> unsubscribe@lucene.apache.org
> >> >> >>>>>>>>> For additional commands, e-mail: dev-
> help@lucene.apache.org
> >> >> >>>>>>>>>
> >> >> >>> --
> >> >> >>>
> >> >> >>> Nicholas Knize, Ph.D., GISP
> >> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> >> >>> Apache Lucene Committer
> >> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>
> >> >
> >>
> >>
> >> --
> >> Adrien
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >> --
> >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
> >>
> >> --
> >> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
> >>
> >>
> >>
> 
> 
> --
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

+1 to release 7.7 and 8.0 in a row starting on the week of February 4th.

On Wed, Jan 23, 2019 at 4:23 PM jim ferenczi <ji...@gmail.com> wrote:
>
> Hi,
> As we agreed some time ago I'd like to start on releasing 8.0. The branch is already created so we can start the process anytime now. Unless there are objections I'd like to start the feature freeze next week in order to build the first candidate the week after.
> We'll also need a 7.7 release but I think we can handle both with Alan so the question now is whether we are ok to start the release process or if there are any blockers left ;).
>
>
> Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com> a écrit :
>>
>> I’ve started to work through the various deprecations on the new master branch.  There are a lot of them, and I’m going to need some assistance for several of them, as it’s not entirely clear what to do.
>>
>> I’ll open two overarching issues in JIRA, one for lucene and one for Solr, with lists of the deprecations that need to be removed in each one.  I’ll create a shared branch on gitbox to work against, and push the changes I’ve already done there.  We can then create individual JIRA issues for any changes that are more involved than just deleting code.
>>
>> All assistance gratefully received, particularly for the Solr deprecations where there’s a lot of code I’m unfamiliar with.
>>
>> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com> wrote:
>>
>> I think the current plan is to do a 7.7 release at the same time as 8.0, to handle any last-minute deprecations etc.  So let’s keep those jobs enabled for now.
>>
>> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>>
>> Hi,
>>
>> I will start and add the branch_8x jobs to Jenkins once I have some time later today.
>>
>> The question: How to proceed with branch_7x? Should we stop using it and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are we planning to one more Lucene/Solr 7.7? In the latter case I would keep the jenkins jobs enabled for a while.
>>
>> Uwe
>>
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de
>> eMail: uwe@thetaphi.de
>>
>> From: Alan Woodward <ro...@gmail.com>
>> Sent: Monday, January 7, 2019 11:30 AM
>> To: dev@lucene.apache.org
>> Subject: Re: Lucene/Solr 8.0
>>
>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x from master, and am in the process of updating the master branch to version 9.  New commits that should be included in the 8.0 release should also be back-ported to branch_8x from master.
>>
>> This is not intended as a feature freeze, as I know there are still some things being worked on for 8.0; however, it should let us clean up master by removing as much deprecated code as possible, and give us an idea of any replacement work that needs to be done.
>>
>>
>> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com> wrote:
>>
>> January.
>>
>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com> wrote:
>>
>> It would be nice to see Solr 8 in January soon as there is an enhancement on nested-documents we are waiting to get our hands on.
>> Any idea when Solr 8 would be out ?
>>
>> Thx
>> SG
>>
>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <da...@gmail.com> wrote:
>>
>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND priority = Blocker and status = open and fixVersion = "master (8.0)"
>>    click here:
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>
>> Thru the end of the month, I intend to work on those issues not yet assigned.
>>
>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com> wrote:
>>
>> +1
>>
>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com> wrote:
>> >
>> > 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 <er...@gmail.com> 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 <ji...@gmail.com> 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 <da...@gmail.com> a écrit :
>> >> >>
>> >> >> +1 to a 7.6 —lots of stuff in there
>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com> 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 <ca...@gmail.com> 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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <jp...@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> >>>
>> >> >>>>>>>>> >>>>>> >>>>> >
>> >> >>>>>>>>> >>>>>> >>>>>
>> >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>>>>>
>> >> >>> --
>> >> >>>
>> >> >>> Nicholas Knize, Ph.D., GISP
>> >> >>> Geospatial Software Guy  |  Elasticsearch
>> >> >>> Apache Lucene Committer
>> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>>
>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com
>>
>>
>>


-- 
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

Hi,
As we agreed some time ago I'd like to start on releasing 8.0. The branch
is already created so we can start the process anytime now. Unless there
are objections I'd like to start the feature freeze next week in order to
build the first candidate the week after.
We'll also need a 7.7 release but I think we can handle both with Alan so
the question now is whether we are ok to start the release process or if
there are any blockers left ;).


Le mar. 15 janv. 2019 à 11:35, Alan Woodward <ro...@gmail.com> a
écrit :

> I’ve started to work through the various deprecations on the new master
> branch.  There are a lot of them, and I’m going to need some assistance for
> several of them, as it’s not entirely clear what to do.
>
> I’ll open two overarching issues in JIRA, one for lucene and one for Solr,
> with lists of the deprecations that need to be removed in each one.  I’ll
> create a shared branch on gitbox to work against, and push the changes I’ve
> already done there.  We can then create individual JIRA issues for any
> changes that are more involved than just deleting code.
>
> All assistance gratefully received, particularly for the Solr deprecations
> where there’s a lot of code I’m unfamiliar with.
>
> On 8 Jan 2019, at 09:21, Alan Woodward <ro...@gmail.com> wrote:
>
> I think the current plan is to do a 7.7 release at the same time as 8.0,
> to handle any last-minute deprecations etc.  So let’s keep those jobs
> enabled for now.
>
> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
>
> Hi,
>
> I will start and add the branch_8x jobs to Jenkins once I have some time
> later today.
>
> The question: How to proceed with branch_7x? Should we stop using it and
> release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are
> we planning to one more Lucene/Solr 7.7? In the latter case I would keep
> the jenkins jobs enabled for a while.
>
> Uwe
>
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de
> eMail: uwe@thetaphi.de
>
> *From:* Alan Woodward <ro...@gmail.com>
> *Sent:* Monday, January 7, 2019 11:30 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: Lucene/Solr 8.0
>
> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x
> from master, and am in the process of updating the master branch to version
> 9.  New commits that should be included in the 8.0 release should also be
> back-ported to branch_8x from master.
>
> This is not intended as a feature freeze, as I know there are still some
> things being worked on for 8.0; however, it should let us clean up master
> by removing as much deprecated code as possible, and give us an idea of any
> replacement work that needs to be done.
>
>
> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com> wrote:
>
> January.
>
> On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com> wrote:
>
> It would be nice to see Solr 8 in January soon as there is an enhancement
> on nested-documents we are waiting to get our hands on.
> Any idea when Solr 8 would be out ?
>
> Thx
> SG
>
> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <da...@gmail.com>
> wrote:
>
> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> priority = Blocker and status = open and fixVersion = "master (8.0)"
>    click here:
>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>
> Thru the end of the month, I intend to work on those issues not yet
> assigned.
>
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com> wrote:
>
> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create
> the branch this week - say Wednesday?  Then we should have some time to
> clean up the master branch and uncover anything that still needs to be done
> on 8.0 before we start the release process next year.
> >
> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> wrote:
> >
> > 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 <er...@gmail.com>
> 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 <ji...@gmail.com>
> 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 <da...@gmail.com>
> a écrit :
> >> >>
> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com>
> 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 <
> caomanhdat317@gmail.com> 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 <
> jim.ferenczi@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 <
> casstargett@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.ferenczi@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 <
> casstargett@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 <
> erickerickson@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.smiley@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.ferenczi@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 <
> jpountz@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 <
> jpountz@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.ferenczi@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 <
> erickerickson@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 <
> caomanhdat317@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.ferenczi@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.smiley@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 <
> jpountz@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 <
> rcmuir@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 <
> jpountz@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 <
> jpountz@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 <
> rcmuir@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 <jp...@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> >>>>>>>>> >>>>>> >>>>> >
> >> >>>>>>>>> >>>>>> >>>>>
> >> >>>>>>>>> >>>>>> >>>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>>>>
> >> >>> --
> >> >>>
> >> >>> Nicholas Knize, Ph.D., GISP
> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> >>> Apache Lucene Committer
> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>
>
>
>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

I’ve started to work through the various deprecations on the new master branch.  There are a lot of them, and I’m going to need some assistance for several of them, as it’s not entirely clear what to do.

I’ll open two overarching issues in JIRA, one for lucene and one for Solr, with lists of the deprecations that need to be removed in each one.  I’ll create a shared branch on gitbox to work against, and push the changes I’ve already done there.  We can then create individual JIRA issues for any changes that are more involved than just deleting code.

All assistance gratefully received, particularly for the Solr deprecations where there’s a lot of code I’m unfamiliar with.

> On 8 Jan 2019, at 09:21, Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> 
> I think the current plan is to do a 7.7 release at the same time as 8.0, to handle any last-minute deprecations etc.  So let’s keep those jobs enabled for now.
> 
>> On 8 Jan 2019, at 09:10, Uwe Schindler <uwe@thetaphi.de <ma...@thetaphi.de>> wrote:
>> 
>> Hi,
>>  
>> I will start and add the branch_8x jobs to Jenkins once I have some time later today.
>>  
>> The question: How to proceed with branch_7x? Should we stop using it and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are we planning to one more Lucene/Solr 7.7? In the latter case I would keep the jenkins jobs enabled for a while.
>>  
>> Uwe
>>  
>> -----
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> http://www.thetaphi.de <http://www.thetaphi.de/>
>> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>>  
>> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> 
>> Sent: Monday, January 7, 2019 11:30 AM
>> To: dev@lucene.apache.org <ma...@lucene.apache.org>
>> Subject: Re: Lucene/Solr 8.0
>>  
>> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x from master, and am in the process of updating the master branch to version 9.  New commits that should be included in the 8.0 release should also be back-ported to branch_8x from master.
>>  
>> This is not intended as a feature freeze, as I know there are still some things being worked on for 8.0; however, it should let us clean up master by removing as much deprecated code as possible, and give us an idea of any replacement work that needs to be done.
>> 
>> 
>>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>  
>>> January.
>>>  
>>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>> wrote:
>>>> It would be nice to see Solr 8 in January soon as there is an enhancement on nested-documents we are waiting to get our hands on.
>>>> Any idea when Solr 8 would be out ?
>>>>  
>>>> Thx
>>>> SG
>>>>  
>>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND priority = Blocker and status = open and fixVersion = "master (8.0)" 
>>>>>    click here:
>>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20 <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20>
>>>>>  
>>>>> Thru the end of the month, I intend to work on those issues not yet assigned. 
>>>>>  
>>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>>> +1
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >
>>>>>> > Hi all,
>>>>>> >
>>>>>> > Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
>>>>>> >
>>>>>> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>>>> >
>>>>>> > 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 <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>> 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 <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >> >>
>>>>>> >> >> +1 to a 7.6 —lots of stuff in there
>>>>>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> 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 <caomanhdat317@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>>> >> >>>>>>>>> >>>
>>>>>> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >>>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> >
>>>>>> >> >>>>>>>>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>>>>>> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>> >>>>>
>>>>>> >> >>>>>>>>> >>>>>> >>> --
>>>>>> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>>> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>>> >> >>>>>>>>> >>>>>>
>>>>>> >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
>>>>>> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> >>>>>>
>>>>>> >> >>>>>>>>> > --
>>>>>> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>>> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>>> >> >>>>>>>>>
>>>>>> >> >>>>>>>>> ---------------------------------------------------------------------
>>>>>> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> >>>>>>>>>
>>>>>> >> >>> --
>>>>>> >> >>>
>>>>>> >> >>> Nicholas Knize, Ph.D., GISP
>>>>>> >> >>> Geospatial Software Guy  |  Elasticsearch
>>>>>> >> >>> Apache Lucene Committer
>>>>>> >> >>> nknize@apache.org <ma...@apache.org>
>>>>>> >> >>
>>>>>> >> >> --
>>>>>> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>>> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>>> >>
>>>>>> >> ---------------------------------------------------------------------
>>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> >>
>>>>>> >
>>>>>> 
>>>>>> 
>>>>>> -- 
>>>>>> Adrien
>>>>>> 
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> -- 
>>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>> -- 
>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

I think the current plan is to do a 7.7 release at the same time as 8.0, to handle any last-minute deprecations etc.  So let’s keep those jobs enabled for now.

> On 8 Jan 2019, at 09:10, Uwe Schindler <uw...@thetaphi.de> wrote:
> 
> Hi,
>  
> I will start and add the branch_8x jobs to Jenkins once I have some time later today.
>  
> The question: How to proceed with branch_7x? Should we stop using it and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are we planning to one more Lucene/Solr 7.7? In the latter case I would keep the jenkins jobs enabled for a while.
>  
> Uwe
>  
> -----
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> http://www.thetaphi.de <http://www.thetaphi.de/>
> eMail: uwe@thetaphi.de <ma...@thetaphi.de>
>  
> From: Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> 
> Sent: Monday, January 7, 2019 11:30 AM
> To: dev@lucene.apache.org <ma...@lucene.apache.org>
> Subject: Re: Lucene/Solr 8.0
>  
> OK, Christmas caught up with me a bit… I’ve just created a branch for 8x from master, and am in the process of updating the master branch to version 9.  New commits that should be included in the 8.0 release should also be back-ported to branch_8x from master.
>  
> This is not intended as a feature freeze, as I know there are still some things being worked on for 8.0; however, it should let us clean up master by removing as much deprecated code as possible, and give us an idea of any replacement work that needs to be done.
> 
> 
>> On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>  
>> January.
>>  
>> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>> wrote:
>>> It would be nice to see Solr 8 in January soon as there is an enhancement on nested-documents we are waiting to get our hands on.
>>> Any idea when Solr 8 would be out ?
>>>  
>>> Thx
>>> SG
>>>  
>>> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
>>>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND priority = Blocker and status = open and fixVersion = "master (8.0)" 
>>>>    click here:
>>>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20 <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20>
>>>>  
>>>> Thru the end of the month, I intend to work on those issues not yet assigned. 
>>>>  
>>>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
>>>>> +1
>>>>> 
>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
>>>>> >
>>>>> > Hi all,
>>>>> >
>>>>> > Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
>>>>> >
>>>>> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
>>>>> >
>>>>> > 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 <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>> 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 <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >> >>
>>>>> >> >> +1 to a 7.6 —lots of stuff in there
>>>>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> 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 <caomanhdat317@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
>>>>> >> >>>>>>>>> >>>
>>>>> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
>>>>> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >>>
>>>>> >> >>>>>>>>> >>>>>> >>>>> >
>>>>> >> >>>>>>>>> >>>>>> >>>>>
>>>>> >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>>>>> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>> >>>>>
>>>>> >> >>>>>>>>> >>>>>> >>> --
>>>>> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>> >> >>>>>>>>> >>>>>>
>>>>> >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
>>>>> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> >>>>>>
>>>>> >> >>>>>>>>> > --
>>>>> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>> >> >>>>>>>>>
>>>>> >> >>>>>>>>> ---------------------------------------------------------------------
>>>>> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> >>>>>>>>>
>>>>> >> >>> --
>>>>> >> >>>
>>>>> >> >>> Nicholas Knize, Ph.D., GISP
>>>>> >> >>> Geospatial Software Guy  |  Elasticsearch
>>>>> >> >>> Apache Lucene Committer
>>>>> >> >>> nknize@apache.org <ma...@apache.org>
>>>>> >> >>
>>>>> >> >> --
>>>>> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>>>>> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>>>>> >>
>>>>> >> ---------------------------------------------------------------------
>>>>> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>>> >>
>>>>> >
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Adrien
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
>>>> -- 
>>>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>>>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
>> -- 
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

RE: Lucene/Solr 8.0

[Uwe Schindler <uw...@thetaphi.de>]

Hi,

 

I will start and add the branch_8x jobs to Jenkins once I have some time later today.

 

The question: How to proceed with branch_7x? Should we stop using it and release 7.6.x only (so we would use branch_7_6 only for bugfixes), or are we planning to one more Lucene/Solr 7.7? In the latter case I would keep the jenkins jobs enabled for a while.

 

Uwe

 

-----

Uwe Schindler

Achterdiek 19, D-28357 Bremen

http://www.thetaphi.de <http://www.thetaphi.de/> 

eMail: uwe@thetaphi.de

 

From: Alan Woodward <ro...@gmail.com> 
Sent: Monday, January 7, 2019 11:30 AM
To: dev@lucene.apache.org
Subject: Re: Lucene/Solr 8.0

 

OK, Christmas caught up with me a bit… I’ve just created a branch for 8x from master, and am in the process of updating the master branch to version 9.  New commits that should be included in the 8.0 release should also be back-ported to branch_8x from master.

 

This is not intended as a feature freeze, as I know there are still some things being worked on for 8.0; however, it should let us clean up master by removing as much deprecated code as possible, and give us an idea of any replacement work that needs to be done.





On 19 Dec 2018, at 15:13, David Smiley <david.w.smiley@gmail.com <ma...@gmail.com> > wrote:

 

January.

 

On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com> > wrote:

It would be nice to see Solr 8 in January soon as there is an enhancement on nested-documents we are waiting to get our hands on.

Any idea when Solr 8 would be out ?

 

Thx

SG

 

On Mon, Dec 17, 2018 at 1:34 PM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com> > wrote:

I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND priority = Blocker and status = open and fixVersion = "master (8.0)" 

   click here:

https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20

 

Thru the end of the month, I intend to work on those issues not yet assigned. 

 

On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com> > wrote:

+1

On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com> > wrote:
>
> Hi all,
>
> Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
>
> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com> > wrote:
>
> 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 <erickerickson@gmail.com <ma...@gmail.com> > 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 <jim.ferenczi@gmail.com <ma...@gmail.com> > 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 <david.w.smiley@gmail.com <ma...@gmail.com> > a écrit :
>> >>
>> >> +1 to a 7.6 —lots of stuff in there
>> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nknize@gmail.com <ma...@gmail.com> > 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 <caomanhdat317@gmail.com <ma...@gmail.com> > 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 <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <ji...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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.smiley@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>> >>>>> >>>
>> >>>>>>>>> >>>>>> >>>>> >
>> >>>>>>>>> >>>>>> >>>>>
>> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>> >>>>>
>> >>>>>>>>> >>>>>> >>> --
>> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/> 
>> >>>>>>>>> >>>>>>
>> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
>> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> >>>>>>
>> >>>>>>>>> > --
>> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/> 
>> >>>>>>>>>
>> >>>>>>>>> ---------------------------------------------------------------------
>> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>> >>>>>>>>>
>> >>> --
>> >>>
>> >>> Nicholas Knize, Ph.D., GISP
>> >>> Geospatial Software Guy  |  Elasticsearch
>> >>> Apache Lucene Committer
>> >>> nknize@apache.org <ma...@apache.org> 
>> >>
>> >> --
>> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
>> >> LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/> 
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 
>>
>


-- 
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org> 
For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org> 

-- 

Lucene/Solr Search Committer (PMC), Developer, Author, Speaker

LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/> 

-- 

Lucene/Solr Search Committer (PMC), Developer, Author, Speaker

LinkedIn: http://linkedin.com/in/davidwsmiley | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/> 

 

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

OK, Christmas caught up with me a bit… I’ve just created a branch for 8x from master, and am in the process of updating the master branch to version 9.  New commits that should be included in the 8.0 release should also be back-ported to branch_8x from master.

This is not intended as a feature freeze, as I know there are still some things being worked on for 8.0; however, it should let us clean up master by removing as much deprecated code as possible, and give us an idea of any replacement work that needs to be done.

> On 19 Dec 2018, at 15:13, David Smiley <da...@gmail.com> wrote:
> 
> January.
> 
> On Wed, Dec 19, 2018 at 2:04 AM S G <sg.online.email@gmail.com <ma...@gmail.com>> wrote:
> It would be nice to see Solr 8 in January soon as there is an enhancement on nested-documents we are waiting to get our hands on.
> Any idea when Solr 8 would be out ?
> 
> Thx
> SG
> 
> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <david.w.smiley@gmail.com <ma...@gmail.com>> wrote:
> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND priority = Blocker and status = open and fixVersion = "master (8.0)" 
>    click here:
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20 <https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20>
> 
> Thru the end of the month, I intend to work on those issues not yet assigned. 
> 
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jpountz@gmail.com <ma...@gmail.com>> wrote:
> +1
> 
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <romseygeek@gmail.com <ma...@gmail.com>> wrote:
> >
> > Hi all,
> >
> > Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
> >
> > On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
> >
> > 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 <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>> 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 <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
> >> >>
> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> 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 <caomanhdat317@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> >> >>>>>>>>> >>>
> >> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> >> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> >> >>>>>>>>> >>>>>> >>>>> >>
> >> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> >> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> >> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> >> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> >> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> >> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> >>>>>>>>> >>>>>> >>>>> >
> >> >>>>>>>>> >>>>>> >>>>>
> >> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>> >>>>>
> >> >>>>>>>>> >>>>>> >>> --
> >> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> >>>>>>>>> >>>>>>
> >> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
> >> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> >>>>>>
> >> >>>>>>>>> > --
> >> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >> >>>>>>>>>
> >> >>>>>>>>> ---------------------------------------------------------------------
> >> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >> >>>>>>>>>
> >> >>> --
> >> >>>
> >> >>> Nicholas Knize, Ph.D., GISP
> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> >>> Apache Lucene Committer
> >> >>> nknize@apache.org <ma...@apache.org>
> >> >>
> >> >> --
> >> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>
> >
> 
> 
> -- 
> Adrien
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> 
> -- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>-- 
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

January.

On Wed, Dec 19, 2018 at 2:04 AM S G <sg...@gmail.com> wrote:

> It would be nice to see Solr 8 in January soon as there is an enhancement
> on nested-documents we are waiting to get our hands on.
> Any idea when Solr 8 would be out ?
>
> Thx
> SG
>
> On Mon, Dec 17, 2018 at 1:34 PM David Smiley <da...@gmail.com>
> wrote:
>
>> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE)
>> AND priority = Blocker and status = open and fixVersion = "master (8.0)"
>>    click here:
>>
>> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>>
>> Thru the end of the month, I intend to work on those issues not yet
>> assigned.
>>
>> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com> wrote:
>>
>>> +1
>>>
>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com>
>>> wrote:
>>> >
>>> > Hi all,
>>> >
>>> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create
>>> the branch this week - say Wednesday?  Then we should have some time to
>>> clean up the master branch and uncover anything that still needs to be done
>>> on 8.0 before we start the release process next year.
>>> >
>>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>>> wrote:
>>> >
>>> > 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 <
>>> erickerickson@gmail.com> 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 <ji...@gmail.com>
>>> 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 <
>>> david.w.smiley@gmail.com> a écrit :
>>> >> >>
>>> >> >> +1 to a 7.6 —lots of stuff in there
>>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com>
>>> 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 <
>>> caomanhdat317@gmail.com> 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 <
>>> jim.ferenczi@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 <
>>> casstargett@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.ferenczi@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 <
>>> casstargett@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 <
>>> erickerickson@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.smiley@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.ferenczi@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 <
>>> jpountz@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 <
>>> jpountz@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.ferenczi@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 <
>>> erickerickson@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 <
>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>> jpountz@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 <
>>> rcmuir@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 <
>>> jpountz@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 <
>>> jpountz@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 <
>>> rcmuir@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 <jp...@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-unsubscribe@lucene.apache.org
>>> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >> >>>>>>>>> >>>>>> >>>>> >>>
>>> >> >>>>>>>>> >>>>>> >>>>> >
>>> >> >>>>>>>>> >>>>>> >>>>>
>>> >> >>>>>>>>> >>>>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>>> dev-unsubscribe@lucene.apache.org
>>> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
>>> dev-help@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-unsubscribe@lucene.apache.org
>>> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
>>> dev-help@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-unsubscribe@lucene.apache.org
>>> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >> >>>>>>>>>
>>> >> >>> --
>>> >> >>>
>>> >> >>> Nicholas Knize, Ph.D., GISP
>>> >> >>> Geospatial Software Guy  |  Elasticsearch
>>> >> >>> Apache Lucene Committer
>>> >> >>> nknize@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-unsubscribe@lucene.apache.org
>>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>>> >>
>>> >
>>>
>>>
>>> --
>>> Adrien
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>> --
>> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
>> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
>> http://www.solrenterprisesearchserver.com
>>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[S G <sg...@gmail.com>]

It would be nice to see Solr 8 in January soon as there is an enhancement
on nested-documents we are waiting to get our hands on.
Any idea when Solr 8 would be out ?

Thx
SG

On Mon, Dec 17, 2018 at 1:34 PM David Smiley <da...@gmail.com>
wrote:

> I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
> priority = Blocker and status = open and fixVersion = "master (8.0)"
>    click here:
>
> https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20
>
> Thru the end of the month, I intend to work on those issues not yet
> assigned.
>
> On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com> wrote:
>
>> +1
>>
>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com>
>> wrote:
>> >
>> > Hi all,
>> >
>> > Now that 7.6 is out of the door (thanks Nick!) we should think about
>> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create
>> the branch this week - say Wednesday?  Then we should have some time to
>> clean up the master branch and uncover anything that still needs to be done
>> on 8.0 before we start the release process next year.
>> >
>> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
>> wrote:
>> >
>> > 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 <er...@gmail.com>
>> 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 <ji...@gmail.com>
>> 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 <da...@gmail.com>
>> a écrit :
>> >> >>
>> >> >> +1 to a 7.6 —lots of stuff in there
>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com>
>> 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 <
>> caomanhdat317@gmail.com> 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 <
>> jim.ferenczi@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 <
>> casstargett@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.ferenczi@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 <
>> casstargett@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 <
>> erickerickson@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.smiley@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.ferenczi@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 <
>> jpountz@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 <
>> jpountz@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.ferenczi@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 <
>> erickerickson@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 <
>> caomanhdat317@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.ferenczi@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.smiley@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 <
>> jpountz@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 <
>> rcmuir@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 <
>> jpountz@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 <
>> jpountz@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 <
>> rcmuir@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 <jp...@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> >>>
>> >> >>>>>>>>> >>>>>> >>>>> >
>> >> >>>>>>>>> >>>>>> >>>>>
>> >> >>>>>>>>> >>>>>> >>>>>
>> ---------------------------------------------------------------------
>> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>> dev-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
>> dev-help@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
>> dev-help@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-unsubscribe@lucene.apache.org
>> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >> >>>>>>>>>
>> >> >>> --
>> >> >>>
>> >> >>> Nicholas Knize, Ph.D., GISP
>> >> >>> Geospatial Software Guy  |  Elasticsearch
>> >> >>> Apache Lucene Committer
>> >> >>> nknize@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-unsubscribe@lucene.apache.org
>> >> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>
>> >
>>
>>
>> --
>> Adrien
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>> --
> Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

I see 10 JIRA issues matching this filter:   project in (SOLR, LUCENE) AND
priority = Blocker and status = open and fixVersion = "master (8.0)"
   click here:
https://issues.apache.org/jira/issues/?jql=project%20in%20(SOLR%2C%20LUCENE)%20AND%20priority%20%3D%20Blocker%20and%20status%20%3D%20open%20and%20fixVersion%20%3D%20%22master%20(8.0)%22%20

Thru the end of the month, I intend to work on those issues not yet
assigned.

On Mon, Dec 17, 2018 at 4:51 AM Adrien Grand <jp...@gmail.com> wrote:

> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com>
> wrote:
> >
> > Hi all,
> >
> > Now that 7.6 is out of the door (thanks Nick!) we should think about
> cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create
> the branch this week - say Wednesday?  Then we should have some time to
> clean up the master branch and uncover anything that still needs to be done
> on 8.0 before we start the release process next year.
> >
> > On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com>
> wrote:
> >
> > 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 <er...@gmail.com>
> 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 <ji...@gmail.com>
> 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 <da...@gmail.com>
> a écrit :
> >> >>
> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com>
> 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 <
> caomanhdat317@gmail.com> 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 <
> jim.ferenczi@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 <
> casstargett@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.ferenczi@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 <
> casstargett@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 <
> erickerickson@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.smiley@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.ferenczi@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 <
> jpountz@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 <
> jpountz@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.ferenczi@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 <
> erickerickson@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 <
> caomanhdat317@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.ferenczi@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.smiley@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 <
> jpountz@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 <
> rcmuir@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 <
> jpountz@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 <
> jpountz@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 <
> rcmuir@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 <jp...@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> >>>
> >> >>>>>>>>> >>>>>> >>>>> >
> >> >>>>>>>>> >>>>>> >>>>>
> >> >>>>>>>>> >>>>>> >>>>>
> ---------------------------------------------------------------------
> >> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> >>>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >> >>>>>>>>>
> >> >>> --
> >> >>>
> >> >>> Nicholas Knize, Ph.D., GISP
> >> >>> Geospatial Software Guy  |  Elasticsearch
> >> >>> Apache Lucene Committer
> >> >>> nknize@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-unsubscribe@lucene.apache.org
> >> For additional commands, e-mail: dev-help@lucene.apache.org
> >>
> >
>
>
> --
> Adrien
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
> --
Lucene/Solr Search Committer (PMC), Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Adrien Grand <jp...@gmail.com>]

+1

On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward <ro...@gmail.com> wrote:
>
> Hi all,
>
> Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.
>
> On 22 Oct 2018, at 18:12, Cassandra Targett <ca...@gmail.com> wrote:
>
> 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 <er...@gmail.com> 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 <ji...@gmail.com> 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 <da...@gmail.com> a écrit :
>> >>
>> >> +1 to a 7.6 —lots of stuff in there
>> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com> 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 <ca...@gmail.com> 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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <jp...@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-unsubscribe@lucene.apache.org
>> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>>>> >>>>>> >>>>> >>>
>> >>>>>>>>> >>>>>> >>>>> >
>> >>>>>>>>> >>>>>> >>>>>
>> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>> >>>>>>>>>
>> >>> --
>> >>>
>> >>> Nicholas Knize, Ph.D., GISP
>> >>> Geospatial Software Guy  |  Elasticsearch
>> >>> Apache Lucene Committer
>> >>> nknize@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>


-- 
Adrien

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[Alan Woodward <ro...@gmail.com>]

Hi all,

Now that 7.6 is out of the door (thanks Nick!) we should think about cutting the 8.0 branch and moving master to 9.0.  I’ll volunteer to create the branch this week - say Wednesday?  Then we should have some time to clean up the master branch and uncover anything that still needs to be done on 8.0 before we start the release process next year.

> On 22 Oct 2018, at 18:12, Cassandra Targett <casstargett@gmail.com <ma...@gmail.com>> wrote:
> 
> 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 <erickerickson@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@gmail.com>> 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 <david.w.smiley@gmail.com <ma...@gmail.com>> a écrit :
> >>
> >> +1 to a 7.6 —lots of stuff in there
> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nknize@gmail.com <ma...@gmail.com>> 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 <caomanhdat317@gmail.com <ma...@gmail.com>> 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 <jim.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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 <casstargett@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <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.smiley@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@gmail.com>> a écrit :
> >>>>>>>>> >>>
> >>>>>>>>> >>> Đạt, is https://issues.apache.org/jira/browse/SOLR-12639 <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 <jpountz@gmail.com <ma...@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 <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.ferenczi@gmail.com <ma...@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 <erickerickson@gmail.com <ma...@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 <caomanhdat317@gmail.com <ma...@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.ferenczi@gmail.com <ma...@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.smiley@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <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 <jpountz@gmail.com <ma...@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 <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 <https://issues.apache.org/jira/browse/LUCENE-8197>) in an optional
> >>>>>>>>> >>>>>> >>>>> >> clause are also fast.
> >>>>>>>>> >>>>>> >>>>> >>
> >>>>>>>>> >>>>>> >>>>> >> Le jeu. 21 juin 2018 à 03:06, Robert Muir <rcmuir@gmail.com <ma...@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 <jpountz@gmail.com <ma...@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 <https://issues.apache.org/jira/browse/LUCENE-8116>
> >>>>>>>>> >>>>>> >>>>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020 <https://issues.apache.org/jira/browse/LUCENE-8020>
> >>>>>>>>> >>>>>> >>>>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007 <https://issues.apache.org/jira/browse/LUCENE-8007>
> >>>>>>>>> >>>>>> >>>>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198 <https://issues.apache.org/jira/browse/LUCENE-4198>
> >>>>>>>>> >>>>>> >>>>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135 <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 <https://issues.apache.org/jira/browse/LUCENE-8031>
> >>>>>>>>> >>>>>> >>>>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134 <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-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>> >>>>> >>>
> >>>>>>>>> >>>>>> >>>>> >
> >>>>>>>>> >>>>>> >>>>>
> >>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>> >>>>>
> >>>>>>>>> >>>>>> >>> --
> >>>>>>>>> >>>>>> >>> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >>>>>>>>> >>>>>> >>> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >>>>>>>>> >>>>>>
> >>>>>>>>> >>>>>> ---------------------------------------------------------------------
> >>>>>>>>> >>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> >>>>>>
> >>>>>>>>> > --
> >>>>>>>>> > Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >>>>>>>>> > LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> >>>>>>>>>
> >>>>>>>>> ---------------------------------------------------------------------
> >>>>>>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> >>>>>>>>>
> >>> --
> >>>
> >>> Nicholas Knize, Ph.D., GISP
> >>> Geospatial Software Guy  |  Elasticsearch
> >>> Apache Lucene Committer
> >>> nknize@apache.org <ma...@apache.org>
> >>
> >> --
> >> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> >> LinkedIn: http://linkedin.com/in/davidwsmiley <http://linkedin.com/in/davidwsmiley> | Book: http://www.solrenterprisesearchserver.com <http://www.solrenterprisesearchserver.com/>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org <ma...@lucene.apache.org>
> For additional commands, e-mail: dev-help@lucene.apache.org <ma...@lucene.apache.org>
> 

Re: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

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 <er...@gmail.com>
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 <ji...@gmail.com>
> 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 <da...@gmail.com> a
> écrit :
> >>
> >> +1 to a 7.6 —lots of stuff in there
> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com>
> 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 <ca...@gmail.com>
> 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 <ji...@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 <
> casstargett@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.ferenczi@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 <
> casstargett@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 <
> erickerickson@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.smiley@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.ferenczi@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 <
> jpountz@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 <
> jpountz@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.ferenczi@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 <
> erickerickson@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 <
> caomanhdat317@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.ferenczi@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.smiley@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 <
> jpountz@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 <
> rcmuir@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 <
> jpountz@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 <
> jpountz@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 <
> rcmuir@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 <
> jpountz@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-unsubscribe@lucene.apache.org
> >>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>>>>>>>> >>>>>> >>>>> >>>
> >>>>>>>>> >>>>>> >>>>> >
> >>>>>>>>> >>>>>> >>>>>
> >>>>>>>>> >>>>>> >>>>>
> ---------------------------------------------------------------------
> >>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
> dev-unsubscribe@lucene.apache.org
> >>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >>>>>>>>> >>>>>> For additional commands, e-mail:
> dev-help@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-unsubscribe@lucene.apache.org
> >>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
> >>>>>>>>>
> >>> --
> >>>
> >>> Nicholas Knize, Ph.D., GISP
> >>> Geospatial Software Guy  |  Elasticsearch
> >>> Apache Lucene Committer
> >>> nknize@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Erick Erickson <er...@gmail.com>]

+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 <ji...@gmail.com> 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 <da...@gmail.com> a écrit :
>>
>> +1 to a 7.6 —lots of stuff in there
>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com> 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 <ca...@gmail.com> 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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <jp...@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-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>> >>>>>> >>>>> >>>
>>>>>>>>> >>>>>> >>>>> >
>>>>>>>>> >>>>>> >>>>>
>>>>>>>>> >>>>>> >>>>> ---------------------------------------------------------------------
>>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>>
>>> --
>>>
>>> Nicholas Knize, Ph.D., GISP
>>> Geospatial Software Guy  |  Elasticsearch
>>> Apache Lucene Committer
>>> nknize@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

+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 <da...@gmail.com> a
écrit :

> +1 to a 7.6 —lots of stuff in there
> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com> 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 <ca...@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 <ji...@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 <ca...@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 <ji...@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 <
>>>>>> casstargett@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 <
>>>>>>> erickerickson@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.smiley@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.ferenczi@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 <jp...@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 <jp...@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.ferenczi@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 <
>>>>>>>> erickerickson@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 <
>>>>>>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>>>>>>> jpountz@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 <
>>>>>>>> rcmuir@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 <
>>>>>>>> jpountz@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 <
>>>>>>>> jpountz@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 <
>>>>>>>> rcmuir@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 <
>>>>>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>>>> dev-help@lucene.apache.org
>>>>>>>> >>>>>> >>>>> >>>
>>>>>>>> >>>>>> >>>>> >
>>>>>>>> >>>>>> >>>>>
>>>>>>>> >>>>>> >>>>>
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
>>>>>>>> dev-help@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-unsubscribe@lucene.apache.org
>>>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>>
>>>>>>>> --
>>
>> Nicholas Knize, Ph.D., GISP
>> Geospatial Software Guy  |  Elasticsearch
>> Apache Lucene Committer
>> nknize@apache.org
>>
> --
> Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
> LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
> http://www.solrenterprisesearchserver.com
>

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

+1 to a 7.6 —lots of stuff in there
On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize <nk...@gmail.com> 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 <ca...@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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <
>>>>>> erickerickson@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.smiley@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.ferenczi@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 <jp...@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 <jp...@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.ferenczi@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 <
>>>>>>> erickerickson@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 <
>>>>>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>>>>>> jpountz@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 <
>>>>>>> rcmuir@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 <
>>>>>>> jpountz@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 <
>>>>>>> jpountz@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 <
>>>>>>> rcmuir@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 <
>>>>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>>> dev-help@lucene.apache.org
>>>>>>> >>>>>> >>>>> >>>
>>>>>>> >>>>>> >>>>> >
>>>>>>> >>>>>> >>>>>
>>>>>>> >>>>>> >>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>>> >>>>>> >>>>> For additional commands, e-mail:
>>>>>>> dev-help@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-unsubscribe@lucene.apache.org
>>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>>
>>>>>>> --
>
> Nicholas Knize, Ph.D., GISP
> Geospatial Software Guy  |  Elasticsearch
> Apache Lucene Committer
> nknize@apache.org
>
-- 
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com

Re: Lucene/Solr 8.0

[Nicholas Knize <nk...@gmail.com>]

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 <ca...@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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <
>>>>> erickerickson@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.smiley@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.ferenczi@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 <jp...@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 <jp...@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.ferenczi@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 <
>>>>>> erickerickson@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 <
>>>>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>>>>> jpountz@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 <
>>>>>> rcmuir@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 <
>>>>>> jpountz@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 <
>>>>>> jpountz@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 <
>>>>>> rcmuir@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 <
>>>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>>>>> dev-help@lucene.apache.org
>>>>>> >>>>>> >>>>> >>>
>>>>>> >>>>>> >>>>> >
>>>>>> >>>>>> >>>>>
>>>>>> >>>>>> >>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> >>>>>> >>>>> To unsubscribe, e-mail:
>>>>>> dev-unsubscribe@lucene.apache.org
>>>>>> >>>>>> >>>>> For additional commands, e-mail:
>>>>>> dev-help@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-unsubscribe@lucene.apache.org
>>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>>
>>>>>> --

Nicholas Knize, Ph.D., GISP
Geospatial Software Guy  |  Elasticsearch
Apache Lucene Committer
nknize@apache.org

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh <ca...@gmail.com>]

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 <ji...@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 <ca...@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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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.ferenczi@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 <
>>>>> erickerickson@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 <
>>>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>>>> jpountz@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 <rc...@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 <
>>>>> jpountz@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 <
>>>>> jpountz@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 <
>>>>> rcmuir@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 <
>>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>>>> dev-help@lucene.apache.org
>>>>> >>>>>> >>>>> >>>
>>>>> >>>>>> >>>>> >
>>>>> >>>>>> >>>>>
>>>>> >>>>>> >>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>>> >>>>> For additional commands, e-mail:
>>>>> dev-help@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-unsubscribe@lucene.apache.org
>>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>>

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

> 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 <ca...@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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <
>>>> erickerickson@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 <
>>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>>> jpountz@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 <rc...@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 <
>>>> jpountz@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 <
>>>> jpountz@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 <
>>>> rcmuir@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 <
>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>>> dev-help@lucene.apache.org
>>>> >>>>>> >>>>> >>>
>>>> >>>>>> >>>>> >
>>>> >>>>>> >>>>>
>>>> >>>>>> >>>>>
>>>> ---------------------------------------------------------------------
>>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>> >>>>>> >>>>> For additional commands, e-mail:
>>>> dev-help@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-unsubscribe@lucene.apache.org
>>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>
>>>>

Re: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

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 <ji...@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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <
>>> erickerickson@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 <
>>> caomanhdat317@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.ferenczi@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.smiley@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 <
>>> jpountz@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 <rc...@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 <
>>> jpountz@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 <
>>> jpountz@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 <
>>> rcmuir@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 <
>>> jpountz@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-unsubscribe@lucene.apache.org
>>> >>>>>> >>>>> >>> For additional commands, e-mail:
>>> dev-help@lucene.apache.org
>>> >>>>>> >>>>> >>>
>>> >>>>>> >>>>> >
>>> >>>>>> >>>>>
>>> >>>>>> >>>>>
>>> ---------------------------------------------------------------------
>>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>
>>>

Re: Lucene/Solr 8.0

[jim ferenczi <ji...@gmail.com>]

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 <ca...@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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <
>> erickerickson@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 <
>> caomanhdat317@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.ferenczi@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.smiley@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 <
>> jpountz@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 <rc...@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 <
>> jpountz@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 <
>> jpountz@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 <
>> rcmuir@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 <
>> jpountz@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-unsubscribe@lucene.apache.org
>> >>>>>> >>>>> >>> For additional commands, e-mail:
>> dev-help@lucene.apache.org
>> >>>>>> >>>>> >>>
>> >>>>>> >>>>> >
>> >>>>>> >>>>>
>> >>>>>> >>>>>
>> ---------------------------------------------------------------------
>> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>> For additional commands, e-mail: dev-help@lucene.apache.org
>>
>>

Re: Lucene/Solr 8.0

[Cassandra Targett <ca...@gmail.com>]

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 <er...@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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <
> erickerickson@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 <
> caomanhdat317@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.ferenczi@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.smiley@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 <jp...@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 <rc...@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 <
> jpountz@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 <
> jpountz@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 <
> rcmuir@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 <
> jpountz@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-unsubscribe@lucene.apache.org
> >>>>>> >>>>> >>> For additional commands, e-mail:
> dev-help@lucene.apache.org
> >>>>>> >>>>> >>>
> >>>>>> >>>>> >
> >>>>>> >>>>>
> >>>>>> >>>>>
> ---------------------------------------------------------------------
> >>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> >>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> >>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Erick Erickson <er...@gmail.com>]

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 <da...@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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <jp...@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-unsubscribe@lucene.apache.org
>>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>> >>>>> >>>
>>>>>> >>>>> >
>>>>>> >>>>>
>>>>>> >>>>> ---------------------------------------------------------------------
>>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org

Re: Lucene/Solr 8.0

[David Smiley <da...@gmail.com>]

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 <ji...@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 <jp...@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 <jp...@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 <ji...@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 <er...@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 <ca...@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 <ji...@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 <da...@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 <jp...@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 <rc...@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 <jp...@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 <jp...@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 <rc...@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 <
>>>>> jpountz@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-unsubscribe@lucene.apache.org
>>>>> >>>>> >>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>> >>>>> >>>
>>>>> >>>>> >
>>>>> >>>>>
>>>>> >>>>>
>>>>> ---------------------------------------------------------------------
>>>>> >>>>> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
>>>>> >>>>> For additional commands, e-mail: dev-help@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-unsubscribe@lucene.apache.org
>>>>> For additional commands, e-mail: dev-help@lucene.apache.org
>>>>>
>>>>> --
Lucene/Solr Search Committer, Consultant, Developer, Author, Speaker
LinkedIn: http://linkedin.com/in/davidwsmiley | Book:
http://www.solrenterprisesearchserver.com