Re: Release Lucene/Solr 8.9.0 should we have it soon

[戴晓彬]

I think jetty 9.4.40.v20210413 wouldbe better，because I found 
https://github.com/eclipse/jetty.project/issues/6121 may result a search 
response error.


-- Original --
From: Cassandra Targett https://issues.apache.org/jira/browse/SOLR-15316
 
 Sorry, I’m way behind on mailing lists and didn’t see the branch had been cut 
already!
 
 
 Cassandra
 
 On Jun 1, 2021, 3:54 PM -0500, Jan Høydahl https://github.com/apache/solr/pull/96
 
  wunder
 Walter Underwood
 wun...@wunderwood.org
 http://observer.wunderwood.org/;(myblog)
 
 
  On Jun 1, 2021, at 12:27 PM, Walter Underwood http://observer.wunderwood.org/;(myblog)
 
 
  On Jun 1, 2021, at 12:20 PM, Atri Sharma https://github.com/apache/solr/pull/96/files
 https://issues.apache.org/jira/browse/SOLR-15056
 
  wunder
 Walter Underwood
 wun...@wunderwood.org
 http://observer.wunderwood.org/;(myblog)
 
 
  On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
http://www.linkedin.com/in/davidwsmiley
 
 
 
 

 
 
  On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
https://issues.apache.org/jira/browse/SOLR-15378 should 
be investigated before 8.9, maybe make it a blocker?
 
  On Thu, May 13, 2021 at 1:35 AM Robert Muir https://github.com/apache/lucene-solr/pull/2495
 
  Personally, I felt that merging non-trivial changes from main 
branch
  to 8.x has some additional risks when cherry-picking:
  * structural changes in main branch making merging more 
difficult
  (e.g. LUCENE-9705 reorganization of codec versioning, great 
change
  moving forwards though)
  * there are many style changes due to spotless in main branch 
which
  add noise to merging against old code.
  * In the specific case of LUCENE-9827, the usual additional 
tricky
  backwards compatibility for 8.x must be added in the backport 
(due to
  minor version bumps there) which can go wrong.
 
  I still think that particular change is worth considering for 
8.9, it
  isn't just a performance bug but also a huge improvement to 
test
  coverage that helps combat risks.
 
  But we should still take some precautions when releasing an 
8.x IMO:
  * be mindful of what we are backporting and the risks 
involved: it is harder.
  * try to let jenkins bake changes in 8.x branches for longer 
than
  usual? even a few days really helps.
 
  On Tue, May 11, 2021 at 1:29 PM Mayya Sharipova
  https://issues.apache.org/jira/browse/SOLR-14597 into some sort of 8x. I've 
recently completed the back port of 2/3 of the lucene tickets that are related, 
and hope to work on the third tomorrow
  
   I had some feedback there, but I think folks were 
waiting for the version integrated with the final form of the Lucene tickets 
before delving further. Hopefully this week I can start on a patch that does 
that.
  
   On Tue, May 11, 2021 at 10:25 AM Adrien Grand 
http://www.needhamsoftware.com (work)
   http://www.the111shift.com (play)
 
  
-
  To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
  For additional commands, e-mail: dev-h...@lucene.apache.org
 
 
 
  --
  http://www.needhamsoftware.com (work)
  http://www.the111shift.com (play)
 
 
 
 --
 -
 Noble Paul
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Welcome Greg Miller as Lucene committer

[Greg Miller]

Thank you everyone!

Cheers,
-Greg

On Tue, Jun 1, 2021 at 11:13 AM Steve Rowe  wrote:
>
> Congrats and welcome, Greg!
>
> --
> Steve
>
> > On May 29, 2021, at 3:47 PM, Adrien Grand  wrote:
> >
> > I'm pleased to announce that Greg Miller has accepted the PMC's invitation 
> > to become a committer.
> >
> > Greg, the tradition is that new committers introduce themselves with a 
> > brief bio.
> >
> > Congratulations and welcome!
> >
> > --
> > 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: Release Lucene/Solr 8.9.0 should we have it soon

[Jan Høydahl]

Cassandra,

Thanks for spotting the Jetty JIRA (SOLR-15316 
). I put up a quck PR 
 for upgrading Jetty to 
9.4.41.v20210516. Currently running all tests.
Due to the CVEs I think there should not be a new Solr release without this 
upgrade. I set fixVersion to 8.9 and kept the blocker. If anyone disagrees, 
speak out.

There's always a risk of a new Jetty version introducing new bugs, but this is 
a minor version upgrade with (almost) exclusively bug fixes since 9.4.36, so 
I'm willing to take the risk if tests look good. Perhaps Jenkins gets a few 
test spins on main before the 8.9 release too. Whyt Mayya?

Jan

> 1. jun. 2021 kl. 23:04 skrev Cassandra Targett :
> 
> I got a question this morning about some Jetty CVEs that look to be fixed 
> with Jetty 9.4.39, and there’s an issue marked as a Blocker (with no version) 
> to upgrade to that version. Is there time to do that for 8.9? Or is it too 
> high risk or would take too long? 
> https://issues.apache.org/jira/browse/SOLR-15316 
> 
> 
> Sorry, I’m way behind on mailing lists and didn’t see the branch had been cut 
> already!
> 
> Cassandra
> On Jun 1, 2021, 3:54 PM -0500, Jan Høydahl , wrote:
>> Let's not hold up the release due to this incomplete PR. It obviously needs 
>> more time for completion and there is always a new train to catch.
>> As far as I understand, Circuit breakers are pluggable, so anyone can 
>> configure their own implementation in the meantime?
>> 
>> Jan
>> 
>>> 1. jun. 2021 kl. 22:13 skrev Atri Sharma >> >:
>>> 
>>> I appreciate you fixing this and adding the new circuit breaker and look 
>>> forward to having it in the hands of our users soon.
>>> 
>>> However, the current state of PR, with significant API churn for a single 
>>> change and overlapping code is not yet ready.
>>> 
>>> If this is too much of a rework, I am happy to take the existing PR and do 
>>> the changes, post which I believe the PR should be close to completion. 
>>> 
>>> Let me know if you need me to help, but unfortunately, the two objections I 
>>> raised are blockers, atleast until we establish that they cannot be done 
>>> away with. 
>>> 
>>> 
>>> On Wed, 2 Jun 2021, 01:37 Walter Underwood, >> > wrote:
>>> I would appreciate a second opinion on the pull request. Substantive issues 
>>> have been resolved. At this point, the discussion is about code style and 
>>> coding standards. I don’t have detailed knowledge about the Solr coding 
>>> style, so I’d appreciate another set of eyes.
>>> 
>>> The current behavior is buggy, and we are not able to use it at Chegg. The 
>>> patch fixes those bugs.
>>> 
>>> https://github.com/apache/solr/pull/96 
>>> 
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org 
>>> http://observer.wunderwood.org/   (my blog)
>>> 
 On Jun 1, 2021, at 12:27 PM, Walter Underwood >>> > wrote:
 
 I answered the comments. I don’t see those answers on github, oddly.
 
 I’ll re-answer them. Most of your questions are already answered in the 
 discussion on Jira.
 
 I central issues is that load average is not always a CPU measure. In some 
 systems, it includes threads in iowait. So it is potentially misleading to 
 label it as CPU and document it as CPU. The updated documentation makes 
 that clear, so that should have already answered your comment. that is why 
 it is important to rename the existing circuit breaker.
 
 wunder
 Walter Underwood
 wun...@wunderwood.org 
 http://observer.wunderwood.org/   (my 
 blog)
 
> On Jun 1, 2021, at 12:20 PM, Atri Sharma  > wrote:
> 
> I tool a look at the PR and gave comments for SOLR-15056, and the last I 
> checked, my comments were not addressed?
> 
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  > wrote:
> Could someone else please take a look at SOLR-15056? This is a small 
> blast radius change that improves the circuit breakers. It includes unit 
> tests and documentation and has been ready since January.
> 
> https://github.com/apache/solr/pull/96/files 
> 
> https://issues.apache.org/jira/browse/SOLR-15056 
> 
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my 
> blog)
> 
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>> > 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Walter Underwood]

This is really frustrating. We have a feature that never should have been 
committed. The behavior and documentation don’t match and the inputs are 
limited to values that make it unusable. The documentation contains a 
nonfunctional link.

I contribute a patch that implements both the original behavior and the 
documented behavior, with unit tests and detailed documentation.

What else am I supposed to do? This seems like we’ve lost the spirit of Yonik’s 
Law of Patches and perfection has become the enemy of progress.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 1, 2021, at 2:01 PM, David Smiley  wrote:
> 
> +1 to Jan's comment; no need to hold up the release.
> 
> I also think we should be open to more releases in the future for 8.x.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, Jun 1, 2021 at 4:55 PM Jan Høydahl  > wrote:
> Let's not hold up the release due to this incomplete PR. It obviously needs 
> more time for completion and there is always a new train to catch.
> As far as I understand, Circuit breakers are pluggable, so anyone can 
> configure their own implementation in the meantime?
> 
> Jan
> 
>> 1. jun. 2021 kl. 22:13 skrev Atri Sharma > >:
>> 
>> I appreciate you fixing this and adding the new circuit breaker and look 
>> forward to having it in the hands of our users soon.
>> 
>> However, the current state of PR, with significant API churn for a single 
>> change and overlapping code is not yet ready.
>> 
>> If this is too much of a rework, I am happy to take the existing PR and do 
>> the changes, post which I believe the PR should be close to completion. 
>> 
>> Let me know if you need me to help, but unfortunately, the two objections I 
>> raised are blockers, atleast until we establish that they cannot be done 
>> away with. 
>> 
>> 
>> On Wed, 2 Jun 2021, 01:37 Walter Underwood, > > wrote:
>> I would appreciate a second opinion on the pull request. Substantive issues 
>> have been resolved. At this point, the discussion is about code style and 
>> coding standards. I don’t have detailed knowledge about the Solr coding 
>> style, so I’d appreciate another set of eyes.
>> 
>> The current behavior is buggy, and we are not able to use it at Chegg. The 
>> patch fixes those bugs.
>> 
>> https://github.com/apache/solr/pull/96 
>> 
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org 
>> http://observer.wunderwood.org/   (my blog)
>> 
>>> On Jun 1, 2021, at 12:27 PM, Walter Underwood >> > wrote:
>>> 
>>> I answered the comments. I don’t see those answers on github, oddly.
>>> 
>>> I’ll re-answer them. Most of your questions are already answered in the 
>>> discussion on Jira.
>>> 
>>> I central issues is that load average is not always a CPU measure. In some 
>>> systems, it includes threads in iowait. So it is potentially misleading to 
>>> label it as CPU and document it as CPU. The updated documentation makes 
>>> that clear, so that should have already answered your comment. that is why 
>>> it is important to rename the existing circuit breaker.
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org 
>>> http://observer.wunderwood.org/   (my blog)
>>> 
 On Jun 1, 2021, at 12:20 PM, Atri Sharma >>> > wrote:
 
 I tool a look at the PR and gave comments for SOLR-15056, and the last I 
 checked, my comments were not addressed?
 
 On Wed, 2 Jun 2021, 00:31 Walter Underwood, >>> > wrote:
 Could someone else please take a look at SOLR-15056? This is a small blast 
 radius change that improves the circuit breakers. It includes unit tests 
 and documentation and has been ready since January.
 
 https://github.com/apache/solr/pull/96/files 
 
 https://issues.apache.org/jira/browse/SOLR-15056 
 
 
 wunder
 Walter Underwood
 wun...@wunderwood.org 
 http://observer.wunderwood.org/   (my 
 blog)
 
> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>  > wrote:
> 
> Thank you for the update, Houston.
> 
> I've started the release process, the branch 8.9 is now cut.
> 
> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman  > wrote:
> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
> 
> - Houston
> 
> On Thu, May 27, 2021 at 11:42 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Cassandra Targett]

I got a question this morning about some Jetty CVEs that look to be fixed with 
Jetty 9.4.39, and there’s an issue marked as a Blocker (with no version) to 
upgrade to that version. Is there time to do that for 8.9? Or is it too high 
risk or would take too long? https://issues.apache.org/jira/browse/SOLR-15316

Sorry, I’m way behind on mailing lists and didn’t see the branch had been cut 
already!

Cassandra
On Jun 1, 2021, 3:54 PM -0500, Jan Høydahl , wrote:
> Let's not hold up the release due to this incomplete PR. It obviously needs 
> more time for completion and there is always a new train to catch.
> As far as I understand, Circuit breakers are pluggable, so anyone can 
> configure their own implementation in the meantime?
>
> Jan
>
> > 1. jun. 2021 kl. 22:13 skrev Atri Sharma :
> >
> > I appreciate you fixing this and adding the new circuit breaker and look 
> > forward to having it in the hands of our users soon.
> >
> > However, the current state of PR, with significant API churn for a single 
> > change and overlapping code is not yet ready.
> >
> > If this is too much of a rework, I am happy to take the existing PR and do 
> > the changes, post which I believe the PR should be close to completion.
> >
> > Let me know if you need me to help, but unfortunately, the two objections I 
> > raised are blockers, atleast until we establish that they cannot be done 
> > away with.
> >
> >
> > > On Wed, 2 Jun 2021, 01:37 Walter Underwood,  wrote:
> > > > I would appreciate a second opinion on the pull request. Substantive 
> > > > issues have been resolved. At this point, the discussion is about code 
> > > > style and coding standards. I don’t have detailed knowledge about the 
> > > > Solr coding style, so I’d appreciate another set of eyes.
> > > >
> > > > The current behavior is buggy, and we are not able to use it at Chegg. 
> > > > The patch fixes those bugs.
> > > >
> > > > https://github.com/apache/solr/pull/96
> > > >
> > > > wunder
> > > > Walter Underwood
> > > > wun...@wunderwood.org
> > > > http://observer.wunderwood.org/  (my blog)
> > > >
> > > > > On Jun 1, 2021, at 12:27 PM, Walter Underwood  
> > > > > wrote:
> > > > >
> > > > > I answered the comments. I don’t see those answers on github, oddly.
> > > > >
> > > > > I’ll re-answer them. Most of your questions are already answered in 
> > > > > the discussion on Jira.
> > > > >
> > > > > I central issues is that load average is not always a CPU measure. In 
> > > > > some systems, it includes threads in iowait. So it is potentially 
> > > > > misleading to label it as CPU and document it as CPU. The updated 
> > > > > documentation makes that clear, so that should have already answered 
> > > > > your comment. that is why it is important to rename the existing 
> > > > > circuit breaker.
> > > > >
> > > > > wunder
> > > > > Walter Underwood
> > > > > wun...@wunderwood.org
> > > > > http://observer.wunderwood.org/  (my blog)
> > > > >
> > > > > > On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
> > > > > >
> > > > > > I tool a look at the PR and gave comments for SOLR-15056, and the 
> > > > > > last I checked, my comments were not addressed?
> > > > > >
> > > > > > > On Wed, 2 Jun 2021, 00:31 Walter Underwood, 
> > > > > > >  wrote:
> > > > > > > > Could someone else please take a look at SOLR-15056? This is a 
> > > > > > > > small blast radius change that improves the circuit breakers. 
> > > > > > > > It includes unit tests and documentation and has been ready 
> > > > > > > > since January.
> > > > > > > >
> > > > > > > > https://github.com/apache/solr/pull/96/files
> > > > > > > > https://issues.apache.org/jira/browse/SOLR-15056
> > > > > > > >
> > > > > > > > wunder
> > > > > > > > Walter Underwood
> > > > > > > > wun...@wunderwood.org
> > > > > > > > http://observer.wunderwood.org/  (my blog)
> > > > > > > >
> > > > > > > > > On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
> > > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Thank you for the update, Houston.
> > > > > > > > >
> > > > > > > > > I've started the release process, the branch 8.9 is now cut.
> > > > > > > > >
> > > > > > > > > > On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
> > > > > > > > > >  wrote:
> > > > > > > > > > > Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
> > > > > > > > > > >
> > > > > > > > > > > - Houston
> > > > > > > > > > >
> > > > > > > > > > > > On Thu, May 27, 2021 at 11:42 PM David Smiley 
> > > > > > > > > > > >  wrote:
> > > > > > > > > > > > > SOLR-15412 is rather serious as the title suggests.  
> > > > > > > > > > > > > I haven't been tracking the progress so if it's 
> > > > > > > > > > > > > already resolved, that's unknown to me and isn't 
> > > > > > > > > > > > > reflected in JIRA.
> > > > > > > > > > > > >
> > > > > > > > > > > > > ~ David Smiley
> > > > > > > > > > > > > Apache Lucene/Solr Search Developer
> > > > > > > > > > > > > http://www.linkedin.com/in/davidwsmiley
> > > > > > > > > > > > >
> > > > > > > > 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[David Smiley]

+1 to Jan's comment; no need to hold up the release.

I also think we should be open to more releases in the future for 8.x.

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


On Tue, Jun 1, 2021 at 4:55 PM Jan Høydahl  wrote:

> Let's not hold up the release due to this incomplete PR. It obviously
> needs more time for completion and there is always a new train to catch.
> As far as I understand, Circuit breakers are pluggable, so anyone can
> configure their own implementation in the meantime?
>
> Jan
>
> 1. jun. 2021 kl. 22:13 skrev Atri Sharma :
>
> I appreciate you fixing this and adding the new circuit breaker and look
> forward to having it in the hands of our users soon.
>
> However, the current state of PR, with significant API churn for a single
> change and overlapping code is not yet ready.
>
> If this is too much of a rework, I am happy to take the existing PR and do
> the changes, post which I believe the PR should be close to completion.
>
> Let me know if you need me to help, but unfortunately, the two objections
> I raised are blockers, atleast until we establish that they cannot be done
> away with.
>
>
> On Wed, 2 Jun 2021, 01:37 Walter Underwood,  wrote:
>
>> I would appreciate a second opinion on the pull request. Substantive
>> issues have been resolved. At this point, the discussion is about code
>> style and coding standards. I don’t have detailed knowledge about the Solr
>> coding style, so I’d appreciate another set of eyes.
>>
>> The current behavior is buggy, and we are not able to use it at Chegg.
>> The patch fixes those bugs.
>>
>> https://github.com/apache/solr/pull/96
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 12:27 PM, Walter Underwood 
>> wrote:
>>
>> I answered the comments. I don’t see those answers on github, oddly.
>>
>> I’ll re-answer them. Most of your questions are already answered in the
>> discussion on Jira.
>>
>> I central issues is that load average is not always a CPU measure. In
>> some systems, it includes threads in iowait. So it is potentially
>> misleading to label it as CPU and document it as CPU. The updated
>> documentation makes that clear, so that should have already answered your
>> comment. that is why it is important to rename the existing circuit breaker.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
>>
>> I tool a look at the PR and gave comments for SOLR-15056, and the last I
>> checked, my comments were not addressed?
>>
>> On Wed, 2 Jun 2021, 00:31 Walter Underwood, 
>> wrote:
>>
>>> Could someone else please take a look at SOLR-15056? This is a small
>>> blast radius change that improves the circuit breakers. It includes unit
>>> tests and documentation and has been ready since January.
>>>
>>> https://github.com/apache/solr/pull/96/files
>>> https://issues.apache.org/jira/browse/SOLR-15056
>>>
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>>
>>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
>>> mayya.sharip...@elastic.co.INVALID> wrote:
>>>
>>> Thank you for the update, Houston.
>>>
>>> I've started the release process, the branch 8.9 is now cut.
>>>
>>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
>>> wrote:
>>>
 Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.

 - Houston

 On Thu, May 27, 2021 at 11:42 PM David Smiley 
 wrote:

