Re: Lucene/Solr 8.0

[Jörn Franke]

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  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 
>>>>>>  a écrit :
>>>>>> 
>>>>>> 
>>>>>> sure, thanks Jim!
>>>>>> 
>>>>>> Tommaso
>>>>>> 
>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>  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 
>>>>>>  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
>>>>>>  ha scritto:
>>>>>> 
>>>>>> 
>>>>>> Hi Noble,
>>>>>> 
>>>>>> No it hasn't created yet.
>>>>>> 
>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>>>>>> 
>>>>>> 
>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>> 
>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley  
>>>>>> wrote:
>>>>>> 
>>>>>> 
>>>>>> I finally have a patch up

Re: Lucene/Solr 8.0

[David Smiley]

 Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley 
> 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  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  >:
>
> 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  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  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  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  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: u...@thetaphi.de
>
> -Original Message-
> From: Adrien Grand 
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev 
> 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 
> 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 
>
> 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 JIR

Re: Lucene/Solr 8.0

[Jan Høydahl]

jection 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  
>>>> a écrit :
>>>> 
>>>> 
>>>> sure, thanks Jim!
>>>> 
>>>> Tommaso
>>>> 
>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>  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  
>>>> 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
>>>>  ha scritto:
>>>> 
>>>> 
>>>> Hi Noble,
>>>> 
>>>> No it hasn't created yet.
>>>> 
>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>>>> 
>>>> 
>>>> Is the branch already cut for 8.0? which is it?
>>>> 
>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley  
>>>> 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  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 
>>>> :
>>>> 
>>>> 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 

Re: Lucene/Solr 8.0

[Adrien Grand]

 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  
>> > 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
>> >  ha scritto:
>> >
>> >
>> > Hi Noble,
>> >
>> > No it hasn't created yet.
>> >
>> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>> >
>> >
>> > Is the branch already cut for 8.0? which is it?
>> >
>> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley  
>> > 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  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 
>> > :
>> >
>> > 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  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  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  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  wrote:
>> >
>> >
>> > Cool,
>> >
>> > I am working on giving my best release time guess as possible on the 

Re: Lucene/Solr 8.0

[David Smiley]

43, jim ferenczi  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.teof...@gmail.com> a écrit :
> >
> >
> > sure, thanks Jim!
> >
> > Tommaso
> >
> > Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
> >  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.teof...@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
> >  ha scritto:
> >
> >
> > Hi Noble,
> >
> > No it hasn't created yet.
> >
> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
> >
> >
> > Is the branch already cut for 8.0? which is it?
> >
> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley 
> 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 
> 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 <
> tomasflo...@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  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

Re: Lucene/Solr 8.0

[Adrien Grand]

 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  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
>  ha scritto:
>
>
> Hi Noble,
>
> No it hasn't created yet.
>
> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley  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  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 :
>
> 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  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  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  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  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: u...@thetaphi.de
>
> -Original Message-
> From: Adrien Grand 
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev 
> 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 
> 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 
>
> a 

Re: Lucene/Solr 8.0

[Noble Paul]

t;>> 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 
>>>>>>>> >>>>>>>>>>>>  a écrit :
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> sure, thanks Jim!
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> Tommaso
>>>>>>>> >>>>>>>>>>>>>
>>>>>>>> >>>>>>>>>>>>> Il giorno lun 28 gen 2019 alle ore 10:35 jim ferenczi
>>>>>>>> >>>>>>>>>>>>>  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.
>&g

Re: Lucene/Solr 8.0

[Alan Woodward]

;> 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 
>>>>>>>>>>>>>>  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
>>>>>>>>>>>>>>>  ha scritto:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Hi Noble,
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> No it hasn't created yet.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul 
>>>>>>>>>>>>>>>>  wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Is the branch already cut for 8.0? which is it?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Mon, Jan 28, 2019 at 4:03 AM David Smiley 
>>>>>>>>>>>>>>>>>  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 
>>>>>>>>>>>>>>>>>>  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
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>

Re: Lucene/Solr 8.0

[Jason Gerlowski]

