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 <dsmi...@apache.org> 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 
> <http://www.linkedin.com/in/davidwsmiley>
> 
> On Tue, Jun 1, 2021 at 4:55 PM Jan Høydahl <jan....@cominvent.com 
> <mailto:jan....@cominvent.com>> 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 <a...@apache.org 
>> <mailto:a...@apache.org>>:
>> 
>> 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, <wun...@wunderwood.org 
>> <mailto:wun...@wunderwood.org>> 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 
>> <https://github.com/apache/solr/pull/96>
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
>> http://observer.wunderwood.org/ <http://observer.wunderwood.org/>  (my blog)
>> 
>>> On Jun 1, 2021, at 12:27 PM, Walter Underwood <wun...@wunderwood.org 
>>> <mailto:wun...@wunderwood.org>> 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 <mailto:wun...@wunderwood.org>
>>> http://observer.wunderwood.org/ <http://observer.wunderwood.org/>  (my blog)
>>> 
>>>> On Jun 1, 2021, at 12:20 PM, Atri Sharma <a...@apache.org 
>>>> <mailto:a...@apache.org>> 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, <wun...@wunderwood.org 
>>>> <mailto:wun...@wunderwood.org>> 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://github.com/apache/solr/pull/96/files>
>>>> https://issues.apache.org/jira/browse/SOLR-15056 
>>>> <https://issues.apache.org/jira/browse/SOLR-15056>
>>>> 
>>>> wunder
>>>> Walter Underwood
>>>> wun...@wunderwood.org <mailto:wun...@wunderwood.org>
>>>> http://observer.wunderwood.org/ <http://observer.wunderwood.org/>  (my 
>>>> blog)
>>>> 
>>>>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova 
>>>>> <mayya.sharip...@elastic.co.INVALID 
>>>>> <mailto: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 <hous...@apache.org 
>>>>> <mailto:hous...@apache.org>> 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 <dsmi...@apache.org 
>>>>> <mailto:dsmi...@apache.org>> 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 
>>>>> <http://www.linkedin.com/in/davidwsmiley>
>>>>> 
>>>>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova 
>>>>> <mayya.sharip...@elastic.co.invalid 
>>>>> <mailto: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 
>>>>> <https://issues.apache.org/jira/projects/LUCENE/versions/12349562> 
>>>>> doesn't have any unresolved issues for 8.9.
>>>>> SOLR <https://issues.apache.org/jira/projects/SOLR/versions/12349563> 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 
>>>>> <mailto: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 
>>>>> <mailto: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 <noble.p...@gmail.com 
>>>>> <mailto:noble.p...@gmail.com>> wrote:
>>>>> +1
>>>>> 
>>>>> 
>>>>> On Tue, May 18, 2021 at 9:30 PM Colvin Cowie <colvin.cowie....@gmail.com 
>>>>> <mailto: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 <nhat.ngu...@elastic.co 
>>>>> > <mailto:nhat.ngu...@elastic.co>.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 <gus.h...@gmail.com 
>>>>> >> <mailto:gus.h...@gmail.com>> wrote:
>>>>> >>>
>>>>> >>> Perhaps https://issues.apache.org/jira/browse/SOLR-15378 
>>>>> >>> <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 <rcm...@gmail.com 
>>>>> >>> <mailto:rcm...@gmail.com>> wrote:
>>>>> >>>>
>>>>> >>>> Mayya, I created backport for Adrien's issue here, to try to help 
>>>>> >>>> out:
>>>>> >>>> https://github.com/apache/lucene-solr/pull/2495 
>>>>> >>>> <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
>>>>> >>>> <mayya.sharip...@elastic.co 
>>>>> >>>> <mailto:mayya.sharip...@elastic.co>.invalid> 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 <gus.h...@gmail.com 
>>>>> >>>> > <mailto:gus.h...@gmail.com>> wrote:
>>>>> >>>> >>
>>>>> >>>> >> I'm also looking to find time to get 
>>>>> >>>> >> https://issues.apache.org/jira/browse/SOLR-14597 
>>>>> >>>> >> <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 <jpou...@gmail.com 
>>>>> >>>> >> <mailto:jpou...@gmail.com>> wrote:
>>>>> >>>> >>>
>>>>> >>>> >>> I would like to backport LUCENE-9827 before we release 8.9, a 
>>>>> >>>> >>> performance regression to stored fields merges. I'll work on 
>>>>> >>>> >>> this as soon as possible.
>>>>> >>>> >>>
>>>>> >>>> >>> On Thu, May 6, 2021 at 10:28 PM Adrien Grand <jpou...@gmail.com 
>>>>> >>>> >>> <mailto:jpou...@gmail.com>> wrote:
>>>>> >>>> >>>>
>>>>> >>>> >>>> +1
>>>>> >>>> >>>>
>>>>> >>>> >>>> Mayya, are you volunteering to be the release manager?
>>>>> >>>> >>>>
>>>>> >>>> >>>> Le jeu. 6 mai 2021 à 18:06, Ishan Chattopadhyaya 
>>>>> >>>> >>>> <ichattopadhy...@gmail.com <mailto:ichattopadhy...@gmail.com>> 
>>>>> >>>> >>>> a écrit :
>>>>> >>>> >>>>>
>>>>> >>>> >>>>> +1
>>>>> >>>> >>>>>
>>>>> >>>> >>>>> On Thu, May 6, 2021 at 7:50 PM Mayya Sharipova 
>>>>> >>>> >>>>> <mayya.sharip...@elastic.co 
>>>>> >>>> >>>>> <mailto:mayya.sharip...@elastic.co>.invalid> wrote:
>>>>> >>>> >>>>>>
>>>>> >>>> >>>>>> Hello everyone,
>>>>> >>>> >>>>>> I was wondering if we can have a 8.9.0 release. It has been 
>>>>> >>>> >>>>>> more than 3 months since 8.8.0 was released.
>>>>> >>>> >>>>>> 8.9.0 doesn't need to be the last release in the 8.x series.
>>>>> >>>> >>>>>>
>>>>> >>>> >>>>>> Thanks.
>>>>> >>>> >>>
>>>>> >>>> >>>
>>>>> >>>> >>>
>>>>> >>>> >>> --
>>>>> >>>> >>> Adrien
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >>
>>>>> >>>> >> --
>>>>> >>>> >> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> 
>>>>> >>>> >> (work)
>>>>> >>>> >> http://www.the111shift.com <http://www.the111shift.com/> (play)
>>>>> >>>>
>>>>> >>>> ---------------------------------------------------------------------
>>>>> >>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>>>> >>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>>>> >>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>>>> >>>> <mailto:dev-h...@lucene.apache.org>
>>>>> >>>>
>>>>> >>>
>>>>> >>>
>>>>> >>> --
>>>>> >>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> 
>>>>> >>> (work)
>>>>> >>> http://www.the111shift.com <http://www.the111shift.com/> (play)
>>>>> 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> -----------------------------------------------------
>>>>> Noble Paul
>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>>>> <mailto:dev-unsubscr...@lucene.apache.org>
>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>>>> <mailto:dev-h...@lucene.apache.org>
>>>>> 
>>>> 
>>> 
>> 
> 

Reply via email to