> SOLR-15412 is rather serious as the title suggests.  I haven't been
> tracking the progress so if it's already resolved, that's unknown to me 
> and
> isn't reflected in JIRA.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
> mayya.sharip...@elastic.co.invalid> wrote:
>
>> Hello everyone,
>> I wonder if everyone is ok for May 31st (Monday) as the date for the
>> feature freeze date and branch cut?
>> I've noticed that `releaseWizard.py` is also asking for the length of
>> feature freeze. What is the custom length to put there?
>>
>> Looks like Lucene
>> 
>> doesn't have any unresolved issues for 8.9.
>> SOLR 
>>  has:
>> -  SOLR-15412  Strict validation on Replica metadata can cause
>> complete outage  (Looks like it may be resolved already?)
>> - SOLR-15410 GC log is directed to console when starting Solr with
>> Java 11 Open J9 on Windows
>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
>> Unix load average
>>
>> Are we ok to postpone these issues to later releases if they are not
>> 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Jan Høydahl]

Let's not hold up the release due to this incomplete PR. It obviously needs 
more time for completion and there is always a new train to catch.
As far as I understand, Circuit breakers are pluggable, so anyone can configure 
their own implementation in the meantime?

Jan

> 1. jun. 2021 kl. 22:13 skrev Atri Sharma :
> 
> I appreciate you fixing this and adding the new circuit breaker and look 
> forward to having it in the hands of our users soon.
> 
> However, the current state of PR, with significant API churn for a single 
> change and overlapping code is not yet ready.
> 
> If this is too much of a rework, I am happy to take the existing PR and do 
> the changes, post which I believe the PR should be close to completion. 
> 
> Let me know if you need me to help, but unfortunately, the two objections I 
> raised are blockers, atleast until we establish that they cannot be done away 
> with. 
> 
> 
> On Wed, 2 Jun 2021, 01:37 Walter Underwood,  > wrote:
> I would appreciate a second opinion on the pull request. Substantive issues 
> have been resolved. At this point, the discussion is about code style and 
> coding standards. I don’t have detailed knowledge about the Solr coding 
> style, so I’d appreciate another set of eyes.
> 
> The current behavior is buggy, and we are not able to use it at Chegg. The 
> patch fixes those bugs.
> 
> https://github.com/apache/solr/pull/96 
> 
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my blog)
> 
>> On Jun 1, 2021, at 12:27 PM, Walter Underwood > > wrote:
>> 
>> I answered the comments. I don’t see those answers on github, oddly.
>> 
>> I’ll re-answer them. Most of your questions are already answered in the 
>> discussion on Jira.
>> 
>> I central issues is that load average is not always a CPU measure. In some 
>> systems, it includes threads in iowait. So it is potentially misleading to 
>> label it as CPU and document it as CPU. The updated documentation makes that 
>> clear, so that should have already answered your comment. that is why it is 
>> important to rename the existing circuit breaker.
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org 
>> http://observer.wunderwood.org/   (my blog)
>> 
>>> On Jun 1, 2021, at 12:20 PM, Atri Sharma >> > wrote:
>>> 
>>> I tool a look at the PR and gave comments for SOLR-15056, and the last I 
>>> checked, my comments were not addressed?
>>> 
>>> On Wed, 2 Jun 2021, 00:31 Walter Underwood, >> > wrote:
>>> Could someone else please take a look at SOLR-15056? This is a small blast 
>>> radius change that improves the circuit breakers. It includes unit tests 
>>> and documentation and has been ready since January.
>>> 
>>> https://github.com/apache/solr/pull/96/files 
>>> 
>>> https://issues.apache.org/jira/browse/SOLR-15056 
>>> 
>>> 
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org 
>>> http://observer.wunderwood.org/   (my blog)
>>> 
 On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
 >>> > wrote:
 
 Thank you for the update, Houston.
 
 I've started the release process, the branch 8.9 is now cut.
 
 On Tue, Jun 1, 2021 at 11:21 AM Houston Putman >>> > wrote:
 Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
 
 - Houston
 
 On Thu, May 27, 2021 at 11:42 PM David Smiley >>> > wrote:
 SOLR-15412 is rather serious as the title suggests.  I haven't been 
 tracking the progress so if it's already resolved, that's unknown to me 
 and isn't reflected in JIRA.
 
 ~ David Smiley
 Apache Lucene/Solr Search Developer
 http://www.linkedin.com/in/davidwsmiley 
 
 
 On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
 >>> > wrote:
 Hello everyone,
 I wonder if everyone is ok for May 31st (Monday) as the date for the 
 feature freeze date and branch cut?
 I've noticed that `releaseWizard.py` is also asking for the length of 
 feature freeze. What is the custom length to put there?
 
 Looks like Lucene 
  doesn't 
 have any unresolved issues for 8.9.
 SOLR  has:
 -  SOLR-15412  Strict validation on Replica metadata can cause complete 
 outage  (Looks like it may be resolved already?)
 - 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Atri Sharma]

I appreciate you fixing this and adding the new circuit breaker and look
forward to having it in the hands of our users soon.

However, the current state of PR, with significant API churn for a single
change and overlapping code is not yet ready.

If this is too much of a rework, I am happy to take the existing PR and do
the changes, post which I believe the PR should be close to completion.

Let me know if you need me to help, but unfortunately, the two objections I
raised are blockers, atleast until we establish that they cannot be done
away with.


On Wed, 2 Jun 2021, 01:37 Walter Underwood,  wrote:

> I would appreciate a second opinion on the pull request. Substantive
> issues have been resolved. At this point, the discussion is about code
> style and coding standards. I don’t have detailed knowledge about the Solr
> coding style, so I’d appreciate another set of eyes.
>
> The current behavior is buggy, and we are not able to use it at Chegg. The
> patch fixes those bugs.
>
> https://github.com/apache/solr/pull/96
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 12:27 PM, Walter Underwood 
> wrote:
>
> I answered the comments. I don’t see those answers on github, oddly.
>
> I’ll re-answer them. Most of your questions are already answered in the
> discussion on Jira.
>
> I central issues is that load average is not always a CPU measure. In some
> systems, it includes threads in iowait. So it is potentially misleading to
> label it as CPU and document it as CPU. The updated documentation makes
> that clear, so that should have already answered your comment. that is why
> it is important to rename the existing circuit breaker.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
>
> I tool a look at the PR and gave comments for SOLR-15056, and the last I
> checked, my comments were not addressed?
>
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  wrote:
>
>> Could someone else please take a look at SOLR-15056? This is a small
>> blast radius change that improves the circuit breakers. It includes unit
>> tests and documentation and has been ready since January.
>>
>> https://github.com/apache/solr/pull/96/files
>> https://issues.apache.org/jira/browse/SOLR-15056
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
>> mayya.sharip...@elastic.co.INVALID> wrote:
>>
>> Thank you for the update, Houston.
>>
>> I've started the release process, the branch 8.9 is now cut.
>>
>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
>> wrote:
>>
>>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>>
>>> - Houston
>>>
>>> On Thu, May 27, 2021 at 11:42 PM David Smiley 
>>> wrote:
>>>
 SOLR-15412 is rather serious as the title suggests.  I haven't been
 tracking the progress so if it's already resolved, that's unknown to me and
 isn't reflected in JIRA.

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


 On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
 mayya.sharip...@elastic.co.invalid> wrote:

> Hello everyone,
> I wonder if everyone is ok for May 31st (Monday) as the date for the
> feature freeze date and branch cut?
> I've noticed that `releaseWizard.py` is also asking for the length of
> feature freeze. What is the custom length to put there?
>
> Looks like Lucene
> 
> doesn't have any unresolved issues for 8.9.
> SOLR 
>  has:
> -  SOLR-15412  Strict validation on Replica metadata can cause
> complete outage  (Looks like it may be resolved already?)
> - SOLR-15410 GC log is directed to console when starting Solr with
> Java 11 Open J9 on Windows
> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
> Unix load average
>
> Are we ok to postpone these issues to later releases if they are not
> resolved and merged before feature freeze?
>
> Thank you.
>
>
>
>
>
>
> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie <
> colvin.cowie@gmail.com> wrote:
>
>> Hello,
>> Eric was going to have a look at the PR.
>> But if it isn't done in time then I don't think it needs to block the
>> release
>>
>> Thanks
>>
>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova <
>> mayya.sharip...@elastic.co.invalid> wrote:
>>
>>> Hello Colvin,
>>> I am wondering if you still want to merge SOLR-15410 for the
>>> Lucene/Solr 8.9 release?
>>> Should we have a deadline for feature freeze? Say May 30th (Sunday)?
>>>
>>> Thank you.
>>>
>>> On 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Walter Underwood]

I would appreciate a second opinion on the pull request. Substantive issues 
have been resolved. At this point, the discussion is about code style and 
coding standards. I don’t have detailed knowledge about the Solr coding style, 
so I’d appreciate another set of eyes.

The current behavior is buggy, and we are not able to use it at Chegg. The 
patch fixes those bugs.