gt;>>> > >>>> >>> >> (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
>>>> > >>>> >>> >>  ha scritto:
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > Hi Noble,
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > No it hasn't created yet.
>>>> > >>>> >>> >> >
>>>> > >>>> >>> >> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul 
>>>> > >>>> >>> >> >  wrote:
>>>> > >>>> >>> >> > >
>>>> > >>>> >>> >> > > Is the branch already cut for 8.0? which is it?
>>>> > >>>> >>> >> > >
>>>> > >>>> >>> >> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley 
>>>> > >>>> >>> >> > >  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 
>>>> > >>>> >>> >> > > >  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 
>>>> > >>>> >>> >> > > >> :
>>>> > >>>> >>> >> > > >>
>>>> > >>>> >>> >> > > >> 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 en

Re: Lucene/Solr 8.0

[Kevin Risden]

> > >> 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 
> >>>> >>> >> > > >> :
> >>>> >>> >> > > >>
> >>>> >>> >> > > >> 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 
> >>>> >>> >> > > >>  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 
> >>>> >>> >> > > >>>  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
> >>>> >&

Re: Lucene/Solr 8.0

[Adrien Grand]

t; 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 
>>>> >>> >> > > >>  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 
>>>> >>> >> > > >>>  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 
>>>> >>> >> > > >>>>  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 
>>>> >>> &g

Re: Lucene/Solr 8.0

[Kevin Risden]

ried 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 
>>> >>> >> > > >>>  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 
>>> >>> >> > > >>>>  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 
>>> >>> >> > > >>>> >  wrote:
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> Cool,
>>> >>> >> > > >>>> >>
>>> >>> >> > > >>>> >> I am working on giving my best release time guess as 
>>> >>> >> > > >>>> >> possible on the FOSDEM conference!
>>> >>> >>

Re: Lucene/Solr 8.0

[Kevin Risden]

> > > >> 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 
>>> >> > > >> :
>>> >> > > >>
>>> >> > > >> 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  
>>> >> > > >> 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  
>>> >> > > >>> 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  
>>> >> > > >>>> wrote:
>>> >> > > >>>> >
>>> >> > > >>>&

Re: Lucene/Solr 8.0

[Tommaso Teofili]

ng 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  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  
>> > > >>>> > 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: u...@thetaphi.de
>> > > >>>> >>
>> > > >>>> >> > -Original Message-
>> > > >>>> >> > From: Adrien Grand 
>> > > >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> > > >>>> >> > To: Lucene Dev 
>> > > >>>> >> > 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 
>> > > >>>> >> > 
>> > > >>>> >> > 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 
>> > > >>>> >> > > 
>> > > >>>> >> > 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.
>> > > >>>> >&g

Re: Lucene/Solr 8.0

[jim ferenczi]

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 
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
>  ha scritto:
> >
> > Hi Noble,
> >
> > No it hasn't created yet.
> >
> > On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
> > >
> > > Is the branch already cut for 8.0? which is it?
> > >
> > > On Mon, Jan 28, 2019 at 4:03 AM David Smiley 
> 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 
> 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 <
> tomasflo...@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 
> 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 
> 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 
> 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

Re: Lucene/Solr 8.0

[Tommaso Teofili]

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
 ha scritto:
>
> Hi Noble,
>
> No it hasn't created yet.
>
> On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
> >
> > Is the branch already cut for 8.0? which is it?
> >
> > On Mon, Jan 28, 2019 at 4:03 AM David Smiley  
> > 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  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 
> > >> :
> > >>
> > >> 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  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  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  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  
> > >>>> > wrote:
> > >>>> >>
> > >>>> >> Cool,
> > >>>> >>
> > >>>> >> I am working on giving my best release time guess as possible on 
> > >>>> >> the FOSDEM confe

Re: Lucene/Solr 8.0

[Adrien Grand]

Hi Noble,

No it hasn't created yet.

On Mon, Jan 28, 2019 at 3:55 AM Noble Paul  wrote:
>
> Is the branch already cut for 8.0? which is it?
>
> On Mon, Jan 28, 2019 at 4:03 AM David Smiley  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  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 
> >> :
> >>
> >> 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  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  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  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  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: u...@thetaphi.de
> >>>> >>
> >>>> >> > -Original Message-
> >>>> >> > From: Adrien Grand 
> >>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >>>> >> > To: Lucene Dev 
> >>>> >> > Subj

Re: Lucene/Solr 8.0

[Noble Paul]

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

On Mon, Jan 28, 2019 at 4:03 AM David Smiley  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  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 :
>>
>> 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  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  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  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  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: u...@thetaphi.de
>>>> >>
>>>> >> > -Original Message-
>>>> >> > From: Adrien Grand 
>>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>>> >> > To: Lucene Dev 
>>>> >> > 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 
>>>> >> > wrote:
>>>> >> > >
>>>> >> > > Hi,
>>>> >> > > As we agreed some time ago I'd like to start on releasing 8.0. The 
>>>> >

Re: Lucene/Solr 8.0

[David Smiley]

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  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  >:
>
> 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  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  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  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  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=gmail=g>
>>> >> http://www.thetaphi.de
>>> >> eMail: u...@thetaphi.de
>>> >>
>>> >> > -Original Message-
>>> >> > From: Adrien Grand 
>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >> > To: Lucene Dev 
>>> >> > 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.feren...@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
>>>

Re: Lucene/Solr 8.0

[Jan Høydahl]

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 :
> 
> 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  <mailto:gus.h...@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  <mailto:jpou...@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  <mailto:gus.h...@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  > <mailto:u...@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: u...@thetaphi.de <mailto:u...@thetaphi.de>
> >>
> >> > -Original Message-
> >> > From: Adrien Grand mailto:jpou...@gmail.com>>
> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > To: Lucene Dev mailto:dev@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  >> > <mailto:jim.feren...@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  >> > > <mailto:romseyg...@gmail.com>>
> >> > a écrit :
> >> > >>
> >> > >> I’ve started to work through t

Re: Lucene/Solr 8.0

[Kevin Risden]

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
 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  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  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  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  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: u...@thetaphi.de
>>> >>
>>> >> > -Original Message-
>>> >> > From: Adrien Grand 
>>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>>> >> > To: Lucene Dev 
>>> >> > 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 
>>> >> > 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
>&

Re: Lucene/Solr 8.0

[Tomás Fernández Löbbe]

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  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  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  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  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: u...@thetaphi.de
>> >>
>> >> > -Original Message-
>> >> > From: Adrien Grand 
>> >> > Sent: Thursday, January 24, 2019 5:33 PM
>> >> > To: Lucene Dev 
>> >> > 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 > >
>> >> > 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 > >
>> >> > 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.
>> >

Re: Lucene/Solr 8.0

[Gus Heck]

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  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  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  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: u...@thetaphi.de
> >>
> >> > -Original Message-
> >> > From: Adrien Grand 
> >> > Sent: Thursday, January 24, 2019 5:33 PM
> >> > To: Lucene Dev 
> >> > 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 
> >> > 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 
> >> > 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 
> >> > 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  wrote:
> >> >

Re: Lucene/Solr 8.0

[Adrien Grand]

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  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  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: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Adrien Grand 
>> > Sent: Thursday, January 24, 2019 5:33 PM
>> > To: Lucene Dev 
>> > 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 
>> > 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 
>> > 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 
>> > 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  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: u...@thetaphi.de
>> > >>
>> > >> From: Alan Woodward 
>> > >> 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.
>> > >>

Re: Lucene/Solr 8.0

[Gus Heck]

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  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: u...@thetaphi.de
>
> > -Original Message-
> > From: Adrien Grand 
> > Sent: Thursday, January 24, 2019 5:33 PM
> > To: Lucene Dev 
> > 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 
> > 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 
> > 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 
> > 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  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: u...@thetaphi.de
> > >>
> > >> From: Alan Woodward 
> > >> 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 
> > wrote:
> > >>
> > >> January.
> > >>
> > >> On Wed, Dec 19, 2018 at 2:04 AM S G 
> > 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 ?
> > >>
> > >> Th

RE: Lucene/Solr 8.0

[Uwe Schindler]

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: u...@thetaphi.de

> -Original Message-
> From: Adrien Grand 
> Sent: Thursday, January 24, 2019 5:33 PM
> To: Lucene Dev 
> 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 
> 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 
> 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 
> 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  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: u...@thetaphi.de
> >>
> >> From: Alan Woodward 
> >> 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 
> wrote:
> >>
> >> January.
> >>
> >> On Wed, Dec 19, 2018 at 2:04 AM S G 
> 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
>  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 
> wrote:
> >>
> >> +1
> >>
> >> On Mon, Dec 1

Re: Lucene/Solr 8.0

[Adrien Grand]

+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  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  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  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  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: u...@thetaphi.de
>>
>> From: Alan Woodward 
>> 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  wrote:
>>
>> January.
>>
>> On Wed, Dec 19, 2018 at 2:04 AM S G  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  
>> 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  wrote:
>>
>> +1
>>
>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward  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  wrote:
>> >
>> > I'm a bit delayed, but +1 on the 7.6 and 8.0 plan fro

Re: Lucene/Solr 8.0

[jim ferenczi]

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  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  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  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: u...@thetaphi.de
>
> *From:* Alan Woodward 
> *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  wrote:
>
> January.
>
> On Wed, Dec 19, 2018 at 2:04 AM S G  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 
> 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  wrote:
>
> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward 
> 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 
> 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 
> 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 
> 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. 

Re: Lucene/Solr 8.0

[Alan Woodward]

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  <mailto:romseyg...@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 > <mailto:u...@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: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>  
>> From: Alan Woodward mailto:romseyg...@gmail.com>> 
>> Sent: Monday, January 7, 2019 11:30 AM
>> To: dev@lucene.apache.org <mailto: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 >> <mailto:david.w.smi...@gmail.com>> wrote:
>>>  
>>> January.
>>>  
>>> On Wed, Dec 19, 2018 at 2:04 AM S G >> <mailto:sg.online.em...@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 >>> <mailto:david.w.smi...@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 >>>> <mailto:jpou...@gmail.com>> wrote:
>>>>>> +1
>>>>>> 
>>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward >>>>> <mailto:romseyg...@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 s

Re: Lucene/Solr 8.0

[Alan Woodward]

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  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: u...@thetaphi.de <mailto:u...@thetaphi.de>
>  
> From: Alan Woodward mailto:romseyg...@gmail.com>> 
> Sent: Monday, January 7, 2019 11:30 AM
> To: dev@lucene.apache.org <mailto: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 > <mailto:david.w.smi...@gmail.com>> wrote:
>>  
>> January.
>>  
>> On Wed, Dec 19, 2018 at 2:04 AM S G > <mailto:sg.online.em...@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 >> <mailto:david.w.smi...@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 >>> <mailto:jpou...@gmail.com>> wrote:
>>>>> +1
>>>>> 
>>>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward >>>> <mailto:romseyg...@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 >>>> > <mailto:casstarg...@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 >>>> > <mailto:erickerick...@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 >>>> >> <mailto:jim.feren...@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 
>>&

Re: Lucene/Solr 8.0

[Dawid Weiss]

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  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  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 
> > mailto:jim.feren...@gmail.com>> wrote:
> > : > >> >>>
> > : > >> >>> Ok thanks for answering.
> > : > >> >>>
> > : > >> >>> > - I think Solr needs a couple more weeks since the work 
> > Dat is doing isn't quite done yet.
> > : > >> >>>
> > : > >> >>> We can wait a few more weeks to create the branch but I 
> > don't think that one action (creating the branch) prevents the other (the 
> > work Dat is doing).
> > : > >> >>> HTTP/2 is one of the blocker for the release but it can be 
> > done in master and backported to the appropriate branch as any other 
> > feature ? We just need an issue with the blocker label to ensure that
> > : > >> >>> we don't miss it ;). Creating the branch early would also 
> > help in case you don't want to release all the work at once in 8.0.0.
> > : > >> >>> Next week was just a proposal, what I meant was soon because 
> > we target a release in a few months.
> > : > >> >>>
> > : > >> >>>
> > : > >> >>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
> > mailto:casstarg...@gmail.com>> a écrit :
> > : > >> 
> > : > >>  IMO next week is a bit too soon for the branch - I think 
> > Solr needs a couple more weeks since the work Dat is doing isn't quite done 
> > yet.
> > : > >> 
> > : > >>  Solr needs the HTTP/2 work Dat has been doing, and he told 
> > me yesterday he feels it is nearly ready to be merged into master. However, 
> > it does require a new release of Jetty to Solr is able to retain Kerberos 
> > authentication support (Dat has been working with that team to help test 
> > the changes Jetty needs to support Kerberos with HTTP/2). They should get 
> > that release out soon, but we are dependent on them a little bit.
> > : > >> 
> > : > >>  He can hopefully reply with more details on his status and 
> > what else needs to be done.
> > : > >> 
> > : > >>  Once Dat merges his work, IMO we should leave it in master 
> > for a little bit. While he has been beasting and testing with Jenkins as he 
> > goes along, I think it would be good to have all the regular master builds 
> > work on it for a little bit also.
> > : > >> 
> > : > >>  Of the other blockers, the only other large-ish one is to 
> > fully remove Trie* fields, which some of us also discussed yesterday and it 
> > seemed we concluded that Solr isn't really ready to do that. The 
> > performance issues with single value lookups are a major obstacle. It would 
> > be nice if someone with a bit more experience with that could comment in 
> > the issue (SOLR-12632) and/or unmark it as a blocker.
> > : > >> 
> > : > >>  Cassandra
> > : > >> 
> > : > >>  On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson 
> > mailto:erickerick...@gmail.com>> wrote:
> > : > >> >
> > : > >> > I find 9 open blockers for 8.0:
> > : > >> >
> > : > >> > 
> > https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN
> >  
> > 
> > : > >> >
> > : > >> 

Re: Lucene/Solr 8.0

[Alan Woodward]

> 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  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 
> mailto:jim.feren...@gmail.com>> wrote:
> : > >> >>>
> : > >> >>> Ok thanks for answering.
> : > >> >>>
> : > >> >>> > - I think Solr needs a couple more weeks since the work Dat 
> is doing isn't quite done yet.
> : > >> >>>
> : > >> >>> We can wait a few more weeks to create the branch but I don't 
> think that one action (creating the branch) prevents the other (the work Dat 
> is doing).
> : > >> >>> HTTP/2 is one of the blocker for the release but it can be 
> done in master and backported to the appropriate branch as any other feature 
> ? We just need an issue with the blocker label to ensure that
> : > >> >>> we don't miss it ;). Creating the branch early would also help 
> in case you don't want to release all the work at once in 8.0.0.
> : > >> >>> Next week was just a proposal, what I meant was soon because 
> we target a release in a few months.
> : > >> >>>
> : > >> >>>
> : > >> >>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
> mailto:casstarg...@gmail.com>> a écrit :
> : > >> 
> : > >>  IMO next week is a bit too soon for the branch - I think Solr 
> needs a couple more weeks since the work Dat is doing isn't quite done yet.
> : > >> 
> : > >>  Solr needs the HTTP/2 work Dat has been doing, and he told me 
> yesterday he feels it is nearly ready to be merged into master. However, it 
> does require a new release of Jetty to Solr is able to retain Kerberos 
> authentication support (Dat has been working with that team to help test the 
> changes Jetty needs to support Kerberos with HTTP/2). They should get that 
> release out soon, but we are dependent on them a little bit.
> : > >> 
> : > >>  He can hopefully reply with more details on his status and 
> what else needs to be done.
> : > >> 
> : > >>  Once Dat merges his work, IMO we should leave it in master 
> for a little bit. While he has been beasting and testing with Jenkins as he 
> goes along, I think it would be good to have all the regular master builds 
> work on it for a little bit also.
> : > >> 
> : > >>  Of the other blockers, the only other large-ish one is to 
> fully remove Trie* fields, which some of us also discussed yesterday and it 
> seemed we concluded that Solr isn't really ready to do that. The performance 
> issues with single value lookups are a major obstacle. It would be nice if 
> someone with a bit more experience with that could comment in the issue 
> (SOLR-12632) and/or unmark it as a blocker.
> : > >> 
> : > >>  Cassandra
> : > >> 
> : > >>  On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson 
> mailto:erickerick...@gmail.com>> wrote:
> : > >> >
> : > >> > I find 9 open blockers for 8.0:
> : > >> >
> : > >> > 
> https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN
>  
> 
> : > >> >
> : > >> > As David mentioned, many of the SOlr committers are at 
> Activate, which
> : > >> > ends Thursday so feedback (and work) may be a bit delayed.
> : > >> > On Wed, Oct 17, 2018 at 8:11 AM David Smiley 
> mailto:david.w.smi...@gmail.com>> wrote:
> : > >> > >
> : > >> > > Hi,
> : > >> 