https://github.com/apache/solr/pull/96

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 1, 2021, at 12:27 PM, Walter Underwood  wrote:
> 
> I answered the comments. I don’t see those answers on github, oddly.
> 
> I’ll re-answer them. Most of your questions are already answered in the 
> discussion on Jira.
> 
> I central issues is that load average is not always a CPU measure. In some 
> systems, it includes threads in iowait. So it is potentially misleading to 
> label it as CPU and document it as CPU. The updated documentation makes that 
> clear, so that should have already answered your comment. that is why it is 
> important to rename the existing circuit breaker.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/  (my blog)
> 
>> On Jun 1, 2021, at 12:20 PM, Atri Sharma > > wrote:
>> 
>> I tool a look at the PR and gave comments for SOLR-15056, and the last I 
>> checked, my comments were not addressed?
>> 
>> On Wed, 2 Jun 2021, 00:31 Walter Underwood, > > wrote:
>> Could someone else please take a look at SOLR-15056? This is a small blast 
>> radius change that improves the circuit breakers. It includes unit tests and 
>> documentation and has been ready since January.
>> 
>> https://github.com/apache/solr/pull/96/files 
>> 
>> https://issues.apache.org/jira/browse/SOLR-15056 
>> 
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org 
>> http://observer.wunderwood.org/   (my blog)
>> 
>>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>>> >> > wrote:
>>> 
>>> Thank you for the update, Houston.
>>> 
>>> I've started the release process, the branch 8.9 is now cut.
>>> 
>>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman >> > wrote:
>>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>> 
>>> - Houston
>>> 
>>> On Thu, May 27, 2021 at 11:42 PM David Smiley >> > wrote:
>>> SOLR-15412 is rather serious as the title suggests.  I haven't been 
>>> tracking the progress so if it's already resolved, that's unknown to me and 
>>> isn't reflected in JIRA.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley 
>>> 
>>> 
>>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
>>> >> > wrote:
>>> Hello everyone,
>>> I wonder if everyone is ok for May 31st (Monday) as the date for the 
>>> feature freeze date and branch cut?
>>> I've noticed that `releaseWizard.py` is also asking for the length of 
>>> feature freeze. What is the custom length to put there?
>>> 
>>> Looks like Lucene 
>>>  doesn't 
>>> have any unresolved issues for 8.9.
>>> SOLR  has:
>>> -  SOLR-15412  Strict validation on Replica metadata can cause complete 
>>> outage  (Looks like it may be resolved already?)
>>> - SOLR-15410 GC log is directed to console when starting Solr with Java 11 
>>> Open J9 on Windows
>>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not Unix 
>>> load average
>>> 
>>> Are we ok to postpone these issues to later releases if they are not 
>>> resolved and merged before feature freeze?
>>> 
>>> Thank you.
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie >> > wrote:
>>> Hello,
>>> Eric was going to have a look at the PR.
>>> But if it isn't done in time then I don't think it needs to block the 
>>> release
>>> 
>>> Thanks
>>> 
>>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova 
>>> >> > wrote:
>>> Hello Colvin,
>>> I am wondering if you still want to merge SOLR-15410 for the Lucene/Solr 
>>> 8.9 release?  
>>> Should we have a deadline for feature freeze? Say May 30th (Sunday)? 
>>> 
>>> Thank you.
>>> 
>>> On Tue, May 18, 2021 at 8:49 AM Noble Paul >> > wrote:
>>> +1
>>> 
>>> 
>>> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie >> > wrote:
>>> >
>>> > Hello,
>>> >
>>> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC logging 
>>> > when using new versions of 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Atri Sharma]

As I mentioned in the PR, my two main objections are:

1. Introduction of SolrCore to CircuitBreakerManager. It causes a
significant API churn and is not needed by any other circuit breaker.

2. Duplication of code -- there is a significant overlap between the code
for the two circuit breakers. Please abstract them to common classes and
define interfaces.

Naming is an auxiliary discussion that is not a blocker to this PR.


On Wed, 2 Jun 2021, 00:58 Walter Underwood,  wrote:

> I answered the comments. I don’t see those answers on github, oddly.
>
> I’ll re-answer them. Most of your questions are already answered in the
> discussion on Jira.
>
> I central issues is that load average is not always a CPU measure. In some
> systems, it includes threads in iowait. So it is potentially misleading to
> label it as CPU and document it as CPU. The updated documentation makes
> that clear, so that should have already answered your comment. that is why
> it is important to rename the existing circuit breaker.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
>
> I tool a look at the PR and gave comments for SOLR-15056, and the last I
> checked, my comments were not addressed?
>
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  wrote:
>
>> Could someone else please take a look at SOLR-15056? This is a small
>> blast radius change that improves the circuit breakers. It includes unit
>> tests and documentation and has been ready since January.
>>
>> https://github.com/apache/solr/pull/96/files
>> https://issues.apache.org/jira/browse/SOLR-15056
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
>> mayya.sharip...@elastic.co.INVALID> wrote:
>>
>> Thank you for the update, Houston.
>>
>> I've started the release process, the branch 8.9 is now cut.
>>
>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
>> wrote:
>>
>>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>>
>>> - Houston
>>>
>>> On Thu, May 27, 2021 at 11:42 PM David Smiley 
>>> wrote:
>>>
 SOLR-15412 is rather serious as the title suggests.  I haven't been
 tracking the progress so if it's already resolved, that's unknown to me and
 isn't reflected in JIRA.

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


 On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
 mayya.sharip...@elastic.co.invalid> wrote:

> Hello everyone,
> I wonder if everyone is ok for May 31st (Monday) as the date for the
> feature freeze date and branch cut?
> I've noticed that `releaseWizard.py` is also asking for the length of
> feature freeze. What is the custom length to put there?
>
> Looks like Lucene
> 
> doesn't have any unresolved issues for 8.9.
> SOLR 
>  has:
> -  SOLR-15412  Strict validation on Replica metadata can cause
> complete outage  (Looks like it may be resolved already?)
> - SOLR-15410 GC log is directed to console when starting Solr with
> Java 11 Open J9 on Windows
> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
> Unix load average
>
> Are we ok to postpone these issues to later releases if they are not
> resolved and merged before feature freeze?
>
> Thank you.
>
>
>
>
>
>
> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie <
> colvin.cowie@gmail.com> wrote:
>
>> Hello,
>> Eric was going to have a look at the PR.
>> But if it isn't done in time then I don't think it needs to block the
>> release
>>
>> Thanks
>>
>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova <
>> mayya.sharip...@elastic.co.invalid> wrote:
>>
>>> Hello Colvin,
>>> I am wondering if you still want to merge SOLR-15410 for the
>>> Lucene/Solr 8.9 release?
>>> Should we have a deadline for feature freeze? Say May 30th (Sunday)?
>>>
>>> Thank you.
>>>
>>> On Tue, May 18, 2021 at 8:49 AM Noble Paul 
>>> wrote:
>>>
 +1


 On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <
 colvin.cowie@gmail.com> wrote:
 >
 > Hello,
 >
 > I raised SOLR-15410 yesterday with a PR to fix an issue with GC
 logging when using new versions of OpenJ9. It's small, so if somebody 
 could
 have a look at it in time for 8.9 that would be great
 >
 > Thanks,
 > Colvin
 >
 > On Thu, 13 May 2021 at 17:52, Nhat Nguyen 
 > 
 wrote:
 >>
 >> Hi Mayya,
 >>
 >> I would like to backport LUCENE-9935, which 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Walter Underwood]

I answered the comments. I don’t see those answers on github, oddly.

I’ll re-answer them. Most of your questions are already answered in the 
discussion on Jira.

I central issues is that load average is not always a CPU measure. In some 
systems, it includes threads in iowait. So it is potentially misleading to 
label it as CPU and document it as CPU. The updated documentation makes that 
clear, so that should have already answered your comment. that is why it is 
important to rename the existing circuit breaker.

wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
> 
> I tool a look at the PR and gave comments for SOLR-15056, and the last I 
> checked, my comments were not addressed?
> 
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  > wrote:
> Could someone else please take a look at SOLR-15056? This is a small blast 
> radius change that improves the circuit breakers. It includes unit tests and 
> documentation and has been ready since January.
> 
> https://github.com/apache/solr/pull/96/files 
> 
> https://issues.apache.org/jira/browse/SOLR-15056 
> 
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org 
> http://observer.wunderwood.org/   (my blog)
> 
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>> > > wrote:
>> 
>> Thank you for the update, Houston.
>> 
>> I've started the release process, the branch 8.9 is now cut.
>> 
>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman > > wrote:
>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>> 
>> - Houston
>> 
>> On Thu, May 27, 2021 at 11:42 PM David Smiley > > wrote:
>> SOLR-15412 is rather serious as the title suggests.  I haven't been tracking 
>> the progress so if it's already resolved, that's unknown to me and isn't 
>> reflected in JIRA.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley 
>> 
>> 
>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
>> > > wrote:
>> Hello everyone,
>> I wonder if everyone is ok for May 31st (Monday) as the date for the feature 
>> freeze date and branch cut?
>> I've noticed that `releaseWizard.py` is also asking for the length of 
>> feature freeze. What is the custom length to put there?
>> 
>> Looks like Lucene 
>>  doesn't 
>> have any unresolved issues for 8.9.
>> SOLR  has:
>> -  SOLR-15412  Strict validation on Replica metadata can cause complete 
>> outage  (Looks like it may be resolved already?)
>> - SOLR-15410 GC log is directed to console when starting Solr with Java 11 
>> Open J9 on Windows
>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not Unix 
>> load average
>> 
>> Are we ok to postpone these issues to later releases if they are not 
>> resolved and merged before feature freeze?
>> 
>> Thank you.
>> 
>> 
>> 
>> 
>> 
>> 
>> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie > > wrote:
>> Hello,
>> Eric was going to have a look at the PR.
>> But if it isn't done in time then I don't think it needs to block the release
>> 
>> Thanks
>> 
>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova 
>> > > wrote:
>> Hello Colvin,
>> I am wondering if you still want to merge SOLR-15410 for the Lucene/Solr 8.9 
>> release?  
>> Should we have a deadline for feature freeze? Say May 30th (Sunday)? 
>> 
>> Thank you.
>> 
>> On Tue, May 18, 2021 at 8:49 AM Noble Paul > > wrote:
>> +1
>> 
>> 
>> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie > > wrote:
>> >
>> > Hello,
>> >
>> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC logging 
>> > when using new versions of OpenJ9. It's small, so if somebody could have a 
>> > look at it in time for 8.9 that would be great
>> >
>> > Thanks,
>> > Colvin
>> >
>> > On Thu, 13 May 2021 at 17:52, Nhat Nguyen > > .invalid> wrote:
>> >>
>> >> Hi Mayya,
>> >>
>> >> I would like to backport LUCENE-9935, which enables bulk-merge for stored 
>> >> fields with index sort, to 8.x this weekend. The patch is ready, but we 
>> >> prefer to give CI some cycles before backporting. Please let me know if 
>> >> it's okay with the release plan.
>> >>
>> >> Thanks,
>> >> Nhat
>> >>
>> >> On Thu, May 13, 2021 at 12:44 PM Gus Heck > >> > wrote:
>> >>>
>> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 
>> >>> 

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Mayya Sharipova]

Sorry, Walter, that I rushed to create a new branch.
Please let me know when your changes are merged to 8.x and 8.9 ( I guess
you need to backport to the new 8.9 branch as well),
and I will continue the release process from there.