RE: Lucene/Solr 8.0

[Uwe Schindler]

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: u...@thetaphi.de

 

From: Alan Woodward  
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 mailto:david.w.smi...@gmail.com> > wrote:

 

January.

 

On Wed, Dec 19, 2018 at 2:04 AM S G mailto:sg.online.em...@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 mailto:david.w.smi...@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 mailto:jpou...@gmail.com> > wrote:

+1

On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward mailto:romseyg...@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  <mailto:casstarg...@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  <mailto:erickerick...@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 > <mailto:jim.feren...@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 > > <mailto:david.w.smi...@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 > >> <mailto:nkn...@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 > >>> <mailto:caomanhdat...@gmail.com> > wrote:
>> >>>>
>> >>>> Thanks Cassandra and Jim,
>> >>>>
>> >&

Re: Lucene/Solr 8.0

[Chris Hostetter]

: 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 
mailto:jim.feren...@gmail.com>> wrote:
: > >> >>>
: > >> >>> Ok thanks for answering.
: > >> >>>
: > >> >>> > - I think Solr needs a couple more weeks since the work Dat is 
doing isn't quite done yet.
: > >> >>>
: > >> >>> We can wait a few more weeks to create the branch but I don't 
think that one action (creating the branch) prevents the other (the work Dat is 
doing).
: > >> >>> HTTP/2 is one of the blocker for the release but it can be done 
in master and backported to the appropriate branch as any other feature ? We 
just need an issue with the blocker label to ensure that
: > >> >>> we don't miss it ;). Creating the branch early would also help 
in case you don't want to release all the work at once in 8.0.0.
: > >> >>> Next week was just a proposal, what I meant was soon because we 
target a release in a few months.
: > >> >>>
: > >> >>>
: > >> >>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett 
mailto:casstarg...@gmail.com>> a écrit :
: > >> 
: > >>  IMO next week is a bit too soon for the branch - I think Solr 
needs a couple more weeks since the work Dat is doing isn't quite done yet.
: > >> 
: > >>  Solr needs the HTTP/2 work Dat has been doing, and he told me 
yesterday he feels it is nearly ready to be merged into master. However, it 
does require a new release of Jetty to Solr is able to retain Kerberos 
authentication support (Dat has been working with that team to help test the 
changes Jetty needs to support Kerberos with HTTP/2). They should get that 
release out soon, but we are dependent on them a little bit.
: > >> 
: > >>  He can hopefully reply with more details on his status and what 
else needs to be done.
: > >> 
: > >>  Once Dat merges his work, IMO we should leave it in master for 
a little bit. While he has been beasting and testing with Jenkins as he goes 
along, I think it would be good to have all the regular master builds work on 
it for a little bit also.
: > >> 
: > >>  Of the other blockers, the only other large-ish one is to fully 
remove Trie* fields, which some of us also discussed yesterday and it seemed we 
concluded that Solr isn't really ready to do that. The performance issues with 
single value lookups are a major obstacle. It would be nice if someone with a 
bit more experience with that could comment in the issue (SOLR-12632) and/or 
unmark it as a blocker.
: > >> 
: > >>  Cassandra
: > >> 
: > >>  On Wed, Oct 17, 2018 at 8:38 AM Erick Erickson 
mailto:erickerick...@gmail.com>> wrote:
: > >> >
: > >> > I find 9 open blockers for 8.0:
: > >> >
: > >> > 
https://issues.apache.org/jira/issues/?jql=project%20%3D%20SOLR%20AND%20priority%20%3D%20Blocker%20AND%20status%20%3D%20OPEN
 

: > >> >
: > >> > As David mentioned, many of the SOlr committers are at 
Activate, which
: > >> > ends Thursday so feedback (and work) may be a bit delayed.
: > >> > On Wed, Oct 17, 2018 at 8:11 AM David Smiley 
mailto:david.w.smi...@gmail.com>> wrote:
: > >> > >
: > >> > > Hi,
: > >> > >
: > >> > > Thanks for volunteering to do the 8.0 release Jim!
: > >> > >
: > >> > > Many of us are at the Activate Conference in Montreal.  We 
had a committers meeting where we discussed some of the blockers.  I think only 
a couple items were raised.  I'll leave Dat to discuss the one on HTTP2.  On 
the Solr nested docs front, I articulated one and we mostly came to a decision 
on how to do it.  It's not "hard" just a matter of how to hook in some 
functionality so that it's user-friendly.  I'll file an issue for this.  
Inexplicably I'm sheepish about marking issues "blocker" but I shouldn't be.  

Re: Lucene/Solr 8.0

[Alan Woodward]

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  wrote:
> 
> January.
> 
> On Wed, Dec 19, 2018 at 2:04 AM S G  > 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  > 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  > wrote:
> +1
> 
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward  > 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  > > 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  > > 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  >> > 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  >> > > a écrit :
> >> >>
> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  >> >> > 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  >> >>> > 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  >>  > 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 