On Tue, Jun 1, 2021 at 3:21 PM Atri Sharma  wrote:

> I tool a look at the PR and gave comments for SOLR-15056, and the last I
> checked, my comments were not addressed?
>
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  wrote:
>
>> Could someone else please take a look at SOLR-15056? This is a small
>> blast radius change that improves the circuit breakers. It includes unit
>> tests and documentation and has been ready since January.
>>
>> https://github.com/apache/solr/pull/96/files
>> https://issues.apache.org/jira/browse/SOLR-15056
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
>> mayya.sharip...@elastic.co.INVALID> wrote:
>>
>> Thank you for the update, Houston.
>>
>> I've started the release process, the branch 8.9 is now cut.
>>
>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
>> wrote:
>>
>>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>>
>>> - Houston
>>>
>>> On Thu, May 27, 2021 at 11:42 PM David Smiley 
>>> wrote:
>>>
 SOLR-15412 is rather serious as the title suggests.  I haven't been
 tracking the progress so if it's already resolved, that's unknown to me and
 isn't reflected in JIRA.

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


 On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
 mayya.sharip...@elastic.co.invalid> wrote:

> Hello everyone,
> I wonder if everyone is ok for May 31st (Monday) as the date for the
> feature freeze date and branch cut?
> I've noticed that `releaseWizard.py` is also asking for the length of
> feature freeze. What is the custom length to put there?
>
> Looks like Lucene
> 
> doesn't have any unresolved issues for 8.9.
> SOLR 
>  has:
> -  SOLR-15412  Strict validation on Replica metadata can cause
> complete outage  (Looks like it may be resolved already?)
> - SOLR-15410 GC log is directed to console when starting Solr with
> Java 11 Open J9 on Windows
> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
> Unix load average
>
> Are we ok to postpone these issues to later releases if they are not
> resolved and merged before feature freeze?
>
> Thank you.
>
>
>
>
>
>
> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie <
> colvin.cowie@gmail.com> wrote:
>
>> Hello,
>> Eric was going to have a look at the PR.
>> But if it isn't done in time then I don't think it needs to block the
>> release
>>
>> Thanks
>>
>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova <
>> mayya.sharip...@elastic.co.invalid> wrote:
>>
>>> Hello Colvin,
>>> I am wondering if you still want to merge SOLR-15410 for the
>>> Lucene/Solr 8.9 release?
>>> Should we have a deadline for feature freeze? Say May 30th (Sunday)?
>>>
>>> Thank you.
>>>
>>> On Tue, May 18, 2021 at 8:49 AM Noble Paul 
>>> wrote:
>>>
 +1


 On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <
 colvin.cowie@gmail.com> wrote:
 >
 > Hello,
 >
 > I raised SOLR-15410 yesterday with a PR to fix an issue with GC
 logging when using new versions of OpenJ9. It's small, so if somebody 
 could
 have a look at it in time for 8.9 that would be great
 >
 > Thanks,
 > Colvin
 >
 > On Thu, 13 May 2021 at 17:52, Nhat Nguyen 
 > 
 wrote:
 >>
 >> Hi Mayya,
 >>
 >> I would like to backport LUCENE-9935, which enables bulk-merge
 for stored fields with index sort, to 8.x this weekend. The patch is 
 ready,
 but we prefer to give CI some cycles before backporting. Please let me 
 know
 if it's okay with the release plan.
 >>
 >> Thanks,
 >> Nhat
 >>
 >> On Thu, May 13, 2021 at 12:44 PM Gus Heck 
 wrote:
 >>>
 >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378
 should be investigated before 8.9, maybe make it a blocker?
 >>>
 >>> On Thu, May 13, 2021 at 1:35 AM Robert Muir 
 wrote:
 
  Mayya, I created backport for Adrien's issue here, to try to
 help out:
  https://github.com/apache/lucene-solr/pull/2495
 
  Personally, I felt that merging non-trivial changes from main

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Atri Sharma]

I tool a look at the PR and gave comments for SOLR-15056, and the last I
checked, my comments were not addressed?

On Wed, 2 Jun 2021, 00:31 Walter Underwood,  wrote:

> Could someone else please take a look at SOLR-15056? This is a small blast
> radius change that improves the circuit breakers. It includes unit tests
> and documentation and has been ready since January.
>
> https://github.com/apache/solr/pull/96/files
> https://issues.apache.org/jira/browse/SOLR-15056
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
> mayya.sharip...@elastic.co.INVALID> wrote:
>
> Thank you for the update, Houston.
>
> I've started the release process, the branch 8.9 is now cut.
>
> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman  wrote:
>
>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>
>> - Houston
>>
>> On Thu, May 27, 2021 at 11:42 PM David Smiley  wrote:
>>
>>> SOLR-15412 is rather serious as the title suggests.  I haven't been
>>> tracking the progress so if it's already resolved, that's unknown to me and
>>> isn't reflected in JIRA.
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>>
>>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
>>> mayya.sharip...@elastic.co.invalid> wrote:
>>>
 Hello everyone,
 I wonder if everyone is ok for May 31st (Monday) as the date for the
 feature freeze date and branch cut?
 I've noticed that `releaseWizard.py` is also asking for the length of
 feature freeze. What is the custom length to put there?

 Looks like Lucene
 
 doesn't have any unresolved issues for 8.9.
 SOLR 
  has:
 -  SOLR-15412  Strict validation on Replica metadata can cause complete
 outage  (Looks like it may be resolved already?)
 - SOLR-15410 GC log is directed to console when starting Solr with Java
 11 Open J9 on Windows
 - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
 Unix load average

 Are we ok to postpone these issues to later releases if they are not
 resolved and merged before feature freeze?

 Thank you.






 On Tue, May 25, 2021 at 12:41 PM Colvin Cowie <
 colvin.cowie@gmail.com> wrote:

> Hello,
> Eric was going to have a look at the PR.
> But if it isn't done in time then I don't think it needs to block the
> release
>
> Thanks
>
> On Tue, 25 May 2021 at 15:50, Mayya Sharipova <
> mayya.sharip...@elastic.co.invalid> wrote:
>
>> Hello Colvin,
>> I am wondering if you still want to merge SOLR-15410 for the
>> Lucene/Solr 8.9 release?
>> Should we have a deadline for feature freeze? Say May 30th (Sunday)?
>>
>> Thank you.
>>
>> On Tue, May 18, 2021 at 8:49 AM Noble Paul 
>> wrote:
>>
>>> +1
>>>
>>>
>>> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <
>>> colvin.cowie@gmail.com> wrote:
>>> >
>>> > Hello,
>>> >
>>> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC
>>> logging when using new versions of OpenJ9. It's small, so if somebody 
>>> could
>>> have a look at it in time for 8.9 that would be great
>>> >
>>> > Thanks,
>>> > Colvin
>>> >
>>> > On Thu, 13 May 2021 at 17:52, Nhat Nguyen 
>>> > 
>>> wrote:
>>> >>
>>> >> Hi Mayya,
>>> >>
>>> >> I would like to backport LUCENE-9935, which enables bulk-merge
>>> for stored fields with index sort, to 8.x this weekend. The patch is 
>>> ready,
>>> but we prefer to give CI some cycles before backporting. Please let me 
>>> know
>>> if it's okay with the release plan.
>>> >>
>>> >> Thanks,
>>> >> Nhat
>>> >>
>>> >> On Thu, May 13, 2021 at 12:44 PM Gus Heck 
>>> wrote:
>>> >>>
>>> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 should
>>> be investigated before 8.9, maybe make it a blocker?
>>> >>>
>>> >>> On Thu, May 13, 2021 at 1:35 AM Robert Muir 
>>> wrote:
>>> 
>>>  Mayya, I created backport for Adrien's issue here, to try to
>>> help out:
>>>  https://github.com/apache/lucene-solr/pull/2495
>>> 
>>>  Personally, I felt that merging non-trivial changes from main
>>> branch
>>>  to 8.x has some additional risks when cherry-picking:
>>>  * structural changes in main branch making merging more
>>> difficult
>>>  (e.g. LUCENE-9705 reorganization of codec versioning, great
>>> change
>>>  moving forwards though)
>>>  * there are many style changes due to spotless in main branch
>>> which
>>>  add noise to merging against old code.

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Walter Underwood]

Could someone else please take a look at SOLR-15056? This is a small blast 
radius change that improves the circuit breakers. It includes unit tests and 
documentation and has been ready since January.

https://github.com/apache/solr/pull/96/files 

https://issues.apache.org/jira/browse/SOLR-15056 


wunder
Walter Underwood
wun...@wunderwood.org
http://observer.wunderwood.org/  (my blog)

> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>  wrote:
> 
> Thank you for the update, Houston.
> 
> I've started the release process, the branch 8.9 is now cut.
> 
> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman  > wrote:
> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
> 
> - Houston
> 
> On Thu, May 27, 2021 at 11:42 PM David Smiley  > wrote:
> SOLR-15412 is rather serious as the title suggests.  I haven't been tracking 
> the progress so if it's already resolved, that's unknown to me and isn't 
> reflected in JIRA.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
>  wrote:
> Hello everyone,
> I wonder if everyone is ok for May 31st (Monday) as the date for the feature 
> freeze date and branch cut?
> I've noticed that `releaseWizard.py` is also asking for the length of feature 
> freeze. What is the custom length to put there?
> 
> Looks like Lucene 
>  doesn't 
> have any unresolved issues for 8.9.
> SOLR  has:
> -  SOLR-15412  Strict validation on Replica metadata can cause complete 
> outage  (Looks like it may be resolved already?)
> - SOLR-15410 GC log is directed to console when starting Solr with Java 11 
> Open J9 on Windows
> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not Unix load 
> average
> 
> Are we ok to postpone these issues to later releases if they are not resolved 
> and merged before feature freeze?
> 
> Thank you.
> 
> 
> 
> 
> 
> 
> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie  > wrote:
> Hello,
> Eric was going to have a look at the PR.
> But if it isn't done in time then I don't think it needs to block the release
> 
> Thanks
> 
> On Tue, 25 May 2021 at 15:50, Mayya Sharipova 
>  wrote:
> Hello Colvin,
> I am wondering if you still want to merge SOLR-15410 for the Lucene/Solr 8.9 
> release?  
> Should we have a deadline for feature freeze? Say May 30th (Sunday)? 
> 
> Thank you.
> 
> On Tue, May 18, 2021 at 8:49 AM Noble Paul  > wrote:
> +1
> 
> 
> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie  > wrote:
> >
> > Hello,
> >
> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC logging 
> > when using new versions of OpenJ9. It's small, so if somebody could have a 
> > look at it in time for 8.9 that would be great
> >
> > Thanks,
> > Colvin
> >
> > On Thu, 13 May 2021 at 17:52, Nhat Nguyen  > .invalid> wrote:
> >>
> >> Hi Mayya,
> >>
> >> I would like to backport LUCENE-9935, which enables bulk-merge for stored 
> >> fields with index sort, to 8.x this weekend. The patch is ready, but we 
> >> prefer to give CI some cycles before backporting. Please let me know if 
> >> it's okay with the release plan.
> >>
> >> Thanks,
> >> Nhat
> >>
> >> On Thu, May 13, 2021 at 12:44 PM Gus Heck  >> > wrote:
> >>>
> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 
> >>>  should be investigated 
> >>> before 8.9, maybe make it a blocker?
> >>>
> >>> On Thu, May 13, 2021 at 1:35 AM Robert Muir  >>> > wrote:
> 
>  Mayya, I created backport for Adrien's issue here, to try to help out:
>  https://github.com/apache/lucene-solr/pull/2495 
>  
> 
>  Personally, I felt that merging non-trivial changes from main branch
>  to 8.x has some additional risks when cherry-picking:
>  * structural changes in main branch making merging more difficult
>  (e.g. LUCENE-9705 reorganization of codec versioning, great change
>  moving forwards though)
>  * there are many style changes due to spotless in main branch which
>  add noise to merging against old code.
>  * In the specific case of LUCENE-9827, the usual additional tricky
>  backwards compatibility for 8.x must be added in the backport (due to
>  minor version bumps there) which can go wrong.
> 
>  I still think that particular change is worth considering for 8.9, it
>  isn't just a performance bug but also a huge improvement to test
>  

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Mayya Sharipova]

Thank you for the update, Houston.

I've started the release process, the branch 8.9 is now cut.

On Tue, Jun 1, 2021 at 11:21 AM Houston Putman  wrote:

> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>
> - Houston
>
> On Thu, May 27, 2021 at 11:42 PM David Smiley  wrote:
>
>> SOLR-15412 is rather serious as the title suggests.  I haven't been
>> tracking the progress so if it's already resolved, that's unknown to me and
>> isn't reflected in JIRA.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova
>>  wrote:
>>
>>> Hello everyone,
>>> I wonder if everyone is ok for May 31st (Monday) as the date for the
>>> feature freeze date and branch cut?
>>> I've noticed that `releaseWizard.py` is also asking for the length of
>>> feature freeze. What is the custom length to put there?
>>>
>>> Looks like Lucene
>>> 
>>> doesn't have any unresolved issues for 8.9.
>>> SOLR 
>>>  has:
>>> -  SOLR-15412  Strict validation on Replica metadata can cause complete
>>> outage  (Looks like it may be resolved already?)
>>> - SOLR-15410 GC log is directed to console when starting Solr with Java
>>> 11 Open J9 on Windows
>>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not Unix
>>> load average
>>>
>>> Are we ok to postpone these issues to later releases if they are not
>>> resolved and merged before feature freeze?
>>>
>>> Thank you.
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie <
>>> colvin.cowie@gmail.com> wrote:
>>>
 Hello,
 Eric was going to have a look at the PR.
 But if it isn't done in time then I don't think it needs to block the
 release

 Thanks

 On Tue, 25 May 2021 at 15:50, Mayya Sharipova
  wrote:

> Hello Colvin,
> I am wondering if you still want to merge SOLR-15410 for the
> Lucene/Solr 8.9 release?
> Should we have a deadline for feature freeze? Say May 30th (Sunday)?
>
> Thank you.
>
> On Tue, May 18, 2021 at 8:49 AM Noble Paul 
> wrote:
>
>> +1
>>
>>
>> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <
>> colvin.cowie@gmail.com> wrote:
>> >
>> > Hello,
>> >
>> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC
>> logging when using new versions of OpenJ9. It's small, so if somebody 
>> could
>> have a look at it in time for 8.9 that would be great
>> >
>> > Thanks,
>> > Colvin
>> >
>> > On Thu, 13 May 2021 at 17:52, Nhat Nguyen 
>> > 
>> wrote:
>> >>
>> >> Hi Mayya,
>> >>
>> >> I would like to backport LUCENE-9935, which enables bulk-merge for
>> stored fields with index sort, to 8.x this weekend. The patch is ready, 
>> but
>> we prefer to give CI some cycles before backporting. Please let me know 
>> if
>> it's okay with the release plan.
>> >>
>> >> Thanks,
>> >> Nhat
>> >>
>> >> On Thu, May 13, 2021 at 12:44 PM Gus Heck 
>> wrote:
>> >>>
>> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 should
>> be investigated before 8.9, maybe make it a blocker?
>> >>>
>> >>> On Thu, May 13, 2021 at 1:35 AM Robert Muir 
>> wrote:
>> 
>>  Mayya, I created backport for Adrien's issue here, to try to
>> help out:
>>  https://github.com/apache/lucene-solr/pull/2495
>> 
>>  Personally, I felt that merging non-trivial changes from main
>> branch
>>  to 8.x has some additional risks when cherry-picking:
>>  * structural changes in main branch making merging more difficult
>>  (e.g. LUCENE-9705 reorganization of codec versioning, great
>> change
>>  moving forwards though)
>>  * there are many style changes due to spotless in main branch
>> which
>>  add noise to merging against old code.
>>  * In the specific case of LUCENE-9827, the usual additional
>> tricky
>>  backwards compatibility for 8.x must be added in the backport
>> (due to
>>  minor version bumps there) which can go wrong.
>> 
>>  I still think that particular change is worth considering for
>> 8.9, it
>>  isn't just a performance bug but also a huge improvement to test
>>  coverage that helps combat risks.
>> 
>>  But we should still take some precautions when releasing an 8.x
>> IMO:
>>  * be mindful of what we are backporting and the risks involved:
>> it is harder.
>>  * try to let jenkins bake changes in 8.x branches for longer than
>>  usual? even a few days really helps.
>> 
>>  On Tue, May 11, 2021 at 1:29 PM Mayya Sharipova
>>   wrote:
>>  >

Re: Welcome Greg Miller as Lucene committer

[Steve Rowe]

Congrats and welcome, Greg!

--
Steve

> On May 29, 2021, at 3:47 PM, Adrien Grand  wrote:
> 
> I'm pleased to announce that Greg Miller has accepted the PMC's invitation to 
> become a committer.
> 
> Greg, the tradition is that new committers introduce themselves with a brief 
> bio.
> 
> Congratulations and welcome!
> 
> -- 
> Adrien


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

RE: Welcome Greg Miller as Lucene committer

[Uwe Schindler]

Hi,

 

Welcome Greg!

 

Uwe

 

-

Uwe Schindler

Achterdiek 19, D-28357 Bremen

  https://www.thetaphi.de

eMail: u...@thetaphi.de

 

From: Adrien Grand  
Sent: Saturday, May 29, 2021 9:47 PM
To: Lucene Dev 
Cc: gsmil...@gmail.com
Subject: Welcome Greg Miller as Lucene committer

 

I'm pleased to announce that Greg Miller has accepted the PMC's invitation to 
become a committer.

Greg, the tradition is that new committers introduce themselves with a brief 
bio.

Congratulations and welcome!


 

-- 

Adrien

Re: Welcome Greg Miller as Lucene committer

[Houston Putman]

Congrats and welcome Greg!

On Tue, Jun 1, 2021 at 8:42 AM Gus Heck  wrote:

> Welcome Greg :)
>
> On Tue, Jun 1, 2021 at 12:03 AM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> Congrats Greg!!
>>
>> On Mon, May 31, 2021 at 9:37 AM Gautam Worah 
>> wrote:
>>
>>> Congratulations Greg :)
>>>
>>> On Mon, May 31, 2021, 8:02 AM Ilan Ginzburg  wrote:
>>>
 Congrats Greg!

 On Sun, May 30, 2021 at 4:35 PM Greg Miller  wrote:

> Thanks everyone! I'm honored to have been nominated and look forward
> to continuing to work with all of you on Lucene! I'm incredibly
> grateful for everyone that has helped me so far. There's a lot to
> learn in Lucene and this community has been a fantastic help ramping
> up, providing thorough PR feedback/ideas/etc. and simply been a great
> group of people to collaborate with.
>
> As far as a brief bio goes, I live in the Seattle area and work for
> Amazon's "Product Search" team, which I joined in January of this
> year. I'm a naturally curious person and find myself fascinated by
> data structure / algorithm problems, so diving into Lucene has been
> really fun! I'm also an avid runner (mostly marathons but right now
> I'm training for my first one-mile race on a track), and love to
> travel with my wife and daughter (although that's been on "pause" for
> obvious reasons for the past year+). My biggest accomplishment of 2021
> so far has been teaching my daughter to ride a bike, but being
> nominated as a Lucene committer is a close second :)
>
> Thanks again everyone and looking forward to continuing to work with
> all of you!
>
> Cheers,
> -Greg
>
> On Sat, May 29, 2021 at 7:59 PM Michael McCandless
>  wrote:
> >
> > Welcome Greg!
> >
> > Mike
> >
> > On Sat, May 29, 2021 at 3:47 PM Adrien Grand 
> wrote:
> >>
> >> I'm pleased to announce that Greg Miller has accepted the PMC's
> invitation to become a committer.
> >>
> >> Greg, the tradition is that new committers introduce themselves
> with a brief bio.
> >>
> >> Congratulations and welcome!
> >>
> >>
> >> --
> >> Adrien
> >
> > --
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Re: Release Lucene/Solr 8.9.0 should we have it soon