Re: Lucene/Solr 8.0

[David Smiley]

January.

On Wed, Dec 19, 2018 at 2:04 AM S G  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 
> 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  wrote:
>>
>>> +1
>>>
>>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward 
>>> 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 
>>> 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 <
>>> erickerick...@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 
>>> 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.smi...@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 
>>> 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 <
>>> caomanhdat...@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.feren...@gmail.com> wrote:
>>> >> >
>>> >> > > But if you're working with a different assumption - that just
>>> the existence of the branch does not stop Dat from still merging his work
>>> and the work being included in 8.0 - then I agree, waiting for him to merge
>>> doesn't need to stop the creation of the branch.
>>> >> >
>>> >> > Yes that's my reasoning. This issue is a blocker so we won't
>>> release without it but we can work on the branch in the meantime and let
>>> other people work on new features that are not targeted to 8.
>>> >> >
>>> >> > Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <
>>> casstarg...@gmail.com> a écrit :
>>> >> >>
>>> >> >> OK - I was making an assumption that the timeline for the
>>> first 8.0 RC would be ASAP after the branch is created.
>>> >> >>
>>> >> >> It's a common perception that making a branch freezes adding
>>> new features to the release, perhaps in an unofficial way (more of a
>>> courtesy rather than a rule). But if you're working with a different
>>> assumption - that just the existence of the branch does not stop Dat from
>>> still merging his work and the work being included in 8.0 - then I agree,
>>> waiting for him to merge doesn't need to stop the creation of the branch.
>>> >> >>
>>> >> >> If, however, once the branch is there people object to Dat
>>> merging his work because it's "too late", then the branch shouldn't be
>>> created yet because we want to really try to 

Re: Lucene/Solr 8.0

[S G]

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 
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  wrote:
>
>> +1
>>
>> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward 
>> 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 
>> 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 
>> 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 
>> 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 
>> a écrit :
>> >> >>
>> >> >> +1 to a 7.6 —lots of stuff in there
>> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize 
>> 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 <
>> caomanhdat...@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.feren...@gmail.com> wrote:
>> >> >
>> >> > > But if you're working with a different assumption - that just
>> the existence of the branch does not stop Dat from still merging his work
>> and the work being included in 8.0 - then I agree, waiting for him to merge
>> doesn't need to stop the creation of the branch.
>> >> >
>> >> > Yes that's my reasoning. This issue is a blocker so we won't
>> release without it but we can work on the branch in the meantime and let
>> other people work on new features that are not targeted to 8.
>> >> >
>> >> > Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <
>> casstarg...@gmail.com> a écrit :
>> >> >>
>> >> >> OK - I was making an assumption that the timeline for the first
>> 8.0 RC would be ASAP after the branch is created.
>> >> >>
>> >> >> It's a common perception that making a branch freezes adding
>> new features to the release, perhaps in an unofficial way (more of a
>> courtesy rather than a rule). But if you're working with a different
>> assumption - that just the existence of the branch does not stop Dat from
>> still merging his work and the work being included in 8.0 - then I agree,
>> waiting for him to merge doesn't need to stop the creation of the branch.
>> >> >>
>> >> >> If, however, once the branch is there people object to Dat
>> merging his work because it's "too late", then the branch shouldn't be
>> created yet because we want to really try to clear that blocker for 8.0.
>> >> >>
>> >> >> Cassandra
>> >> >>
>> >> >> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <
>> jim.feren...@gmail.com> wrote:
>> >> >>>
>> >> >>> Ok thanks for answering.
>> 

Re: Lucene/Solr 8.0

[David Smiley]

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  wrote:

> +1
>
> On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward 
> 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 
> 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 
> 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 
> 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 
> a écrit :
> >> >>
> >> >> +1 to a 7.6 —lots of stuff in there
> >> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize 
> 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 <
> caomanhdat...@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.feren...@gmail.com> wrote:
> >> >
> >> > > But if you're working with a different assumption - that just
> the existence of the branch does not stop Dat from still merging his work
> and the work being included in 8.0 - then I agree, waiting for him to merge
> doesn't need to stop the creation of the branch.
> >> >
> >> > Yes that's my reasoning. This issue is a blocker so we won't
> release without it but we can work on the branch in the meantime and let
> other people work on new features that are not targeted to 8.
> >> >
> >> > Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <
> casstarg...@gmail.com> a écrit :
> >> >>
> >> >> OK - I was making an assumption that the timeline for the first
> 8.0 RC would be ASAP after the branch is created.
> >> >>
> >> >> It's a common perception that making a branch freezes adding new
> features to the release, perhaps in an unofficial way (more of a courtesy
> rather than a rule). But if you're working with a different assumption -
> that just the existence of the branch does not stop Dat from still merging
> his work and the work being included in 8.0 - then I agree, waiting for him
> to merge doesn't need to stop the creation of the branch.
> >> >>
> >> >> If, however, once the branch is there people object to Dat
> merging his work because it's "too late", then the branch shouldn't be
> created yet because we want to really try to clear that blocker for 8.0.
> >> >>
> >> >> Cassandra
> >> >>
> >> >> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <
> jim.feren...@gmail.com> wrote:
> >> >>>
> >> >>> Ok thanks for answering.
> >> >>>
> >> >>> > - I think Solr needs a couple more weeks since the work Dat
> is doing isn't quite done yet.
> >> >>>
> >> >>> We can wait a few more weeks to create the branch but I don't
> think that one action (creating the branch) prevents the other (the work
> Dat is doing).
> >> >>> HTTP/2 is one of the blocker for 

Re: Lucene/Solr 8.0

[Adrien Grand]

+1

On Mon, Dec 17, 2018 at 10:38 AM Alan Woodward  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  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  
> 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  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  a 
>> > écrit :
>> >>
>> >> +1 to a 7.6 —lots of stuff in there
>> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  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  
>> >>> 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  
>>  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 
>> >  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 
>> >>  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 

Re: Lucene/Solr 8.0

[Alan Woodward]

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  > 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  > 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  > 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  > > a écrit :
> >>
> >> +1 to a 7.6 —lots of stuff in there
> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  >> > 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  >>> > 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   > 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  > > 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  >> > 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 

Re: Lucene/Solr 8.0