[Houston Putman]

Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.

- Houston

On Thu, May 27, 2021 at 11:42 PM David Smiley  wrote:

> SOLR-15412 is rather serious as the title suggests.  I haven't been
> tracking the progress so if it's already resolved, that's unknown to me and
> isn't reflected in JIRA.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova
>  wrote:
>
>> Hello everyone,
>> I wonder if everyone is ok for May 31st (Monday) as the date for the
>> feature freeze date and branch cut?
>> I've noticed that `releaseWizard.py` is also asking for the length of
>> feature freeze. What is the custom length to put there?
>>
>> Looks like Lucene
>> 
>> doesn't have any unresolved issues for 8.9.
>> SOLR 
>>  has:
>> -  SOLR-15412  Strict validation on Replica metadata can cause complete
>> outage  (Looks like it may be resolved already?)
>> - SOLR-15410 GC log is directed to console when starting Solr with Java
>> 11 Open J9 on Windows
>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not Unix
>> load average
>>
>> Are we ok to postpone these issues to later releases if they are not
>> resolved and merged before feature freeze?
>>
>> Thank you.
>>
>>
>>
>>
>>
>>
>> On Tue, May 25, 2021 at 12:41 PM Colvin Cowie 
>> wrote:
>>
>>> Hello,
>>> Eric was going to have a look at the PR.
>>> But if it isn't done in time then I don't think it needs to block the
>>> release
>>>
>>> Thanks
>>>
>>> On Tue, 25 May 2021 at 15:50, Mayya Sharipova
>>>  wrote:
>>>
 Hello Colvin,
 I am wondering if you still want to merge SOLR-15410 for the
 Lucene/Solr 8.9 release?
 Should we have a deadline for feature freeze? Say May 30th (Sunday)?

 Thank you.

 On Tue, May 18, 2021 at 8:49 AM Noble Paul 
 wrote:

> +1
>
>
> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <
> colvin.cowie@gmail.com> wrote:
> >
> > Hello,
> >
> > I raised SOLR-15410 yesterday with a PR to fix an issue with GC
> logging when using new versions of OpenJ9. It's small, so if somebody 
> could
> have a look at it in time for 8.9 that would be great
> >
> > Thanks,
> > Colvin
> >
> > On Thu, 13 May 2021 at 17:52, Nhat Nguyen 
> > 
> wrote:
> >>
> >> Hi Mayya,
> >>
> >> I would like to backport LUCENE-9935, which enables bulk-merge for
> stored fields with index sort, to 8.x this weekend. The patch is ready, 
> but
> we prefer to give CI some cycles before backporting. Please let me know if
> it's okay with the release plan.
> >>
> >> Thanks,
> >> Nhat
> >>
> >> On Thu, May 13, 2021 at 12:44 PM Gus Heck 
> wrote:
> >>>
> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 should
> be investigated before 8.9, maybe make it a blocker?
> >>>
> >>> On Thu, May 13, 2021 at 1:35 AM Robert Muir 
> wrote:
> 
>  Mayya, I created backport for Adrien's issue here, to try to help
> out:
>  https://github.com/apache/lucene-solr/pull/2495
> 
>  Personally, I felt that merging non-trivial changes from main
> branch
>  to 8.x has some additional risks when cherry-picking:
>  * structural changes in main branch making merging more difficult
>  (e.g. LUCENE-9705 reorganization of codec versioning, great change
>  moving forwards though)
>  * there are many style changes due to spotless in main branch
> which
>  add noise to merging against old code.
>  * In the specific case of LUCENE-9827, the usual additional tricky
>  backwards compatibility for 8.x must be added in the backport
> (due to
>  minor version bumps there) which can go wrong.
> 
>  I still think that particular change is worth considering for
> 8.9, it
>  isn't just a performance bug but also a huge improvement to test
>  coverage that helps combat risks.
> 
>  But we should still take some precautions when releasing an 8.x
> IMO:
>  * be mindful of what we are backporting and the risks involved:
> it is harder.
>  * try to let jenkins bake changes in 8.x branches for longer than
>  usual? even a few days really helps.
> 
>  On Tue, May 11, 2021 at 1:29 PM Mayya Sharipova
>   wrote:
>  >
>  > Thanks everyone,
>  >
>  > Adrien, I  am happy to try to be a release manager for this
> release.
>  >
>  > Adrien, and Gus, please let me know when your changes are
> merged to 8.x
>  >
>  >
>  >
>  > On Tue, May 11, 2021 at 10:38 AM Gus Heck 
> wrote:
>  

Re: Statement from the Solr and Lucene PMC regarding recent Code of Conduct violations

[Ishan Chattopadhyaya]

Thanks Jan and both the PMCs.

On Tue, 1 Jun, 2021, 1:03 pm Jan Høydahl,  wrote:

> This is a joint statement on behalf of the Apache Solr and Lucene Project
> Management Committees (PMCs).
>
> Some of the language used in May 2021 on the SOLR-14245 JIRA issue [1] and
> the concurrent dev@solr [2] and dev@lucene [3] mailing list threads
> violates our project community's Code of Conduct [4]. Personal attacks,
> blaming, and negative characterizations of others are harmful in open
> source development and will not be tolerated in our community.
>
> The Apache Solr and Lucene PMCs [5][6] have privately discussed the matter
> and wish to publicly and officially censure the referenced behavior of
> Ishan Chattopadhyaya and Noble Paul. Future infractions will have stronger
> consequences. Of course we hope it won't come to that, and we hope this
> addresses any concern in our communities about participating in open-source
> development with civility and respect. Any additional questions or concerns
> regarding the code of conduct can be sent to priv...@solr.apache.org or
> priv...@lucene.apache.org.
>
> [1] https://issues.apache.org/jira/browse/SOLR-14245
> [2]
> https://lists.apache.org/thread.html/rced539c2708284bf94a70c514c181ae643f0d7327a2d603e08422115%40%3Cdev.solr.apache.org%3E
> 
> [3]
> https://lists.apache.org/thread.html/rced539c2708284bf94a70c514c181ae643f0d7327a2d603e08422115%40%3Cdev.lucene.apache.org%3E
> [4] https://solr.apache.org/community.html#code-of-conduct
> [5] https://solr.apache.org/whoweare.html#project-management-committee
> [6]
> https://lucene.apache.org/whoweare.html#lucene-project-management-committee-pmc
>

Re: Welcome Greg Miller as Lucene committer

[Gus Heck]

Welcome Greg :)

On Tue, Jun 1, 2021 at 12:03 AM Tomás Fernández Löbbe 
wrote:

> Congrats Greg!!
>
> On Mon, May 31, 2021 at 9:37 AM Gautam Worah 
> wrote:
>
>> Congratulations Greg :)
>>
>> On Mon, May 31, 2021, 8:02 AM Ilan Ginzburg  wrote:
>>
>>> Congrats Greg!
>>>
>>> On Sun, May 30, 2021 at 4:35 PM Greg Miller  wrote:
>>>
 Thanks everyone! I'm honored to have been nominated and look forward
 to continuing to work with all of you on Lucene! I'm incredibly
 grateful for everyone that has helped me so far. There's a lot to
 learn in Lucene and this community has been a fantastic help ramping
 up, providing thorough PR feedback/ideas/etc. and simply been a great
 group of people to collaborate with.

 As far as a brief bio goes, I live in the Seattle area and work for
 Amazon's "Product Search" team, which I joined in January of this
 year. I'm a naturally curious person and find myself fascinated by
 data structure / algorithm problems, so diving into Lucene has been
 really fun! I'm also an avid runner (mostly marathons but right now
 I'm training for my first one-mile race on a track), and love to
 travel with my wife and daughter (although that's been on "pause" for
 obvious reasons for the past year+). My biggest accomplishment of 2021
 so far has been teaching my daughter to ride a bike, but being
 nominated as a Lucene committer is a close second :)

 Thanks again everyone and looking forward to continuing to work with
 all of you!

 Cheers,
 -Greg

 On Sat, May 29, 2021 at 7:59 PM Michael McCandless
  wrote:
 >
 > Welcome Greg!
 >
 > Mike
 >
 > On Sat, May 29, 2021 at 3:47 PM Adrien Grand 
 wrote:
 >>
 >> I'm pleased to announce that Greg Miller has accepted the PMC's
 invitation to become a committer.
 >>
 >> Greg, the tradition is that new committers introduce themselves with
 a brief bio.
 >>
 >> Congratulations and welcome!
 >>
 >>
 >> --
 >> Adrien
 >
 > --
 > Mike McCandless
 >
 > http://blog.mikemccandless.com

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



-- 
http://www.needhamsoftware.com (work)
http://www.the111shift.com (play)

Re: [JENKINS] Lucene » Lucene-Solr-SmokeRelease-8.x - Build # 220 - Still Failing!

[Jason Gerlowski]

Hey all,

This is my fault.  Will look at fixing it this morning.  Sorry for the
disruption!

If this is blocking anyone, let me know and I'll revert the offending
commit while I investigate the cause.  Otherwise I'll just leave it
as-is and push to have a fix as soon as I can.

Jason

On Sat, May 29, 2021 at 8:35 PM Robert Muir  wrote:
>
> The latest 8.x failure seems to be related to POM files from solr gcs
> repository. I don't currently know what is needed to move this along.
>
> On Sat, May 29, 2021 at 8:28 PM Apache Jenkins Server
>  wrote:
> >
> > Build: 
> > https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-SmokeRelease-8.x/220/
> >
> > No tests ran.
> >
> > Build Log:
> > [...truncated 28456 lines...]
> > BUILD FAILED
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/build.xml:431:
> >  The following error occurred while executing this line:
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/solr/build.xml:685:
> >  The following error occurred while executing this line:
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/solr/build.xml:664:
> >  The following error occurred while executing this line:
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/solr/common-build.xml:471:
> >  The following error occurred while executing this line:
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/lucene/common-build.xml:1767:
> >  The following error occurred while executing this line:
> > /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/lucene/common-build.xml:682:
> >  Unable to initialize POM pom.xml: Could not find the model file 
> > '/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.x/lucene/build/poms/solr/contrib/gcs-repository/pom.xml'.
> >  for project unknown
> >
> > Total time: 7 minutes 13 seconds
> > Build step 'Invoke Ant' marked build as failure
> > Setting JDK_1_9_LATEST_HOME=/home/jenkins/tools/java/latest1.9
> > Email was triggered for: Failure - Any
> > Sending email for trigger: Failure - Any
> > Setting JDK_1_9_LATEST_HOME=/home/jenkins/tools/java/latest1.9
> > Setting JDK_1_9_LATEST_HOME=/home/jenkins/tools/java/latest1.9
> > Setting JDK_1_9_LATEST_HOME=/home/jenkins/tools/java/latest1.9
> > Setting JDK_1_9_LATEST_HOME=/home/jenkins/tools/java/latest1.9
>
> -
> 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: Doubling down on our mistakes?

[Jan Høydahl]

To everyone following this e-mail thread.

The Project Management Committees have discussed the matter and would like to 
draw attention to "Statement from the Solr and Lucene PMC regarding recent Code 
of Conduct violations" posted to this list today, and linked below:

https://lists.apache.org/thread.html/r9875b53aeaebca8678ee0127562d8a35c7938906fbd318ac17ba011d%40%3Cdev.solr.apache.org%3E
 

Jan Høydahl
Solr PMC Chair

> 21. mai 2021 kl. 05:52 skrev David Smiley :
> 
> I removed dev@lucene.apache.org  from my 
> response here.  Please everyone do the same and don't email both Lucene & 
> Solr at the same time.  I recall that's an old best practice / rule in 
> general -- never address an email to more than one list.
> 
> I agree 100% with Erick.  It's shameful and looks bad on our community and 
> it's just so not necessary.  It's a clear code-of-conduct violation.  I hope 
> Andrzej is "okay" emotionally; I'd be a mess in his shoes.  At least the 
> apologies are very reasonable to me; I was expecting Ishan/Noble to dig their 
> heels in (as I witnessed some months ago) and I'm relieved not to see that.  
> 
> The internal complexity of Solr (esp. SolrCloud) is very high; it's difficult 
> to make changes and not have some worry that maybe a change has some ill 
> effect.  Yet we can't simply not touch it.  The irony here is that the change 
> in question was targeted directly at improving the quality of Solr; I love 
> those types of changes, honestly.
> 
> Perhaps Solr getting it's own Docker images as part of the project may lead 
> to automated Solr-upgrade testing to catch compatibility bugs?  Maybe that 
> might be done at the K8S Solr Operator level integration tests since I'm 
> guessing the Operator facilitates upgrades already?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Tue, May 18, 2021 at 8:54 AM Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> I apologize for the harsh words, and personally to Andrzej for hurting your 
> feelings. I had no such intentions. 
> 
> > You conveniently don’t mention that I WITHDREW my objection, and instead 
> > proposed a lenient validation (but validation nonetheless!).
> Yes, let me mention that you agreed in principal to reduce the impact of the 
> change (even though not completely revert it). I welcome that and thank you 
> for that. By the time you replied on JIRA, I had already sent this mail.
> 
> > I see no urgency at all in this matter. This can be handled as day-to-day 
> > bug fixing as usual.
> I think this requires an immediate notification to all users to be aware of 
> this situation before upgrading. Also, an immediate breakfix should be 
> helpful for them. 
> 
> > My feelings are hurt, and I'm greatly disappointed in your words, quick 
> > attacking off the cuff regularly rude (IMO) because you happened to have a 
> > bad day.
> I apologize.
> 
> How I saw things is that we have a commitment to our users to give them good 
> quality software that they can rely on. My intention was not to attack 
> Andrzej personally, but to bring about collective awareness regarding this 
> problem: that we, as a community, don't care enough for our users. We need to 
> get better at testing, get better at reviews, better at benchmarks, etc. 
> Individually, we all have the best of intentions, and obviously so does 
> Andrzej. However, we need to get better, and I wanted this to be a starting 
> point in that conversation. Clearly, I was carried over and I apologize for 
> that.
> 
> On Tue, May 18, 2021 at 5:52 PM Andrzej Białecki  > wrote:
> Ishan, as I pointed out in Jira I don’t care for you implying that I have 
> evil intentions, I resent also your implication that I’m behaving 
> irrationally or don’t care for the users. Those of you who are interested may 
> read the comments in Jira and judge for themselves.
> 
> You conveniently don’t mention that I WITHDREW my objection, and instead 
> proposed a lenient validation (but validation nonetheless!). It’s easy to 
> scream “revert! revert!” but it actually takes some consideration to properly 
> address the original purpose of this change - that is, detecting and avoiding 
> the corruption of replica state. Let’s focus on this and not on pointing 
> fingers.
> 
> As for the production outage - I’m sorry this happened to you. As I hope you 
> and Noble and others are sorry for other inadvertently introduced bugs, which 
> I’m sure brought down many clusters at inconvenient hours... 
> 
> 
>> On 18 May 2021, at 13:26, Ishan Chattopadhyaya > > wrote:
>> 
>> https://issues.apache.org/jira/browse/SOLR-14245 
>> 
>> 
>> There 

Statement from the Solr and Lucene PMC regarding recent Code of Conduct violations

[Jan Høydahl]

This is a joint statement on behalf of the Apache Solr and Lucene Project 
Management Committees (PMCs).

Some of the language used in May 2021 on the SOLR-14245 JIRA issue [1] and the 
concurrent dev@solr [2] and dev@lucene [3] mailing list threads violates our 
project community's Code of Conduct [4]. Personal attacks, blaming, and 
negative characterizations of others are harmful in open source development and 
will not be tolerated in our community.

The Apache Solr and Lucene PMCs [5][6] have privately discussed the matter and 
wish to publicly and officially censure the referenced behavior of Ishan 
Chattopadhyaya and Noble Paul. Future infractions will have stronger 
consequences. Of course we hope it won't come to that, and we hope this 
addresses any concern in our communities about participating in open-source 
development with civility and respect. Any additional questions or concerns 
regarding the code of conduct can be sent to priv...@solr.apache.org or 
priv...@lucene.apache.org.

[1] https://issues.apache.org/jira/browse/SOLR-14245 

[2] 
https://lists.apache.org/thread.html/rced539c2708284bf94a70c514c181ae643f0d7327a2d603e08422115%40%3Cdev.solr.apache.org%3E
 

[3] 
https://lists.apache.org/thread.html/rced539c2708284bf94a70c514c181ae643f0d7327a2d603e08422115%40%3Cdev.lucene.apache.org%3E
 

[4] https://solr.apache.org/community.html#code-of-conduct 

[5] https://solr.apache.org/whoweare.html#project-management-committee 

[6] 
https://lucene.apache.org/whoweare.html#lucene-project-management-committee-pmc 

Re: [jira] [Commented] (LUCENE-9983) Stop sorting determinize powersets unnecessarily

[Dawid Weiss]

Hi Mike,

Looking at the algorithm it's the opposite - it tries hard not to iterate
over all the combinations. The "power sets" come from combinations of
accessible sets of states using different NFA paths. This example is pretty
good:

https://en.wikipedia.org/wiki/Powerset_construction#Example

Dawid

On Tue, Jun 1, 2021 at 1:11 AM Michael Sokolov  wrote:

> I haven't looked at this at all, so please disregard if I'm off base, but
> it sounds as if we are materializing power sets? Would it be better to just
> store an array of the members and generate the combinations iteratively on
> demand?
>
> On Mon, May 31, 2021, 5:27 PM Haoyu Zhai (Jira)  wrote:
>
>>
>> [
>> https://issues.apache.org/jira/browse/LUCENE-9983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17354660#comment-17354660
>> ]
>>
>> Haoyu Zhai commented on LUCENE-9983:
>> 
>>
>> I've added a simple static counter just for the adversarial test, and
>> here's the stats:
>>  * {{incr}} called: 106073079
>>  * entry added to set: 100076079
>>  * {{decr}} called: 106069079
>>  * entry removed from set: 100072079
>>  * {{computeHash}} called: 40057
>>  * {{freeze}} called: 14056
>>
>> So seems to me my guess above holds, we're doing way more put/remove
>> entry operations than others
>>
>> > Stop sorting determinize powersets unnecessarily
>> > 
>> >
>> > Key: LUCENE-9983
>> > URL: https://issues.apache.org/jira/browse/LUCENE-9983
>> > Project: Lucene - Core
>> >  Issue Type: Improvement
>> >Reporter: Michael McCandless
>> >Priority: Major
>> >  Time Spent: 40m
>> >  Remaining Estimate: 0h
>> >
>> > Spinoff from LUCENE-9981.
>> > Today, our {{Operations.determinize}} implementation builds powersets
>> of all subsets of NFA states that "belong" in the same determinized state,
>> using [this algorithm|https://en.wikipedia.org/wiki/Powerset_construction
>> ].
>> > To hold each powerset, we use a malleable {{SortedIntSet}} and
>> periodically freeze it to a {{FrozenIntSet}}, also sorted.  We pay a high
>> price to keep these growing maps of int key, int value sorted by key, e.g.
>> upgrading to a {{TreeMap}} once the map is large enough (> 30 entries).
>> > But I think sorting is entirely unnecessary here!  Really all we need
>> is the ability to add/delete keys from the map, and hashCode / equals (by
>> key only – ignoring value!), and to freeze the map (a small optimization
>> that we could skip initially).  We only use these maps to lookup in the
>> (growing) determinized automaton whether this powerset has already been
>> seen.
>> > Maybe we could simply poach the {{IntIntScatterMap}} implementation
>> from [HPPC|https://github.com/carrotsearch/hppc]?  And then change its
>> {{hashCode}}/{{equals }}to only use keys (not values).
>> > This change should be a big speedup for the kinds of (admittedly
>> adversarial) regexps we saw on LUCENE-9981.
>> >
>>
>>
>>
>> --
>> This message was sent by Atlassian Jira
>> (v8.3.4#803005)
>>
>> -
>> To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: issues-h...@lucene.apache.org
>>
>>