[Cassandra Targett]

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 
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 
> 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  a
> écrit :
> >>
> >> +1 to a 7.6 —lots of stuff in there
> >> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize 
> 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 
> 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 
> wrote:
> >
> > > But if you're working with a different assumption - that just the
> existence of the branch does not stop Dat from still merging his work and
> the work being included in 8.0 - then I agree, waiting for him to merge
> doesn't need to stop the creation of the branch.
> >
> > Yes that's my reasoning. This issue is a blocker so we won't release
> without it but we can work on the branch in the meantime and let other
> people work on new features that are not targeted to 8.
> >
> > Le mer. 17 oct. 2018 à 20:51, Cassandra Targett <
> casstarg...@gmail.com> a écrit :
> >>
> >> OK - I was making an assumption that the timeline for the first 8.0
> RC would be ASAP after the branch is created.
> >>
> >> It's a common perception that making a branch freezes adding new
> features to the release, perhaps in an unofficial way (more of a courtesy
> rather than a rule). But if you're working with a different assumption -
> that just the existence of the branch does not stop Dat from still merging
> his work and the work being included in 8.0 - then I agree, waiting for him
> to merge doesn't need to stop the creation of the branch.
> >>
> >> If, however, once the branch is there people object to Dat merging
> his work because it's "too late", then the branch shouldn't be created yet
> because we want to really try to clear that blocker for 8.0.
> >>
> >> Cassandra
> >>
> >> On Wed, Oct 17, 2018 at 12:13 PM jim ferenczi <
> jim.feren...@gmail.com> wrote:
> >>>
> >>> Ok thanks for answering.
> >>>
> >>> > - I think Solr needs a couple more weeks since the work Dat is
> doing isn't quite done yet.
> >>>
> >>> We can wait a few more weeks to create the branch but I don't
> think that one action (creating the branch) prevents the other (the work
> Dat is doing).
> >>> HTTP/2 is one of the blocker for the release but it can be done in
> master and backported to the appropriate branch as any other feature ? We
> just need an issue with the blocker label to ensure that
> >>> we don't miss it ;). Creating the branch early would also help in
> case you don't want to release all the work at once in 8.0.0.
> >>> Next week was just a proposal, what I meant was soon because we
> target a release in a few months.
> >>>
> >>>
> >>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett <
> casstarg...@gmail.com> a écrit :
> 
>  IMO next week is a bit too soon for the branch - I think Solr
> needs a couple more weeks since the work Dat is doing isn't quite done yet.
> 
>  Solr needs the HTTP/2 work Dat has been doing, and he told me
> yesterday he feels it is nearly ready to be merged into master. However, it
> does require a new release of Jetty to Solr is able to retain Kerberos
> authentication support (Dat has been working with that team to help test
> the changes Jetty needs to support Kerberos with HTTP/2). They should get
> that release out soon, but we are dependent on them a little bit.
> 
>  He can hopefully reply with 

Re: Lucene/Solr 8.0

[Erick Erickson]

+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  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  a écrit 
> :
>>
>> +1 to a 7.6 —lots of stuff in there
>> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  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  
>>> 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  
 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  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  
>> 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  
>>> 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 

Re: Lucene/Solr 8.0

[jim ferenczi]

+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  a
écrit :

> +1 to a 7.6 —lots of stuff in there
> On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  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 
>> 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 
>>> 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 
 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 
> wrote:
>
>> Ok thanks for answering.
>>
>> > - I think Solr needs a couple more weeks since the work Dat is
>> doing isn't quite done yet.
>>
>> We can wait a few more weeks to create the branch but I don't think
>> that one action (creating the branch) prevents the other (the work Dat is
>> doing).
>> HTTP/2 is one of the blocker for the release but it can be done in
>> master and backported to the appropriate branch as any other feature ? We
>> just need an issue with the blocker label to ensure that
>> we don't miss it ;). Creating the branch early would also help in
>> case you don't want to release all the work at once in 8.0.0.
>> Next week was just a proposal, what I meant was soon because we
>> target a release in a few months.
>>
>>
>> Le mer. 17 oct. 2018 à 17:52, Cassandra Targett <
>> casstarg...@gmail.com> a écrit :
>>
>>> IMO next week is a bit too soon for the branch - I think Solr needs
>>> a couple more weeks since the work Dat is doing isn't quite done yet.
>>>
>>> Solr needs the HTTP/2 work Dat has been doing, and he told me
>>> yesterday he feels it is nearly ready to be merged into master. 
>>> However, it
>>> does require a new release of Jetty to Solr is able to retain Kerberos
>>> authentication support (Dat has been working with that team to help test
>>> the changes Jetty needs to support Kerberos with HTTP/2). They should 
>>> get
>>> that release out soon, but we are dependent on them a little bit.
>>>
>>> He can hopefully reply with more details on his status and what else
>>> needs to be done.
>>>
>>> Once Dat merges his work, IMO we should leave it in master for a
>>> little bit. 

Re: Lucene/Solr 8.0

[David Smiley]

+1 to a 7.6 —lots of stuff in there
On Thu, Oct 18, 2018 at 4:47 PM Nicholas Knize  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 
> 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 
>> 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 
>>> 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 
 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 
> 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 

Re: Lucene/Solr 8.0

[Nicholas Knize]

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

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh]

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

Re: Lucene/Solr 8.0

[jim ferenczi]

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

Re: Lucene/Solr 8.0

[Cassandra Targett]

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

Re: Lucene/Solr 8.0

[jim ferenczi]

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

Re: Lucene/Solr 8.0

[Cassandra Targett]

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 
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 
> 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 
> 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  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  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 
> a écrit :
> >
> > Ok thanks Đạt and Erick. I'll follow the blockers on Jira.  Đạt do
> you have an issue opened for the HTTP/2 support ?
> >
> > Le ven. 31 août 2018 à 16:40, Erick Erickson <
> erickerick...@gmail.com> a écrit :
> >>
> >> There's also the issue of what to do as far as removing Trie*
> support.
> >> I think there's a blocker JIRA.
> >>
> >> project = SOLR AND priority = Blocker AND resolution = Unresolved
> >>
> >> Shows 6 blockers
> >> On Fri, Aug 31, 2018 at 

Re: Lucene/Solr 8.0

[Erick Erickson]

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

Re: Lucene/Solr 8.0

[David Smiley]

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

Re: Lucene/Solr 8.0

[jim ferenczi]

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

Re: Lucene/Solr 8.0

[Adrien Grand]

Đạ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  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  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  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 
>>> 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 
>>> 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 
>>> 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 
>>> 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  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 
>>> 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 
>>> 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  a
>>> écrit :
>>> > >>>
>>> > >>> How can the end user actually use the biggest new feature:
>>> impacts and
>>> > >>> BMW? As far as I can tell, the issue to actually implement the
>>> > >>> necessary API changes (IndexSearcher/TopDocs/etc) is still
>>> open and
>>> > >>> unresolved, although there are some interesting ideas on it.
>>> This
>>> > >>> seems like a really big missing piece, without a proper API,
>>> the stuff
>>> > >>> is not really usable. I also can't imagine a situation where
>>> the API
>>> > >>> could be introduced in a followup minor release because it
>>> would be
>>> > >>> too invasive.
>>> > >>>
>>> > >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand <
>>> jpou...@gmail.com> wrote:
>>> > >>> > Hi all,
>>> > >>> >
>>> > >>> > I would like to start discussing releasing Lucene/Solr 8.0.
>>> Lucene 8
>>> > >>> > already

Re: Lucene/Solr 8.0

[Adrien Grand]

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  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  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 
>> 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 
>> 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 
>> 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 
>> 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  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 
>> 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  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  a
>> écrit :
>> > >>>
>> > >>> How can the end user actually use the biggest new feature:
>> impacts and
>> > >>> BMW? As far as I can tell, the issue to actually implement the
>> > >>> necessary API changes (IndexSearcher/TopDocs/etc) is still open
>> and
>> > >>> unresolved, although there are some interesting ideas on it.
>> This
>> > >>> seems like a really big missing piece, without a proper API,
>> the stuff
>> > >>> is not really usable. I also can't imagine a situation where
>> the API
>> > >>> could be introduced in a followup minor release because it
>> would be
>> > >>> too invasive.
>> > >>>
>> > >>> On Mon, Jun 18, 2018 at 1:19 PM, Adrien Grand <
>> jpou...@gmail.com> wrote:
>> > >>> > Hi all,
>> > >>> >
>> > >>> > I would like to start discussing releasing Lucene/Solr 8.0.
>> Lucene 8
>> > >>> > already
>> > >>> > has some good changes around scoring, notably cleanups to
>> > >>> > similarities[1][2][3], indexing of impacts[4], and an
>> implementation of
>> > >>> > Block-Max WAND[5] which, once combined, allow to run queries
>> faster
>> > >>> > when
>> > >>> > total hit counts are not requested.

Re: Lucene/Solr 8.0

[jim ferenczi]

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

Re: Lucene/Solr 8.0

[Erick Erickson]

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

Re: Lucene/Solr 8.0

[Đạt Cao Mạnh]

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

Re: Lucene/Solr 8.0

[jim ferenczi]

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

Re: Lucene/Solr 8.0

[David Smiley]

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  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  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  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  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  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 
>> wrote:
>> >>> > Hi all,
>> >>> >
>> >>> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8
>> >>> > already
>> >>> > has some good changes around scoring, notably cleanups to
>> >>> > similarities[1][2][3], indexing of impacts[4], and an
>> implementation of
>> >>> > Block-Max WAND[5] which, once combined, allow to run queries faster
>> >>> > when
>> >>> > total hit counts are not requested.
>> >>> >
>> >>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
>> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
>> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
>> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
>> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
>> >>> >
>> >>> > In terms of bug fixes, there is also a bad relevancy bug[6] which is
>> >>> > only in
>> >>> > 8.0 because it required a breaking change[7] to be implemented.
>> >>> >
>> >>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
>> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
>> >>> >
>> >>> > As usual, doing a new major release will also help age out old
>> codecs,
>> >>> > which
>> >>> > in-turn make maintenance easier: 8.0 will no longer need to care
>> about
>> >>> > the
>> >>> > fact that some codecs were initially implemented with a
>> random-access
>> >>> > API
>> >>> > for doc values, that pre-7.0 indices encoded norms differently, or
>> that
>> >>> > pre-6.2 indices could not record an index sort.
>> >>> >
>> >>> > I also expect that we will come up with ideas of things to do for
>> 8.0
>> >>> > as we
>> >>> > feel that the next major is getting closer. In terms of planning, I
>> was
>> >>> > thinking that we could target something like october 2018, which
>> would
>> >>> > be
>> >>> > 12-13 months after 7.0 and 3-4 months from now.
>> >>> >
>> >>> > From a Solr perspective, the main change I'm aware of that would be
>> >>> > worth
>> >>> > releasing a new major is the Star Burst effort. Is it something we
>> want
>> >>> > to
>> >>> > get in for 8.0?
>> >>> >
>> >>> > Adrien
>> >>>
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>>
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, 

Re: Lucene/Solr 8.0

[Adrien Grand]

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  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  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  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  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 
> wrote:
> >>> > Hi all,
> >>> >
> >>> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8
> >>> > already
> >>> > has some good changes around scoring, notably cleanups to
> >>> > similarities[1][2][3], indexing of impacts[4], and an implementation
> of
> >>> > Block-Max WAND[5] which, once combined, allow to run queries faster
> >>> > when
> >>> > total hit counts are not requested.
> >>> >
> >>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
> >>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
> >>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
> >>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
> >>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
> >>> >
> >>> > In terms of bug fixes, there is also a bad relevancy bug[6] which is
> >>> > only in
> >>> > 8.0 because it required a breaking change[7] to be implemented.
> >>> >
> >>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
> >>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
> >>> >
> >>> > As usual, doing a new major release will also help age out old
> codecs,
> >>> > which
> >>> > in-turn make maintenance easier: 8.0 will no longer need to care
> about
> >>> > the
> >>> > fact that some codecs were initially implemented with a random-access
> >>> > API
> >>> > for doc values, that pre-7.0 indices encoded norms differently, or
> that
> >>> > pre-6.2 indices could not record an index sort.
> >>> >
> >>> > I also expect that we will come up with ideas of things to do for 8.0
> >>> > as we
> >>> > feel that the next major is getting closer. In terms of planning, I
> was
> >>> > thinking that we could target something like october 2018, which
> would
> >>> > be
> >>> > 12-13 months after 7.0 and 3-4 months from now.
> >>> >
> >>> > From a Solr perspective, the main change I'm aware of that would be
> >>> > worth
> >>> > releasing a new major is the Star Burst effort. Is it something we
> want
> >>> > to
> >>> > get in for 8.0?
> >>> >
> >>> > Adrien
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Robert Muir]

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  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  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  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  wrote:
>>> > Hi all,
>>> >
>>> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8
>>> > already
>>> > has some good changes around scoring, notably cleanups to
>>> > similarities[1][2][3], indexing of impacts[4], and an implementation of
>>> > Block-Max WAND[5] which, once combined, allow to run queries faster
>>> > when
>>> > total hit counts are not requested.
>>> >
>>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
>>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
>>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
>>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
>>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
>>> >
>>> > In terms of bug fixes, there is also a bad relevancy bug[6] which is
>>> > only in
>>> > 8.0 because it required a breaking change[7] to be implemented.
>>> >
>>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
>>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
>>> >
>>> > As usual, doing a new major release will also help age out old codecs,
>>> > which
>>> > in-turn make maintenance easier: 8.0 will no longer need to care about
>>> > the
>>> > fact that some codecs were initially implemented with a random-access
>>> > API
>>> > for doc values, that pre-7.0 indices encoded norms differently, or that
>>> > pre-6.2 indices could not record an index sort.
>>> >
>>> > I also expect that we will come up with ideas of things to do for 8.0
>>> > as we
>>> > feel that the next major is getting closer. In terms of planning, I was
>>> > thinking that we could target something like october 2018, which would
>>> > be
>>> > 12-13 months after 7.0 and 3-4 months from now.
>>> >
>>> > From a Solr perspective, the main change I'm aware of that would be
>>> > worth
>>> > releasing a new major is the Star Burst effort. Is it something we want
>>> > to
>>> > get in for 8.0?
>>> >
>>> > Adrien
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>

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

Re: Lucene/Solr 8.0

[Adrien Grand]

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  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  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  wrote:
>> > Hi all,
>> >
>> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8
>> already
>> > has some good changes around scoring, notably cleanups to
>> > similarities[1][2][3], indexing of impacts[4], and an implementation of
>> > Block-Max WAND[5] which, once combined, allow to run queries faster when
>> > total hit counts are not requested.
>> >
>> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
>> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
>> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
>> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
>> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
>> >
>> > In terms of bug fixes, there is also a bad relevancy bug[6] which is
>> only in
>> > 8.0 because it required a breaking change[7] to be implemented.
>> >
>> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
>> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
>> >
>> > As usual, doing a new major release will also help age out old codecs,
>> which
>> > in-turn make maintenance easier: 8.0 will no longer need to care about
>> the
>> > fact that some codecs were initially implemented with a random-access
>> API
>> > for doc values, that pre-7.0 indices encoded norms differently, or that
>> > pre-6.2 indices could not record an index sort.
>> >
>> > I also expect that we will come up with ideas of things to do for 8.0
>> as we
>> > feel that the next major is getting closer. In terms of planning, I was
>> > thinking that we could target something like october 2018, which would
>> be
>> > 12-13 months after 7.0 and 3-4 months from now.
>> >
>> > From a Solr perspective, the main change I'm aware of that would be
>> worth
>> > releasing a new major is the Star Burst effort. Is it something we want
>> to
>> > get in for 8.0?
>> >
>> > Adrien
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Lucene/Solr 8.0

[Adrien Grand]

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  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  wrote:
> > Hi all,
> >
> > I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8
> already
> > has some good changes around scoring, notably cleanups to
> > similarities[1][2][3], indexing of impacts[4], and an implementation of
> > Block-Max WAND[5] which, once combined, allow to run queries faster when
> > total hit counts are not requested.
> >
> > [1] https://issues.apache.org/jira/browse/LUCENE-8116
> > [2] https://issues.apache.org/jira/browse/LUCENE-8020
> > [3] https://issues.apache.org/jira/browse/LUCENE-8007
> > [4] https://issues.apache.org/jira/browse/LUCENE-4198
> > [5] https://issues.apache.org/jira/browse/LUCENE-8135
> >
> > In terms of bug fixes, there is also a bad relevancy bug[6] which is
> only in
> > 8.0 because it required a breaking change[7] to be implemented.
> >
> > [6] https://issues.apache.org/jira/browse/LUCENE-8031
> > [7] https://issues.apache.org/jira/browse/LUCENE-8134
> >
> > As usual, doing a new major release will also help age out old codecs,
> which
> > in-turn make maintenance easier: 8.0 will no longer need to care about
> the
> > fact that some codecs were initially implemented with a random-access API
> > for doc values, that pre-7.0 indices encoded norms differently, or that
> > pre-6.2 indices could not record an index sort.
> >
> > I also expect that we will come up with ideas of things to do for 8.0 as
> we
> > feel that the next major is getting closer. In terms of planning, I was
> > thinking that we could target something like october 2018, which would be
> > 12-13 months after 7.0 and 3-4 months from now.
> >
> > From a Solr perspective, the main change I'm aware of that would be worth
> > releasing a new major is the Star Burst effort. Is it something we want
> to
> > get in for 8.0?
> >
> > Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Lucene/Solr 8.0

[Robert Muir]

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  wrote:
> Hi all,
>
> I would like to start discussing releasing Lucene/Solr 8.0. Lucene 8 already
> has some good changes around scoring, notably cleanups to
> similarities[1][2][3], indexing of impacts[4], and an implementation of
> Block-Max WAND[5] which, once combined, allow to run queries faster when
> total hit counts are not requested.
>
> [1] https://issues.apache.org/jira/browse/LUCENE-8116
> [2] https://issues.apache.org/jira/browse/LUCENE-8020
> [3] https://issues.apache.org/jira/browse/LUCENE-8007
> [4] https://issues.apache.org/jira/browse/LUCENE-4198
> [5] https://issues.apache.org/jira/browse/LUCENE-8135
>
> In terms of bug fixes, there is also a bad relevancy bug[6] which is only in
> 8.0 because it required a breaking change[7] to be implemented.
>
> [6] https://issues.apache.org/jira/browse/LUCENE-8031
> [7] https://issues.apache.org/jira/browse/LUCENE-8134
>
> As usual, doing a new major release will also help age out old codecs, which
> in-turn make maintenance easier: 8.0 will no longer need to care about the
> fact that some codecs were initially implemented with a random-access API
> for doc values, that pre-7.0 indices encoded norms differently, or that
> pre-6.2 indices could not record an index sort.
>
> I also expect that we will come up with ideas of things to do for 8.0 as we
> feel that the next major is getting closer. In terms of planning, I was
> thinking that we could target something like october 2018, which would be
> 12-13 months after 7.0 and 3-4 months from now.
>
> From a Solr perspective, the main change I'm aware of that would be worth
> releasing a new major is the Star Burst effort. Is it something we want to
> get in for 8.0?
>
> Adrien

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