Re: [Vote] Bump the Lucene main branch to Java 21

[Jan Høydahl]

+1

Jan

> 23. feb. 2024 kl. 20:01 skrev Patrick Zhai :
> 
> +1
> 
> On Fri, Feb 23, 2024 at 9:34 AM Dawid Weiss  > wrote:
>> 
>> I'm fine with this requirement. 
>> 
>> +1.
>> 
>> On Fri, Feb 23, 2024 at 12:24 PM Chris Hegarty 
>>  wrote:
>>> Hi,
>>> 
>>> Since the discussion on bumping the Lucene main branch to Java 21 is 
>>> winding down, let's hold a vote on this important change.
>>> 
>>> Once bumped, the next major release of Lucene (whenever that will be) will 
>>> require a version of Java greater than or equal to Java 21.
>>> 
>>> The vote will be open for at least 72 hours (and allow some additional time 
>>> for the weekend) i.e. until 2024-02-28 12:00 UTC.
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> Here is my +1
>>> 
>>> -Chris.
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>>> 
>>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>>> 
>>> 

Re: [VOTE] Release Lucene 9.10.0 RC1

[Jan Høydahl]

+1 (binding)

SUCCESS! [0:50:52.035790]

Jan

> 14. feb. 2024 kl. 20:28 skrev Adrien Grand :
> 
> Please vote for release candidate 1 for Lucene 9.10.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.10.0-RC1-rev-695c0ac84508438302cd346a812cfa2fdc5a10df
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.10.0-RC1-rev-695c0ac84508438302cd346a812cfa2fdc5a10df
> 
> The vote will be open for at least 72 hours i.e. until 2024-02-17 20:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.11.3 RC1

[Jan Høydahl]

+1 (binding)

SUCCESS! [1:18:11.930433]

Only ran smoke tester. macOS, Temurin 1.8.0_402

Jan

> 5. feb. 2024 kl. 23:23 skrev Houston Putman :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.11.3
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-revbaa7c80af4278cc8951a344d8e9320386588d12d
> 
> The vote will be open for at least 72 hours i.e. until 2024-02-08 23:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1

Re: [VOTE] Release Lucene 9.9.2 RC1

[Jan Høydahl]

+1

Only ran smoke tester

SUCCESS! [0:55:39.348431]

Jan


> 25. jan. 2024 kl. 12:57 skrev Chris Hegarty 
> :
> 
> Please vote for release candidate 1 for Lucene 9.9.2
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.2-RC1-rev-a2939784c4ca60bc28bf488b5479c02fc2e5e22c
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.2-RC1-rev-a2939784c4ca60bc28bf488b5479c02fc2e5e22c
> 
> The vote will be open for 96 hours ( allowing some additional time for 
> weekend span) i.e. until 2024-01-29 12:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> Draft release notes can be found at 
> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote9_9_2
> 
> -Chris.
> 
> 
> -
> 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: [VOTE] Release Lucene 9.9.1 RC1

[Jan Høydahl]

+1 (binding, smoketester only)

SUCCESS! [1:03:56.025355]

Jan

> 13. des. 2023 kl. 12:55 skrev Chris Hegarty 
> :
> 
> Hi,
> 
> Please vote for release candidate 1 for Lucene 9.9.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.1-RC1-rev-eee32cbf5e072a8c9d459c349549094230038308
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.1-RC1-rev-eee32cbf5e072a8c9d459c349549094230038308
> 
> The vote will be open for at least 72 hours i.e. until 2023-12-16 12:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -Chris.
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene 9.9.0 Release

[Jan Høydahl]

+1 to a 9.9.0 release, thanks for volunteering.

And also positive to immediately start planning the 10.0 release. JDK bump -> 
17 is a major "feature" in itself, so we can bump main branch to 21 too. And 
discontinue support for 8.x after the 8.11.3 release.

Jan

> 22. nov. 2023 kl. 17:11 skrev Michael Sokolov :
> 
> +1 thanks for volunteering! 
> 
> Hijacking the thread a bit, sorry, I started looking into whether this is a 
> good time to start looking ahead to 10? I know we had some rumblings about 
> releasing that so we can start requiring newer JDKs. But looking at CHANGES 
> it feels like we already back-ported most of the good stuff and lack a truly 
> compelling reason to move ahead (other than JDK requirement and fact that it 
> has been 2 years since 9). So maybe we wait a bit longer?
> 
> On Tue, Nov 21, 2023 at 11:04 AM Patrick Zhai  > wrote:
>> +1, thank you Chris!
>> 
>> On Tue, Nov 21, 2023, 06:49 Benjamin Trent > > wrote:
>>> +1 9.9 will be a stellar release!
>>> 
>>> Thank you Chris!
>>> 
>>> On Tue, Nov 21, 2023 at 7:31 AM Adrien Grand >> > wrote:
 +1 9.9 has plenty of great changes indeed! Thanks for volunteering as a 
 RM, Chris.
 
 It would be good to try and fix the PKLookup regression that was 
 introduced since 9.8: 
 http://people.apache.org/~mikemccand/lucenebench/PKLookup.html. Is it just 
 about getting #12699  merged?
 
 Separately, I have a PR that does a small change to the file format of 
 postings and skip lists. It's certainly not a blocker for 9.9, but it 
 would be convenient to get it into 9.9 since we already changed file 
 formats for the switch from PFOR to FOR. Does someone have time to take a 
 look? #12810 
 On Tue, Nov 21, 2023 at 11:16 AM Michael McCandless 
 mailto:luc...@mikemccandless.com>> wrote:
> +1
> 
> Thank you for volunteering as RC Chris!
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com 
> 
> On Tue, Nov 21, 2023 at 4:52 AM Chris Hegarty 
>  wrote:
>> Hi,
>> 
>> It's been a while since the 9.8.0 release and we’ve accumulated quite a 
>> few changes. I’d like to propose that we release 9.9.0.
>> 
>> If there's no objections, I volunteer to be the release manager and will 
>> cut the feature branch a week from now, 12:00 28th Nov UTC.
>> 
>> -Chris.
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
>> 
>> For additional commands, e-mail: dev-h...@lucene.apache.org 
>> 
>> 
 
 
 --
 Adrien

Re: Bump minimum Java version requirement to 21

[Jan Høydahl]

+1 to a 10.0 on JDK17.

There is no "agreement" anywhere to follow a 2-year cadence for major versions, 
even if that's been a pattern.
Adopting a new JDK with clear benefits or getting off an EOL JDK should be 
valid arguments for considering a new major.
If downstream wants to keep supporting 9.10.y into eternity after our 11.0 
rlease, then it's open source :) 

Jan

> 6. nov. 2023 kl. 13:40 skrev Chris Hegarty 
> :
> 
> Hi Robert,
> 
>> On 6 Nov 2023, at 12:24, Robert Muir  wrote:
>> 
>>> …
>>> The only concern I have with no.2 is that it could be considered an 
>>> “aggressive” adoption of Java 21 - adoption sooner than the ecosystem can 
>>> handle, e.g. are environments in which Lucene is deployed, and their 
>>> transitive dependencies, ready to run on Java 21? By the time we’re ready 
>>> to release 10.0.0, say March 2023, then I expect no issue with this.
>> 
>> The problem is worse, historically jdk version X isn't adopted as a
>> minimum until it is already EOL. And the lucene major versions take an
>> eternity to get out there, code just sits in "main" branch for years
>> unreleased to nobody. It is really discouraging as a contributor to
>> contribute code that literally sits on the shelf for years, for no
>> good reason at all.
> 
> Agreed. I also feel discouraged by this approach too, and also wanna
> avoid the “backport the world”, since it’s counterproductive.
> 
>> So why delay?
>> 
>> The argument of "moving sooner than ecosystem can handle" is also
>> bogus in the same way. You mean versus the code sitting on the shelf
>> and being released to nobody?
> 
> Yes - sitting on the shelf is no good to anyone.
> 
> Ok, what I’m hearing are good arguments for releasing 10.0.0 *now*, with
> a Java 17 minimum - this is what is in _main_ today.
> 
> If we do that, then we can follow up with _main_ later (after the 10.x
> branch is created). That is, 1) bump _main_ to Java 21, and 2) decide
> when a Lucene 11 is to be released (I would to see Lucene 11 ~1yr after
> Lucene 10).
> 
> This is Uwe’s proposal, earlier in this thread.
> 
> -Chris.
> 
> 
> 
> -
> 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: [VOTE] Release Lucene/Solr 8.11.3 RC1

[Jan Høydahl]

Hi,

Thanks for doing the release. I'm running smoke tester

However, there seems to be still open blocker issues in JIRA: 
https://issues.apache.org/jira/issues/?filter=12352945
I just resolved one other that was solved yesterday, but for the remaining 
three I cannot see that they are fixed.
Not 100% sure if all three qualify as blockers either, but they all look 
security related.

Jan

> 31. okt. 2023 kl. 10:24 skrev Ishan Chattopadhyaya 
> :
> 
> 
> Please vote for release candidate 1 for Lucene/Solr 8.11.3
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-rev10d925469f3d4e66b6339b9e1c7d4d4afa4cf206
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.3-RC1-rev10d925469f3d4e66b6339b9e1c7d4d4afa4cf206
> 
> The vote will be open for at least 72 hours i.e. until 2023-11-03 10:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> 
> 

Re: 8.11.3 release

[Jan Høydahl]

Thanks Kevin, Ishan for doing the prep work here.

I re-enabled the jenkins job 
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.11/ to get a 
feel for the current status. We also have a smokeTest job that should be 
enabled when release is approaching.

Jan

> 12. okt. 2023 kl. 19:38 skrev Kevin Risden :
> 
> I've pushed a few things to branch_8_11 recently
> *
> https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f
> *
> https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152
> *
> https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994
> 
> https://github.com/apache/lucene-solr/pull/2681 is in draft and updated a
> bunch of relatively low risk dependencies. There might be others we want to
> upgrade, but figured it was a decent start.
> 
> Kevin Risden
> 
> 
> On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac 
> wrote:
> 
>> I just opened a pull request.
>> https://github.com/apache/lucene-solr/pull/2679
>> Details are in the PR.
>> 
>> Thanks !
>> 
>> Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com>
>> a écrit :
>> 
>>> Thanks Pierre, I'll have it included in 8.11 once you are able to have a
>> PR
>>> for this. Thanks!
>>> 
>>> On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac 
>>> wrote:
>>> 
>>>> Hi Ishan,
>>>> Sorry for the late chime in.
>>>> 
>>>> Some time ago I filled a Jira for a Solr 8 specific bug:
>>>> https://issues.apache.org/jira/browse/SOLR-16843
>>>> 
>>>> At that time, I wasn't expecting more 8.x releases, so I did not open a
>>> PR
>>>> for it.
>>>> I can work on a fix if we have a few days more before the release. I
>>> think
>>>> it is worth to have it in solr 8 (that's not a backport)
>>>> 
>>>> Thanks
>>>> 
>>>> 
>>>> Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> a écrit :
>>>> 
>>>>> I'm going to track items from 9x releases in the following sheet.
>>>>> 
>>>>> 
>>>> 
>>> 
>> https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0
>>>>> 
>>>>> Please let me know if there's any item there that you think would be
>>>> useful
>>>>> to backport (if easy) to 8.11, and want me to take a look at
>>> backporting
>>>>> it.
>>>>> Regards,
>>>>> Ishan
>>>>> 
>>>>> On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya <
>>>>> ichattopadhy...@gmail.com> wrote:
>>>>> 
>>>>>> Just a reminder to backport any issues one sees fit for a 8.11.3
>>>> release.
>>>>>> I'll try to get an RC out by the end of September, so still more
>>> than a
>>>>>> week away.
>>>>>> 
>>>>>> On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>> 
>>>>>>> Hi Jan,
>>>>>>> Yes, still targeting September. But I will slip on my initial plan
>>> of
>>>>>>> doing it by first week of September. I'm foreseeing mid September
>>>>> timeframe.
>>>>>>> Thanks for checking in.
>>>>>>> Regards,
>>>>>>> Ishan
>>>>>>> 
>>>>>>> On Wed, 23 Aug, 2023, 5:05 pm Jan Høydahl, >> 
>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Following up on Ishan's proposed 8.11.3 release (
>>>>>>>> https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2
>> )
>>>>>>>> 
>>>>>>>> Does the Lucene project have any bugfix candidates for
>> backporting?
>>>>>>>> 
>>>>>>>> Ishan, are you still targeting September?
>>>>>>>> 
>>>>>>>> Jan
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya <
>>>>>>>> ichattopadhy...@gmail.com>:
>>>>>>>>> 
>>>>&

Re: [VOTE] Release Lucene 9.8.0 RC1

[Jan Høydahl]

Smoke tester only

SUCCESS! [1:22:37.441415]

+1 (binding)

Jan

> 22. sep. 2023 kl. 07:48 skrev Patrick Zhai :
> 
> Please vote for release candidate 1 for Lucene 9.8.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.8.0-RC1-rev-d914b3722bd5b8ef31ccf7e8ddc638a87fd648db
> 
> The vote will be open for at least 72 hours, as there's a weekend, the vote 
> will last until 2023-09-27 06:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (non-binding)

Re: 8.11.3 release

[Jan Høydahl]

Hi,

Following up on Ishan's proposed 8.11.3 release 
(https://lists.apache.org/thread/3xjtv1sxqx8f9nvhkc0cb90b2p76nfx2)

Does the Lucene project have any bugfix candidates for backporting?

Ishan, are you still targeting September? 

Jan


> 1. aug. 2023 kl. 14:57 skrev Ishan Chattopadhyaya :
> 
> Oh yes, good idea. Forgot about the split!
> 
> +Lucene Dev 
> 
> On Tue, 1 Aug, 2023, 6:17 pm Uwe Schindler,  wrote:
> 
>> Maybe ask on Lucene list, too, if there are some bug people like to have
>> fixed in Lucene.
>> 
>> Uwe
>> 
>> Am 01.08.2023 um 11:10 schrieb Ishan Chattopadhyaya:
>>> Hi all,
>>> There have been lots of bug fixes that have gone into 9x that should
>>> benefit all 8x users as well.
>>> I thought of volunteering for such a 8.x release based on this comment
>> [0].
>>> 
>>> Unless someone has any objections or concerns, can we tentatively plan
>> 1st
>>> September 2023 (1 month from now) as a tentative release for 8.11.3? I
>>> think we will get ample time to backport relevant fixes to 8x by then.
>>> 
>>> Best regards,
>>> Ishan
>>> 
>>> [0] -
>>> 
>> https://issues.apache.org/jira/browse/SOLR-16777?focusedCommentId=17742854=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17742854
>>> 
>> --
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 


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

Re: Lucene PMC Chair Greg Miller

[Jan Høydahl]

Thank you Bruno and Greg!

Jan

> 6. mar. 2023 kl. 18:15 skrev Bruno Roustant :
> 
> Hello Lucene developers,
> 
> Lucene Program Management Committee has elected a new chair, Greg Miller, and 
> the Board has approved.
> 
> Greg, thank you for stepping up, and congratulations!
> 
> 
> - Bruno


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

Re: Release wizard: generage asciidoc guide

[Jan Høydahl]

Hi,

It is just a convenience for generating a "print" version of the entire release 
process. It will generate an .adoc file and if  you have asciidoctor installed 
you will also get it converted to HTML.

Jan

> 31. jan. 2023 kl. 10:58 skrev Luca Cavanna :
> 
> Hi all,
> I was wondering what the " 6 - Generate Asciidoc guide for this
> release" step of the release wizard does. It failed for me yesterday
> and asking around I was not sure if it is a required step. Would love
> to clarify this and make adjustments if needed, so the next release
> manager does not have the same question.
> 
> Cheers
> Luca
> 
> -
> 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: [VOTE] Release Lucene 9.5.0 RC1

[Jan Høydahl]

+1

SUCCESS! [0:36:32.191785]

Jan

> 25. jan. 2023 kl. 19:43 skrev Luca Cavanna :
> 
> Please vote for release candidate 1 for Lucene 9.5.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.5.0-RC1-rev-13803aa6ea7fee91f798cfeded4296182ac43a21
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.5.0-RC1-rev-13803aa6ea7fee91f798cfeded4296182ac43a21
> 
> The vote will be open for at least 72 hours i.e. until 2023-01-28 19:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1

Re: [lucene] branch main updated: Prevent NPEs while still handling the polar case for horizontal planes right off the pole

[Jan Høydahl]

I’m not on Windows myself, but I think the trick is doing the git clone to the 
WSL file system. So you may have one checkout for use with windows and another 
for use within wsl.

And if you’re a CLI person, there’s a GitHub cli tool ‘hub’ that is handy: 
https://hub.github.com/

Jan Høydahl

> 17. nov. 2022 kl. 16:49 skrev Dawid Weiss :
> 
> I never used WSL but it does seem like the problem there:
> 
> "As you can tell from the comparison table above, the WSL 2
> architecture outperforms WSL 1 in several ways, with the exception of
> performance across OS file systems, which can be addressed by storing
> your project files on the same operating system as the tools you are
> running to work on the project."
> 
> https://learn.microsoft.com/en-us/windows/wsl/compare-versions
> 
> Dawid
> 
> 
>> On Thu, Nov 17, 2022 at 1:11 PM Robert Muir  wrote:
>> 
>> if your machine is really 12 cores and 64GB ram but is that slow, then
>> uninstall that windows shit immediately, that's horrible.
>> 
>>> On Thu, Nov 17, 2022 at 5:46 AM Karl Wright  wrote:
>>> 
>>> Thanks - the target I was using was the complete "build" target on the 
>>> whole project.  This will be a valuable improvement. ;-)
>>> 
>>> I have slow network here so it is possible that the entire build was slow 
>>> for that reason.  The machine is a new Dell laptop, 12 cores, 64GB memory, 
>>> but I am running under Windows Subsystem for Linux which is a bit slower 
>>> than native Ubuntu.  Still, the gradlew command you gave takes many minutes 
>>> (of which a sizable amount is spent in :gitStatus - more than 5 minutes 
>>> there alone).  Anything less than 10 minutes I deem acceptable, which this 
>>> doesn't quite manage, but I'll live.
>>> 
>>> Karl
>>> 
>>> 
>>> On Thu, Nov 17, 2022 at 5:06 AM Dawid Weiss  wrote:
>>>> 
>>>> 
>>>>> Thank you for the comment.
>>>> 
>>>> 
>>>> Sorry if it came out the wrong way - I certainly didn't mean it to be 
>>>> unkind.
>>>> 
>>>>> 
>>>>> It took me several days just to get things set up so I was able to commit 
>>>>> again, and I did this through command-line not github.
>>>> 
>>>> 
>>>> These things are not mutually exclusive - I work with command line as 
>>>> well. You just push to your own repository (or a branch, if you don't care 
>>>> to have your own fork on github) and then file a PR from there. If you're 
>>>> on a slower machine - this is even better since precommit checks run for 
>>>> you there.
>>>> 
>>>>> 
>>>>> The full gradlew script takes over 2 hours to run now so if there's a 
>>>>> faster target I can use to determine these things in advance I'd love to 
>>>>> know what it is.
>>>> 
>>>> 
>>>> Well, this is crazy long so I wonder what's happening. I'd love to help 
>>>> but it'd be good to know what machine this is (disk, cpu, memory?) and 
>>>> what the build command was. Without knowing these, I'd say - run the tests 
>>>> and checks for the module you've changed only, not for everything. How 
>>>> long does this take?
>>>> 
>>>> ./gradlew check -p lucene/spatial3d
>>>> 
>>>> It takes roughly 1 minute for me, including startup (after the daemon is 
>>>> running in the background, it's much faster).
>>>> 
>>>> There are some workflow examples/ hints I left here:
>>>> https://github.com/apache/lucene/blob/main/help/workflow.txt#L6-L22
>>>> 
>>>> Hope it helps,
>>>> Dawid
>> 
>> -
>> 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: [JENKINS] Lucene » Lucene-Check-9.4 - Build # 509 - Failure!

[Jan Høydahl]

That's a good question. The wizard already has a mapping from Solr version to 
Java version and a method to find correct java_home and java_cmd:
https://github.com/dweiss/lucene/blob/main/dev-tools/scripts/releaseWizard.py#L590:L600

So perhaps we need some logic to set correct JAVA_HOME and path for each 
command depending on branch?

Also the Java version for Lucene 10 (main) must be updated here 
https://github.com/dweiss/lucene/blob/main/dev-tools/scripts/releaseWizard.py#L69:L70

Jan

> 25. okt. 2022 kl. 10:49 skrev Dawid Weiss :
> 
> 
> I think the problem here is that at the point of running those commands I had 
> lost trust in the release wizard and I was running the commands manually.
> 
> Ok, that explains it. :)
>  
> One of the problems at the moment in the release wizard is that any step that 
> involves running a gradle task on main branch fails because it requires java 
> 17 and we run all commands with java 11. I think that should be addressed, 
> those steps were missing for the 9.4.0 release and I fixed them too. 
> 
> I'm not sure how to handle cross-major version releases with the release 
> wizard. Should the wizard/scripts from 9x be used (and not the main version)?
> 
> Dawid

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Jan Høydahl]

You'll not be able to create a GH issue with a script, on behalf of the 
original reporter.
Neither will you be able to add a GH issue comment impersonating the person who 
made the JIRA comment.
Rather, all issues and all comments would be made by the script/bot user, and 
you'd have to add in free-text information about reporter and commenter.
You may be able to assign an issue to the github-id of the original JIRA 
assignee though.

See 
https://stackoverflow.com/questions/36540508/github-api-possible-to-set-reporter-of-issue-to-another-user-when-creating-issu
 

 

I'm still against duplicating jira history over to GitHub. I think it will be a 
confusing mess and not worth the effort. The history split can be mitigated by 
documentation, and perhaps a search engine :)

If, however, experiments show that a quality migration is possible, then can we 
please open a separate git repo only for the historic issues? It is easy to 
search across two repos in GitHub, e.g. 
https://github.com/pulls?q=is%3Apr+is%3Aclosed+repo%3Aapache%2Flucene+repo%3Aapache%2Flucene-solr+wizard+
 

 

Jan

> 18. jun. 2022 kl. 21:48 skrev Robert Muir :
> 
> 
> 
> On Sat, Jun 18, 2022, 7:42 AM Tomoko Uchida  > wrote:
> User id mapping is an important consideration for me.
> 
> Can we find a mapping from Jira user id to GitHub account anywhere?
> 
> I think we would have to create it. But my hope would be that maybe 50-100 
> names would cover large majority of issues.
> Don't we have to gain the consent of each individual to map both accounts?
> 
> No, we don't have to ask permission to mention someone with an @username
> 
> 
> 2022年6月18日(土) 18:52 Robert Muir mailto:rcm...@gmail.com>>:
> >
> > I looked at some related projects on github:
> > https://github.com/Skraeda/jira-2-github 
> > 
> > Does the barebones basics but helps you think of the inputs: "username
> > mapping", "release -> milestone mapping", etc. Of course for a
> > username mapping, maybe its best to just handle the top 99% or so and
> > let the long-tail just come across as "full name". I also find plenty
> > of projects that convert "special jira language" to markdown, e.g.
> > https://github.com/catcombo/jira2markdown 
> > 
> > I'm not convinced conversion would be degraded, with a little bit of
> > thought into the conversion, I think it could actually be *better*.
> > github issues can do everything jira can, just without the fussy UI.
> > e.g. issues can have attachments (for all the patch files), and
> > attachment names can have duplicates. Issues can link to other issues,
> > commits, or PRs easily.
> >
> > It just depends on how much we want to invest into it. If we want to
> > really go whole-hog, then when we do the initial JIRA->issue
> > conversion, we should *save that mapping* as a .CSV file or similar.
> > Because later we could then use it to find/replace URLs in
> > Changes.txt, source code, benchmark annotations, etc etc. Let's at
> > least leave the possibility open to do that work as followup.
> >
> > I find the idea that we're stuck looking at JIRA forever ridiculous.
> >
> > On Sat, Jun 18, 2022 at 3:19 AM Dawid Weiss  > > wrote:
> > >
> > >
> > > I honestly don't know what can be done and what has to be sacrificed. I'm 
> > > pretty sure it'll be more difficult than svn->git conversion because more 
> > > factors are involved. One tough thing to somehow preserve may be user 
> > > names (reporters, etc.). I'm not sure how other projects dealt with that.
> > >
> > > Perhaps a way to do it incrementally would be to create a json/xml 
> > > (structured) dump of jira content and then write a converter into a 
> > > similar json/xml dump for importing into github. I remember it took many 
> > > iterations and trial and error for svn->git conversion to eventually 
> > > reach the final shape and it was simpler  and faster to do it locally.
> > >
> > > Dawid
> > >
> > > On Sat, Jun 18, 2022 at 8:59 AM Tomoko Uchida 
> > > mailto:tomoko.uchida.1...@gmail.com>> 
> > > wrote:
> > >>
> > >> I'll give it a try though, I'm really skeptical that it can be done
> > >> with a satisfactory level of quality (we want to "preserve" issue
> > >> history, not just to have shallow/degraded copies, right?), and the
> > >> migration will be significantly delayed to figure out the way to
> > >> properly moving all issues to GitHub.
> > >> if there is another way to bypass this challenge - please let me know.
> > >>
> > >> Tomoko
> > >>
> > >> 2022年6月18日(土) 15:44 Dawid Weiss  > >> >:
> > >>
> > >> >
> > >> >
> > >> > Hi Tomoko,
> > >> >
> > >> > I've added a few bullet 

Re: Deleting old RCs

[Jan Høydahl]

I think I saw the same during Solr 9 release, it was fixed in 
https://github.com/apache/solr/commit/d51355256e4adc4ff1a03022e61ae1911601ccb7 

 and may need backport.
There are also other fixes in Solr wizard that can be backported to Lucene, but 
I'm short on time before summer..

Jan

> 18. jun. 2022 kl. 00:58 skrev Houston Putman :
> 
> Definitely clean them up.
> 
> It should be a step in the release wizard when aborting the failed RC or 
> promoting the successful RC. (This is in the python code, not the yaml file.) 
> I know it is in Solr, but maybe that got broken in the lucene release wizard 
> after the split. Given the lucene-solr artifacts, maybe its just a messaging 
> issue in the release manager that needs to be fixed so that this step is 
> clearer.
> 
> - Houston
> 
> On Sat, Jun 18, 2022 at 12:32 AM Anshum Gupta  > wrote:
> I don't think we need them so it totally makes sense to clean them up.
> 
> On Fri, Jun 17, 2022 at 3:28 PM Mike Drob  > wrote:
> Can we delete all of these? Do we still need them? Is there any reason to 
> keep them? I guess they don't hurt anything by existing...
> 
> $ svn ls https://dist.apache.org/repos/dist/dev/lucene/ 
> 
> lucene-9.0.0-RC1-rev-903ee94dc50643299c15dfa954410f3ee4d62075/
> lucene-9.0.0-RC2-rev-95072f3b71e67e308d71a6149323bf7dd04c8f75/
> lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b/
> lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679/
> lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0/
> lucene-solr-7.3.0-RC1-reveb8a5a882f879a51389b5d43f74f3aceac9e68c9/
> lucene-solr-7.6.0-RC1-rev2d4435162774ad43b66ce0e7847bf8c1558e20a9/
> lucene-solr-7.7.3-RC1-rev1a0d2a901dfec93676b0fe8be425101ceb754b85/
> lucene-solr-8.1.0-RC1-reve5839fb416083fcdaeedfb1e329a9fdaa29fdc50/
> lucene-solr-8.3.0-RC1-revd796eca84dbabe3ae9b3c27afc01ef3bee35acb1/
> lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
> 
> Thanks,
> Mike
> 
> 
> -- 
> Anshum Gupta

Re: [RESULT] [VOTE] Migration to GitHub issue from Jira

[Jan Høydahl]

+1 for a manual approach

Over time the volume will gravitate to mostly GitHub issues. And JIRA will 
always remain as an archive, so nothing is lost. Devs can always peek into the 
list of open JIRAs any time and choose to start a PR for one. A slight 
disadvantage is of course that in the first year or two you need to look in 
both systems to get a full overview of all open issues. But auto migrating 
hundreds of abandoned JIRA issues to GitHub is no better imo.

Jan

> 15. jun. 2022 kl. 13:03 skrev Dawid Weiss :
> 
> 
> Maybe a 3rd option could be to only use GitHub for new issues by adding some 
> text to the Jira create issue dialog that says something like "JIRA is 
> deprecated, please use GitHub for new issues" to encourage users to create 
> new issues on GitHub instead of JIRA.
> 
> I was thinking this too, actually. It'd allow for a more graceful transition 
> period from one system to another. It'd also help keep cross-links (from 
> comments, etc.) in the old issues reference proper targets. And I don't see 
> many disadvantages - I imagine that folks who wish to revisit old(er) open 
> Jira issues and prefer GH can close the jira ticket as a duplicate and open a 
> new corresponding GH issue. Wouldn't this be easier (for you as well)? The 
> key change would be procedural -- allow pull requests and github issues as 
> first-class "change" tickets.
> 
> D.

Re: [VOTE] Release Lucene/Solr 8.11.2 RC2

[Jan Høydahl]

+1 (binding)

SUCCESS! [1:19:45.192785]

Jan

> 13. jun. 2022 kl. 21:05 skrev Mike Drob :
> 
> Please vote for release candidate 2 for Lucene/Solr 8.11.2
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.2-RC2-rev17dee71932c683e345508113523e764c3e4c80fa
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.2-RC2-rev17dee71932c683e345508113523e764c3e4c80fa
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2022-06-16 20:00 UTC
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 

Re: Welcome Greg Miller to the Lucene PMC

[Jan Høydahl]

Welcome Greg!

Jan

> 7. jun. 2022 kl. 08:36 skrev Adrien Grand :
> 
> I'm pleased to announce that Greg Miller has accepted an invitation to join 
> the Lucene PMC!
> 
> Congratulations Greg, and welcome aboard!
> 
> -- 
> Adrien


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

Re: Welcome Lu Xugang as Lucene committer

[Jan Høydahl]

Welcome and congratulations!

Jan

> 1. jun. 2022 kl. 09:07 skrev Adrien Grand :
> 
> I'm pleased to announce that Lu Xugang has accepted the PMC's
> invitation to become a committer.
> 
> Xugang, 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 Chris Hegarty as Lucene committer

[Jan Høydahl]

Welcome Chris!

Jan

> 1. jun. 2022 kl. 09:04 skrev Adrien Grand :
> 
> I'm pleased to announce that Chris Hegarty has accepted the PMC's
> invitation to become a committer.
> 
> Chris, 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: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Jan Høydahl]

+1 Approve (PMC)

I'm not worried about reliance on GitHub as it is already approved by ASF. This 
will lower the barrier to participation for new contributors.

- Jan

> 30. mai 2022 kl. 17:39 skrev Tomoko Uchida :
> 
> Hi everyone!
> 
> As we had previous discussion thread [1], I propose migration to GitHub issue 
> from Jira.
> It'd be technically possible (see [2] for details) and I think it'd be good 
> for the project - not only for welcoming new developers who are not familiar 
> with Jira, but also for improving the experiences of long-term 
> committers/contributors by consolidating the conversation platform.
> 
> You can see a short summary of the discussion, some stats on current Jira 
> issues, and a draft migration plan in [2].
> Please review [2] if you haven't seen it and vote for this proposal.
> 
> The vote will be open until 2022-06-06 16:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> *IMPORTANT NOTE*
> I set a local protocol for this vote.
> There are 95 committers on this project [3] - the vote will be effective if 
> it successfully gains more than 15% of voters (>= 15) from committers 
> (including PMC members). This means, that although only PMC member votes are 
> counted for the final result, the votes from all committers are important to 
> make the vote result effective.
> 
> If there are less than 15 votes at 2022-06-06 16:00 UTC, I will expand the 
> term to 2022-06-13 16:00 UTC. If this fails to get sufficient voters after 
> the expanded time limit, I'll cancel this vote regardless of the result.
> But why do I set such an extra bar? My fear is that if such things are 
> decided by the opinions of a few members, the result shouldn't yield a good 
> outcome for the future. It isn't my goal to just pass the vote [4].
> 
> [1] https://lists.apache.org/thread/78wj0vll73sct065m5jjm4z8gqb5yffk 
> 
> [2] https://issues.apache.org/jira/browse/LUCENE-10557 
> 
> [3] https://projects.apache.org/committee.html?lucene 
> 
> [4] I'm sorry for being overly cautious, but I have never met in person or 
> virtually any of the committers (with a very few exceptions), therefore 
> cannot assess if the vote result is reliable or not unless there is certain 
> explicit feedback.
> 
> Tomoko

Re: Bugfix release Lucene/Solr 8.11.2

[Jan Høydahl]

I bumped Jackson in https://issues.apache.org/jira/browse/SOLR-16213 
<https://issues.apache.org/jira/browse/SOLR-16213> and also backported to 8_11. 
Wdyt?

Jan

> 18. mai 2022 kl. 15:22 skrev Gus Heck :
> 
> SOLR-16194 is in and ported to 8.11,.2
> 
> On Wed, May 18, 2022 at 7:12 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> I was pinged on https://issues.apache.org/jira/browse/SOLR-16019 
> <https://issues.apache.org/jira/browse/SOLR-16019> because I have an 
> in-flight PR with a backport. I'll complete and merge that PR.
> 
> Jan
> 
> 
>> 13. mai 2022 kl. 01:03 skrev Mike Drob > <mailto:md...@mdrob.com>>:
>> 
>> To: dev@lucene, dev@solr
>> 
>> NOTICE:
>> 
>> I am planning on preparing a bugfix release from branch branch_8_11 (likely 
>> mid next week)
>> 
>> Please observe the normal rules for committing to this branch:
>> 
>> * Before committing to the branch, reply to this thread and argue
>>   why the fix needs backporting and how long it will take.
>> ** If you're backporting stuff this week still or over the weekend, then skip
>> the bit about how long it will take.
>> * All issues accepted for backporting should be marked with 8.11.2
>>   in JIRA, and issues that should delay the release must be marked as Blocker
>> * All patches that are intended for the branch should first be committed
>>   to the unstable branch, merged into the stable branch, and then into
>>   the current release branch.
>> * Only Jira issues with Fix version 8.11.2 and priority "Blocker" will delay
>>   a release candidate build.
>> 
>> Also, please observe that since 9.0 already exists, there cannot be any 
>> index format breaking changes. It really should only be bug fixes that have 
>> already been verified on the 9x branch.
>> 
>> Thanks,
>> Mike
> 
> 
> 
> -- 
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)

Re: [VOTE] Release Lucene 9.2.0 RC2

[Jan Høydahl]

+1

SUCCESS! [1:13:38.226868]

Jan

> 19. mai 2022 kl. 17:16 skrev Alan Woodward :
> 
> Please vote for release candidate 2 for Lucene 9.2.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC2-rev-ba8c3a806ada3d7b3c34d408e449a92376a8481b
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC2-rev-ba8c3a806ada3d7b3c34d408e449a92376a8481b
> 
> The vote will be open until 2022-05-23 16:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> -
> 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: Bugfix release Lucene/Solr 8.11.2

[Jan Høydahl]

I was pinged on https://issues.apache.org/jira/browse/SOLR-16019 
 because I have an in-flight 
PR with a backport. I'll complete and merge that PR.

Jan


> 13. mai 2022 kl. 01:03 skrev Mike Drob :
> 
> To: dev@lucene, dev@solr
> 
> NOTICE:
> 
> I am planning on preparing a bugfix release from branch branch_8_11 (likely 
> mid next week)
> 
> Please observe the normal rules for committing to this branch:
> 
> * Before committing to the branch, reply to this thread and argue
>   why the fix needs backporting and how long it will take.
> ** If you're backporting stuff this week still or over the weekend, then skip
> the bit about how long it will take.
> * All issues accepted for backporting should be marked with 8.11.2
>   in JIRA, and issues that should delay the release must be marked as Blocker
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Only Jira issues with Fix version 8.11.2 and priority "Blocker" will delay
>   a release candidate build.
> 
> Also, please observe that since 9.0 already exists, there cannot be any index 
> format breaking changes. It really should only be bug fixes that have already 
> been verified on the 9x branch.
> 
> Thanks,
> Mike

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Jan Høydahl]

For code changes, patch files in Jira used to be the only option. Over the 
years, this is almost completely replaced by PRs, but we still leave the door 
open for patch in JIRA.
We could apply the same principle here: Don't shut down JIRA, but change 
documentation so that GitHub issues is documented first. A contributor who for 
some reason is prohibited to use a GitHub account can then use the JIRA+patch 
workflow and CHANGES.txt will record the JIRA issue, in-between all the 
github-issues. BWT: All issues, both in JIRA and GitHub are readable to the 
public without a user account.

Jan

> 6. mai 2022 kl. 05:15 skrev Tomoko Uchida :
> 
> Hi Yuting,
> thanks for your feedback.
> For your information, we have a general issue to improve our contribution 
> workflow: LUCENE-10543 , 
> and this is actually a sub-task of it.
> You and anyone can contribute to it by leaving comments, creating 
> documentation or instruction for developers, or whatever else (if you'd 
> like!).
> 
> I'll try to keep this thread a safe place for everyone though, I'd especially 
> appreciate feedback from newcomers like Vigya and Yuting, since I understand 
> and remember it is more difficult (and sometimes fearful) to join discussions 
> for new developers than long-time contributors.
> 
> Tomoko
> 
> 
> 2022年5月6日(金) 11:16 Yuti G mailto:gan.y...@gmail.com>>:
> Hi Tomoko,
> 
> Thanks for raising this discussion! 
> 
> As a new member of the Lucene community, I'm also confused by the input 
> components when creating a Jira issue. I struggled with previewing my text 
> and had to edit it after creating a Jira issue or a comment, and I just found 
> that each re-edit would send an email notification to the list 
> 
> I only used the GitHub issue system on a small team scale and I am getting 
> familiar with Jira now. It would be very helpful if we can create a clear 
> instruction/guide for new developers on how to create an issue no matter 
> which system we choose in the future.
> 
> Best,
> Yuting
> 
> On Thu, May 5, 2022 at 6:00 PM Tomoko Uchida  > wrote:
> I'm not going to thoroughly discuss the migration path from Jira to GitHub 
> here, but generally, the rough image in my mind is the same as Jan described 
> -  "Milestone" for version tracking, and "labels" for other purposes (issue 
> types, component types, etc.).
> 
> As for the proposal of in-house GitLab, it could be an option (if UI/UX is 
> the only problem) but I don't think it's feasible.
> We need high availability platform and we don't have machine/human resources 
> to operate such mission-critical in-house service on our own. And, even if 
> it's possible, we still have to switch between two platforms - it doesn't 
> solve my problem.
> 
> > That's precisely the crux of the disagreement: I want to be able to 
> > register 
> > an account at Apache and *not* GitHub and still be able to contribute.
> 
> > Is the original Jira -> GitHub move just a change of defaults or are we, 
> > once moved to GitHub, not letting people use Jira at all anymore ?
> 
> Interesting point - is there anyone else who doesn't have or use GitHub 
> account and *won't sign up or sign in for it* ?
> 
> Tomoko
> 
> 
> 2022年5月6日(金) 7:04 Uwe Schindler mailto:u...@thetaphi.de>>:
> I agree with that.
> 
> What annoys me is that I have to open a fake issue in Jira. I think we should 
> allow people to open GitHub PR or issues. It gets reported also to mailing 
> list. If a Lucene committer does not want to use GitHub, heshe can just 
> download the PR as patch file and apply. Same for issues: all is mirrored to 
> mailing list.
> 
> If our users want to open issues they should do what they prefer.
> 
> Uwe
> 
> Am 5. Mai 2022 21:50:58 UTC schrieb Michael Sokolov  >:
> Is the original Jira -> GitHub move just a change of defaults or are we,
> once moved to GitHub, not letting people use Jira at all anymore ?
> 
> Nothing has been decided - it's all open for debate.
> 
> I just want to re-state the idea (at least as I heard it) behind this
> proposed move is to make contributing more accessible.
> 
> As for github banning people, just google "github banning" and you
> will see that people have been banned for a variety of reasons.
> 
> I don't know if the risk of that outweighs the inconvenience of JIRA
> for the new developer.
> 
> Please note that the primary avenue for contributions today *is
> already github*. So far we have not had any issues with people being
> banned, and if that were to happen, we still accept patch files in
> JIRA. We have had these two mechanisms in place for quite a while now
> and both are in active use.
> 
> But this proposal is about issue tracking anyway: I just point out
> that we already rely on github in spite of its shortcomings.
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For 

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Jan Høydahl]

ASF has officially blessed use of github issues as alternative to Jira. They 
are not going to setup a private GitLab or tool X. While GitLab is nice, I 
don't think the main intention with the proposal was to inroduce yet another 
platform where contributors need to register an account and learn the UI :)


GitHub issues versions are tracked in "Milestones" - 
https://docs.github.com/en/issues/using-labels-and-milestones-to-track-work/about-milestones
 

 

See example from solr-operator. These issues or PRs were released in v0.5.1: 
https://github.com/apache/solr-operator/milestone/8?closed=1 

Labels are also very flexibl.

Jan

> 5. mai 2022 kl. 22:18 skrev David Smiley :
> 
> Is anyone familiar with using GitHub (or maybe GitLab I suppose) for tracking 
> metadata about the issue -- something JIRA excels at?  For example the 
> version of our project that a given PR is released in -- aka the JIRA "Fix 
> Version"?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Wed, May 4, 2022 at 10:24 PM Tomoko Uchida  > wrote:
> Hello everyone!
> 
> Recently, we relaxed the requirement for creating a Jira issue when opening a 
> pull request (LUCENE-10545 
> ).
> 
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
> for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557 
> 
> 
> According to the INFRA issue for the RocketMQ project (Michael McCandless 
> gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote 
> result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702 
> 
> 
> Eventually, we'd need a formal vote, but before that, I'd like to hear 
> general opinions/thoughts (or feelings) on this topic from developers.
> 
> In brief, I think it'd be technically possible and also be good for the 
> project - not only for welcoming new developers who are not familiar with 
> Jira, but also for improving the experiences of long-term contributors by 
> consolidating the conversation platform. 
> It'll need some administrative work though, I'm willing to work for it if we 
> reach an agreement.
> 
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
> don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
> decide the migration will be good for us, then we can try to figure out a 
> reasonable solution for technical/administrative matters. 
> 
> I may be too optimistic about it; but - a bit of stupidness will be needed to 
> start such a move, and I'm serious about this proposal :)
> 
> Thanks and regards,
> Tomoko

Re: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Jan Høydahl]

Given how JIRA has become a monster of a product with different markup syntax 
for each version, and bugs everywhere (does not even work on mobile), I'm no 
longer the JIRA fan I once was.

In Solr we already use github issues for the Solr-Operator sub project 
https://github.com/apache/solr-operator/issues 
 and I believe it has worked 
well. Of course excellent integration with PRs :)
In earlier discussions on this topic, the idea has been shot down with the 
argument of split bug history and migration challenges. But I think you are 
wise to delay the HOW discussion for now.
This discussion should also not be about politics. Some may be opposed to 
Microsoft and GitHub, but as long as the ASF has officially blessed github as 
an official option, i'ts not a very constructive discussion.
The most important decision point on my part is perception by new / young 
users. Look at OpenOffice, they have remained on Bugzilla - are you compelled 
to contribute? :)

Jan

> 5. mai 2022 kl. 04:23 skrev Tomoko Uchida :
> 
> Hello everyone!
> 
> Recently, we relaxed the requirement for creating a Jira issue when opening a 
> pull request (LUCENE-10545 
> ).
> 
> As the next and bigger (perhaps ambitious) step, I opened a rough proposal 
> for migration to GitHub issue from Jira.
> https://issues.apache.org/jira/browse/LUCENE-10557 
> 
> 
> According to the INFRA issue for the RocketMQ project (Michael McCandless 
> gave the pointer in a comment on the issue; thanks!), a PMC agreement or Vote 
> result is needed for the decision.
> https://issues.apache.org/jira/browse/INFRA-15702 
> 
> 
> Eventually, we'd need a formal vote, but before that, I'd like to hear 
> general opinions/thoughts (or feelings) on this topic from developers.
> 
> In brief, I think it'd be technically possible and also be good for the 
> project - not only for welcoming new developers who are not familiar with 
> Jira, but also for improving the experiences of long-term contributors by 
> consolidating the conversation platform. 
> It'll need some administrative work though, I'm willing to work for it if we 
> reach an agreement.
> 
> Please note that:
> * This is not a VOTE. Simple vote-style feedback (+/- 1) is welcome, but we 
> don't aim to reach a conclusion in this thread.
> * Let's not discuss "how to migrate existing Jira issues" for now. Once we 
> decide the migration will be good for us, then we can try to figure out a 
> reasonable solution for technical/administrative matters. 
> 
> I may be too optimistic about it; but - a bit of stupidness will be needed to 
> start such a move, and I'm serious about this proposal :)
> 
> Thanks and regards,
> Tomoko

Re: Release notes draft for Apache Solr 9.0

[Jan Høydahl]

Thanks Anshum,

I'm moving this mail thread from the Lucene dev-list to the Solr dev-list :)

I think, as this is a major release, we should say explicitly in the 
release-notes something like:
"This is a major-version release with several features removed and other major, 
breaking changes. Please consult the Release Guide chapter "Solr Upgrade Notes" 
(link) when planning an upgrade".

I'll add some other comments inline in Confluence..

Jan

> 28. mar. 2022 kl. 04:15 skrev Anshum Gupta :
> 
> Hi everyone,
> 
> Please find the initial draft of the release notes for Solr 9.0 here: 
> https://cwiki.apache.org/confluence/x/jL-kCw 
> 
> 
> Please let me know if you need me to update/add something, or feel free to do 
> so yourself.
> 
> -- 
> Anshum Gupta

Re: Lucene PMC Chair Bruno Roustant

[Jan Høydahl]

Congrats Bruno, and thank you Michael for a steady hand on the tiller last term!

Jan

> 23. mar. 2022 kl. 14:02 skrev Michael Sokolov :
> 
> Hello, Lucene developers. Lucene Program Management Committee has
> elected a new chair, Bruno Roustant, and the Board has approved.
> Bruno, thank you for stepping up, and congratulations!
> 
> -Mike
> 
> -
> 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: [VOTE] Release Lucene 9.1.0 RC1

[Jan Høydahl]

Ah, sure, makes sense. I'm trying to get smoketester to run in Jenkins for Solr 
as well, so struggling with some of the same issues there.

Jan

> 15. mar. 2022 kl. 13:41 skrev Uwe Schindler :
> 
> That does not help for smoke tester  It has a hardcoded command line.
>  
> I figured out how to do it. You can passe xtra args at end of smoke tester 
> command line.
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>  
> From: Jan Høydahl  
> Sent: Tuesday, March 15, 2022 1:33 PM
> To: Lucene Dev 
> Subject: Re: [VOTE] Release Lucene 9.1.0 RC1
>  
> Click the "Advanced" button for the "Invoke Gradle script" task, and you get 
> the chance to pass "Project properties" as well as "Switches" and "System 
> properties".
>  
> Jan
> 
> 
>> 15. mar. 2022 kl. 13:12 skrev Uwe Schindler > <mailto:u...@thetaphi.de>>:
>>  
>> Hi,
>>  
>> I have a problem with running Smoketester (like on every release) with 
>> Policeman Jenkins. There’s a job to execute smoke tester and it takes as 
>> parameters the branch name and the version number (incl. hash).
>>  
>> This worked for 9.0, but with 9.1 it hangs endless and does not finish:
>> make sure no JARs/WARs in src dist...
>> run "./gradlew --no-daemon check -p lucene/documentation"
>> run tests w/ Java 11 and testArgs='-Dtests.nightly=true 
>> -Dtests.badapples=false '...
>>  
>> After that nothing happens anymore. The CPUs use a lot at beginning, but it 
>> hangs at end with one cpu core 100% occupied. From the parameters it enabled 
>> -Dtests.nightly=true. Is this wanted or somehow coming from environment.
>>  
>> There is one important thing to note: Jenkins has a gradle.properties with 
>> the following lines (similar on ASF jenkins):
>> org.gradle.parallel=true
>> org.gradle.priority=normal
>> org.gradle.daemon=false
>>  
>> org.gradle.workers.max=6
>> tests.jvms=6
>> tests.multiplier=3
>>  
>> The “tests.multiplier=3” looks like the problem. I have no idea how to stop 
>> this, because the gradle properties are injected through the config file. Is 
>> there a way to pass custom parameters. Maybe we should add 
>> “-Dtests.multiplier=1” to the command line. At least in combination with 
>> “-Dtests.nightly=true” this seems to break (see ASF Jenkins which has most 
>> nightly jobs taking forever)
>>  
>> Does anybody complain if I commit a -Dtests.multiplier=1 to the 9.1 branch?
>>  
>> Uwe
>>  
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>  
>> From: Julie Tibshirani mailto:juliet...@gmail.com>> 
>> Sent: Tuesday, March 15, 2022 1:57 AM
>> To: dev@lucene.apache.org <mailto:dev@lucene.apache.org>
>> Subject: [VOTE] Release Lucene 9.1.0 RC1
>>  
>> Please vote for release candidate 1 for Lucene 9.1.0
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679
>>  
>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679>
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679
>>  
>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679>
>> 
>> The vote will be open for at least 72 hours i.e. until 2022-03-18 00:00 UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1.
>>  
>> Julie

Re: [VOTE] Release Lucene 9.1.0 RC1

[Jan Høydahl]

Click the "Advanced" button for the "Invoke Gradle script" task, and you get 
the chance to pass "Project properties" as well as "Switches" and "System 
properties".

Jan

> 15. mar. 2022 kl. 13:12 skrev Uwe Schindler :
> 
> Hi,
>  
> I have a problem with running Smoketester (like on every release) with 
> Policeman Jenkins. There’s a job to execute smoke tester and it takes as 
> parameters the branch name and the version number (incl. hash).
>  
> This worked for 9.0, but with 9.1 it hangs endless and does not finish:
> make sure no JARs/WARs in src dist...
> run "./gradlew --no-daemon check -p lucene/documentation"
> run tests w/ Java 11 and testArgs='-Dtests.nightly=true 
> -Dtests.badapples=false '...
>  
> After that nothing happens anymore. The CPUs use a lot at beginning, but it 
> hangs at end with one cpu core 100% occupied. From the parameters it enabled 
> -Dtests.nightly=true. Is this wanted or somehow coming from environment.
>  
> There is one important thing to note: Jenkins has a gradle.properties with 
> the following lines (similar on ASF jenkins):
> org.gradle.parallel=true
> org.gradle.priority=normal
> org.gradle.daemon=false
>  
> org.gradle.workers.max=6
> tests.jvms=6
> tests.multiplier=3
>  
> The “tests.multiplier=3” looks like the problem. I have no idea how to stop 
> this, because the gradle properties are injected through the config file. Is 
> there a way to pass custom parameters. Maybe we should add 
> “-Dtests.multiplier=1” to the command line. At least in combination with 
> “-Dtests.nightly=true” this seems to break (see ASF Jenkins which has most 
> nightly jobs taking forever)
>  
> Does anybody complain if I commit a -Dtests.multiplier=1 to the 9.1 branch?
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Julie Tibshirani  
> Sent: Tuesday, March 15, 2022 1:57 AM
> To: dev@lucene.apache.org
> Subject: [VOTE] Release Lucene 9.1.0 RC1
>  
> Please vote for release candidate 1 for Lucene 9.1.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC1-rev-a6114b532a273e370528675d551d3ddfa02f4679
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2022-03-18 00:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1.
>  
> Julie

Re: Welcome Guo Feng as Lucene committer

[Jan Høydahl]

Welcome Feng!

Jan

> 25. jan. 2022 kl. 10:09 skrev Adrien Grand :
> 
> I'm pleased to announce that Guo Feng has accepted the PMC's
> invitation to become a committer.
> 
> Feng, 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: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Jan Høydahl]

Welcome Patrick!

Jan

> 19. des. 2021 kl. 10:11 skrev Dawid Weiss :
> 
> Hello everyone!
> 
> Please welcome Haoyu Zhai as the latest Lucene committer. You may also
> know Haoyu as Patrick - this is perhaps his kind gesture to those of
> us whose tongues are less flexible in pronouncing difficult first
> names. :)
> 
> It's a tradition to briefly introduce yourself to the group, Patrick.
> Welcome and thank you!
> 
> Dawid
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: Log4j < 2.15.0 may still be vulnerable even if -Dlog4j2.formatMsgNoLookups=true is set

[Jan Høydahl]

We make edits to the log4j advisory almost daily, see 
https://github.com/apache/solr-site/commits/e10a6a9fe0eed8dcba3ad1a076c8208e014e76ff/content/solr/security/2021-12-10-cve-2021-44228.md
I wonder if we should include a "Revision history" paragraph in the advisory 
for transparency?

Jan

> 15. des. 2021 kl. 19:09 skrev Uwe Schindler :
> 
> Hi all, I prepared a PR about the followup CVE-2021-45046: 
> https://github.com/apache/solr-site/pull/59 
> 
>  
> Please verify and make suggestion. I will merge this into main/production 
> later.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Uwe Schindler mailto:u...@thetaphi.de>> 
> Sent: Wednesday, December 15, 2021 3:31 PM
> To: 'dev@lucene.apache.org ' 
> mailto:dev@lucene.apache.org>>
> Subject: RE: Log4j < 2.15.0 may still be vulnerable even if 
> -Dlog4j2.formatMsgNoLookups=true is set
>  
> We should add this to the webpage. Another one asked on the security mailing 
> list.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de 
> eMail: u...@thetaphi.de 
>  
> From: Gus Heck mailto:gus.h...@gmail.com>> 
> Sent: Wednesday, December 15, 2021 12:39 AM
> To: dev mailto:dev@lucene.apache.org>>
> Subject: Re: Log4j < 2.15.0 may still be vulnerable even if 
> -Dlog4j2.formatMsgNoLookups=true is set
>  
> Perhaps we could tweak it to say that the system property fix is sufficient 
> *for Solr* (i.e. not imply that it is a valid work around for all cases)
>  
> On Tue, Dec 14, 2021 at 6:20 PM Uwe Schindler  > wrote:
>> The other attack vectors are also not possible with Solr:
>> 
>> - Logger.printf("%s", userInput) is not used
>> - custom message factory is not used
>> 
>> Uwe
>> 
>> Am 14. Dezember 2021 22:59:26 UTC schrieb Uwe Schindler > >:
>>> It is still a valid mitigation.
>>> 
>>> Mike Drobban I explained it. MDC is the other attack vector and that's not 
>>> an issue with Solr.
>>> 
>>> Please accept this, just because the documentation of log4j changes, 
>>> there's no additional risk. We may update the mitigation to mention that in 
>>> Solr's case the system property is fine.
>>> 
>>> Uwe
>>> 
>>> Am 14. Dezember 2021 22:52:29 UTC schrieb solr >> >:
 Ok.
 
 But FTR - apache/log4j has discredited just setting the system property as 
 a mitigation measure, so I still think the SOLR security-page should be 
 changed to not list this as a valid mitigation:
 
 https://logging.apache.org/log4j/2.x/security.html 
 
 "Older (discredited) mitigation measures
 
 This page previously mentioned other mitigation measures, but we 
 discovered that these measures only limit exposure while leaving some 
 attack vectors open.
 
 Other insufficient mitigation measures are: setting system property 
 log4j2.formatMsgNoLookups or environment variable 
 LOG4J_FORMAT_MSG_NO_LOOKUPS to true for releases >= 2.10, or modifying the 
 logging configuration to disable message lookups with %m{nolookups}, 
 %msg{nolookups} or %message{nolookups} for releases >= 2.7 and <= 2.14.1.
 “
 
 Regards,
 
 
 Fredrik
 
 
 --
 Fredrik Rødland   Cell:+47 99 21 98 17
 Maisen Pedersens vei 1Twitter: @fredrikr
 NO-1363 Høvik, NORWAY flickr:  http://www.flickr.com/fmmr/ 
 
 http://rodland.no  about.me 
  http://about.me/fmr 
 
> On 14 Dec 2021, at 23:44, Mike Drob  > wrote:
> 
> The MDC Patterns used by solr are for the collection, shard, replica, 
> core and node names, and a potential trace id. All of those are 
> restricted to alphanumeric, no special characters like $ or { needed for 
> the injection. And trying to access a collection that didn’t exist 
> Returns 404 without logging.
> 
> Upgrading is always going to be more complete, but I think we’re still ok 
> for now, at least until the next iteration of this attack surfaces.
> 
> 
> 
> On Tue, Dec 14, 2021 at 3:37 PM solr  > wrote:
> Only setting -Dlog4j2.formatMsgNoLookups=true might not be enough to 
> mitigate the log4j vulnerability.
> 
> See https://github.com/kmindi/log4shell-vulnerable-app 
> 
> “So even with LOG4J_FORMAT_MSG_NO_LOOKUPS true version 2.14.1 of log4j is 
> vulnerable when using ThreadContextMap in PatternLayout.”
> 
> 

[ANNOUNCE] Apache Lucene 8.11.1 released

[Jan Høydahl]

The Lucene PMC is pleased to announce the release of Apache Lucene 8.11.1.

Apache Lucene is a high-performance, full-featured text search engine library 
written entirely in Java. It is a technology suitable for nearly any 
application that requires full-text search, especially cross-platform.

This release contains one bug fix. The release is available for immediate 
download at:

   https://lucene.apache.org/core/downloads.html

Lucene 8.11.1 Release Highlights:

 * Log4j is upgraded to v2.16.0 to mitigate CVE-2021-44228 (for Luke users)

Re: [JENKINS] Lucene » Lucene-NightlyTests-9.0 - Build # 45 - Failure!

[Jan Høydahl]

Yep, I think it is a bad java11 upgrade on the jenkins server. All builds have 
been failing for a long time

Jan

> 17. des. 2021 kl. 13:08 skrev Dawid Weiss :
> 
> This looks like the binary of java is broken somehow.
> 
> On Fri, Dec 17, 2021 at 1:00 PM Apache Jenkins Server
>  wrote:
>> 
>> Build: 
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-NightlyTests-9.0/45/
>> 
>> No tests ran.
>> 
>> Build Log:
>> [...truncated 86 lines...]
>> ERROR: Step ‘Publish JUnit test result report’ failed: No test report files 
>> were found. Configuration error?
>> Email was triggered for: Failure - Any
>> Sending email for trigger: Failure - Any
>> 
>> -
>> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: builds-h...@lucene.apache.org
> 
> -
> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
> For additional commands, e-mail: builds-h...@lucene.apache.org
> 


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

[RESULT] [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

It's NOT been >72h since the vote was initiated, but consensus among at least 5 
PMC members to release early as an exception due to the log4j fix.
The result is:

+1  13  (12 binding)
 0  0
-1  0

This vote has PASSED 

Counted votes are: janhoy, rmuir, thelabdude, mdrob, ishan, mikemccand, 
uschindler, dsmiley, gus, houston, anshum, atri, dweiss

> 16. des. 2021 kl. 08:58 skrev Jan Høydahl :
> 
> Thanks all, I'll close the vote now and start publishing the release...
> 
> If you're a PMC member who planned to vote, but have not yet done so, there 
> is still value in expressing your vote in this thread, further validating the 
> release. I'll tally the final count tomorrow as well, for the record.
> 
> Jan
> 
>> 16. des. 2021 kl. 01:39 skrev Mike Drob > <mailto:md...@apache.org>>:
>> 
>> Fast track please
>> 
>> On Wed, Dec 15, 2021 at 6:34 PM Gus Heck > <mailto:gus.h...@gmail.com>> wrote:
>> fast track please :)
>> 
>> On Wed, Dec 15, 2021 at 7:23 PM Anshum Gupta > <mailto:ans...@anshumgupta.net>> wrote:
>> Fast-track please :) 
>> 
>> On Wed, Dec 15, 2021 at 4:19 PM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> Given the votes so far (11 binding +1) I'm also positive to publish 
>> tomorrow, and not wait for Friday.
>> The release voting rules are three or more +1 votes and more +1 votes than 
>> -1 votes, so for the vote to fail we'd need more than 11 -1's from now :)
>> 
>> If I see at least 3 more of you in favor (reply with "FAST-TRACK PLEASE") 
>> and no justified vetoes, then I can make it happen on Thursday afternoon UTC!
>> 
>> Jan
>> 
>>> 15. des. 2021 kl. 22:57 skrev Ishan Chattopadhyaya 
>>> mailto:ichattopadhy...@gmail.com>>:
>>> 
>>> I think we should publish, release and announce asap, not waiting for 72h 
>>> or the MVN propogation.
>>> 
>>> On Thu, 16 Dec, 2021, 2:40 am Anshum Gupta, >> <mailto:ans...@anshumgupta.net>> wrote:
>>> +1 (binding)
>>> 
>>> Smoke tester is happy.
>>> 
>>> SUCCESS! [1:03:13.162577]
>>> 
>>> Also tested out a sample search/indexing app.
>>> 
>>> On Tue, Dec 14, 2021 at 6:36 AM Jan Høydahl >> <mailto:jan@cominvent.com>> wrote:
>>> Please vote for release candidate 1 for Lucene/Solr 8.11.1
>>> 
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>>>  
>>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
>>> 
>>> You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
>>> with this command:
>>> 
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>>>  
>>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
>>> 
>>> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
>>> 
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>> 
>>> Here is my +1
>>> 
>>> SUCCESS! [0:54:56.979538]
>>> 
>>> NOTE: You must run the smoke tester from latest commit on branch_8_11, 
>>> since my surname contains a unicode-character, needing a fix in the gpg 
>>> command ran by the smoketester.
>>> -
>>> 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>
>>> 
>>> 
>>> 
>>> -- 
>>> Anshum Gupta
>> 
>> 
>> 
>> -- 
>> Anshum Gupta
>> 
>> 
>> -- 
>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
>> http://www.the111shift.com <http://www.the111shift.com/> (play)
> 

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

Thanks all, I'll close the vote now and start publishing the release...

If you're a PMC member who planned to vote, but have not yet done so, there is 
still value in expressing your vote in this thread, further validating the 
release. I'll tally the final count tomorrow as well, for the record.

Jan

> 16. des. 2021 kl. 01:39 skrev Mike Drob :
> 
> Fast track please
> 
> On Wed, Dec 15, 2021 at 6:34 PM Gus Heck  <mailto:gus.h...@gmail.com>> wrote:
> fast track please :)
> 
> On Wed, Dec 15, 2021 at 7:23 PM Anshum Gupta  <mailto:ans...@anshumgupta.net>> wrote:
> Fast-track please :) 
> 
> On Wed, Dec 15, 2021 at 4:19 PM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> Given the votes so far (11 binding +1) I'm also positive to publish tomorrow, 
> and not wait for Friday.
> The release voting rules are three or more +1 votes and more +1 votes than -1 
> votes, so for the vote to fail we'd need more than 11 -1's from now :)
> 
> If I see at least 3 more of you in favor (reply with "FAST-TRACK PLEASE") and 
> no justified vetoes, then I can make it happen on Thursday afternoon UTC!
> 
> Jan
> 
>> 15. des. 2021 kl. 22:57 skrev Ishan Chattopadhyaya 
>> mailto:ichattopadhy...@gmail.com>>:
>> 
>> I think we should publish, release and announce asap, not waiting for 72h or 
>> the MVN propogation.
>> 
>> On Thu, 16 Dec, 2021, 2:40 am Anshum Gupta, > <mailto:ans...@anshumgupta.net>> wrote:
>> +1 (binding)
>> 
>> Smoke tester is happy.
>> 
>> SUCCESS! [1:03:13.162577]
>> 
>> Also tested out a sample search/indexing app.
>> 
>> On Tue, Dec 14, 2021 at 6:36 AM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> Please vote for release candidate 1 for Lucene/Solr 8.11.1
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>>  
>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
>> 
>> You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
>> with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>>  
>> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
>> 
>> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1
>> 
>> SUCCESS! [0:54:56.979538]
>> 
>> NOTE: You must run the smoke tester from latest commit on branch_8_11, since 
>> my surname contains a unicode-character, needing a fix in the gpg command 
>> ran by the smoketester.
>> -
>> 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>
>> 
>> 
>> 
>> -- 
>> Anshum Gupta
> 
> 
> 
> -- 
> Anshum Gupta
> 
> 
> -- 
> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work)
> http://www.the111shift.com <http://www.the111shift.com/> (play)

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

Given the votes so far (11 binding +1) I'm also positive to publish tomorrow, 
and not wait for Friday.
The release voting rules are three or more +1 votes and more +1 votes than -1 
votes, so for the vote to fail we'd need more than 11 -1's from now :)

If I see at least 3 more of you in favor (reply with "FAST-TRACK PLEASE") and 
no justified vetoes, then I can make it happen on Thursday afternoon UTC!

Jan

> 15. des. 2021 kl. 22:57 skrev Ishan Chattopadhyaya 
> :
> 
> I think we should publish, release and announce asap, not waiting for 72h or 
> the MVN propogation.
> 
> On Thu, 16 Dec, 2021, 2:40 am Anshum Gupta,  <mailto:ans...@anshumgupta.net>> wrote:
> +1 (binding)
> 
> Smoke tester is happy.
> 
> SUCCESS! [1:03:13.162577]
> 
> Also tested out a sample search/indexing app.
> 
> On Tue, Dec 14, 2021 at 6:36 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> Please vote for release candidate 1 for Lucene/Solr 8.11.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
> 
> You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
> with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
>  
> <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
> 
> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [0:54:56.979538]
> 
> NOTE: You must run the smoke tester from latest commit on branch_8_11, since 
> my surname contains a unicode-character, needing a fix in the gpg command ran 
> by the smoketester.
> -
> 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>
> 
> 
> 
> -- 
> Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

I think ASF allows exception to the 72h voting rule for urgent fixes. The 
current vote result is 7 "+1" and no "-1". So if we figure out how to trigger 
that exception we could push it e.g. tomorrow instad of Friday?

Jan

> 15. des. 2021 kl. 15:29 skrev Uwe Schindler :
> 
> Hi,
> 
> Policeman Jenkins tested the relaese with Smoketester:
> 
> SUCCESS! [1:28:23.237262]
> Finished: SUCCESS
> 
> https://jenkins.thetaphi.de/job/Lucene-Solr-8.x-Release-Tester/38/console
> 
> I did not do futher checks, I just want to get the release out soon! Thanks
> to Jan to do the release so fast.
> 
> In the release notes of Lucene we should just mention that log4j was updated
> (Luke and possibly Replicator). A changes entry was forgotten, but that's
> not urgent.
> 
> So here's my +1
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Jan Høydahl 
>> Sent: Tuesday, December 14, 2021 3:36 PM
>> To: Lucene Dev 
>> Subject: [VOTE] Release Lucene/Solr 8.11.1 RC1
>> 
>> Please vote for release candidate 1 for Lucene/Solr 8.11.1
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-
>> rev0b002b11819df70783e83ef36b42ed1223c14b50
>> 
>> You can run the smoke tester directly (from a fresh branch_8_11 checkout),
>> with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-
>> rev0b002b11819df70783e83ef36b42ed1223c14b50
>> 
>> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00
> UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1
>> 
>> SUCCESS! [0:54:56.979538]
>> 
>> NOTE: You must run the smoke tester from latest commit on branch_8_11,
>> since my surname contains a unicode-character, needing a fix in the gpg
>> command ran by the smoketester.
>> -
>> 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
> 


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

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

If anyone wants to test RC1 in Docker or solr-operator, here is an image: 
cominvent/solr:8.11.1-rc1 

Example:

  docker run --rm -p 8983:8983 cominvent/solr:8.11.1-rc1 -c

Jan

> 15. des. 2021 kl. 13:17 skrev Michael McCandless :
> 
> +1 from me from smoke test result:
> 
> SUCCESS! [0:43:56.320467]
> 
> It failed the first time with this failure, but I re-ran and succeeded above:
> 
>[junit4] Suite: org.apache.solr.security.JWTIssuerConfigTest
>[junit4]   2> 996270 INFO  
> (SUITE-JWTIssuerConfigTest-seed#[6DC363670E25C70C]-worker) [ ] 
> o.a.s.SolrTestCase Setting 'solr.default.confdir' system property to 
> test-framework derived value of '/tmp/smoke_l\
> ucene_8.11.1_0b002b11819df70783e83ef36b42ed1223c14b50/unpack/solr-8.11.1/solr/server/solr/configsets/_default/conf'
>[junit4]   2> NOTE: reproduce with: ant test  
> -Dtestcase=JWTIssuerConfigTest -Dtests.method=jwksUrlwithHttpBehaviors 
> -Dtests.seed=6DC363670E25C70C -Dtests.locale=da-DK 
> -Dtests.timezone=Europe/Isle_of_Man -Dte\
> sts.asserts=true -Dtests.file.encoding=UTF-8
>[junit4] FAILURE 0.01s J0 | JWTIssuerConfigTest.jwksUrlwithHttpBehaviors 
> <<<
>[junit4]> Throwable #1: junit.framework.AssertionFailedError: Expected 
> exception SolrException but no exception was thrown
>[junit4]>at 
> __randomizedtesting.SeedInfo.seed([6DC363670E25C70C:2678FED260C5F46]:0)
>[junit4]>at 
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2759)
>[junit4]>at 
> org.apache.lucene.util.LuceneTestCase.expectThrows(LuceneTestCase.java:2749)
>[junit4]>at 
> org.apache.solr.security.JWTIssuerConfigTest.jwksUrlwithHttpBehaviors(JWTIssuerConfigTest.java:145)
>[junit4]>at java.lang.Thread.run(Thread.java:748)
>[junit4]   2> NOTE: test params are: codec=Asserting(Lucene87): {}, 
> docValues:{}, maxPointsInLeafNode=412, maxMBSortInHeap=5.443718473632918, 
> sim=Asserting(RandomSimilarity(queryNorm=true): {}), locale=da-DK,\
>  timezone=Europe/Isle_of_Man
>[junit4]   2> NOTE: Linux 5.14.12-arch1-1 amd64/Oracle Corporation 
> 1.8.0_251 (64-bit)/cpus=128,threads=1,free=134208904,total=508035072
> 
> Mike McCandless
> 
> http://blog.mikemccandless.com <http://blog.mikemccandless.com/>
> 
> On Tue, Dec 14, 2021 at 11:51 PM Ishan Chattopadhyaya 
> mailto:ichattopadhy...@gmail.com>> wrote:
> Ran the smoke tested, and it passed.
> 
> SUCCESS! [1:21:47.769507]
> 
> +1
> 
> On Wed, Dec 15, 2021 at 9:28 AM Mike Drob  <mailto:md...@apache.org>> wrote:
> +1 (binding)
> 
> ran smoke tester - unit tests passed the first time but timed out downloading 
> artifacts from maven. reran a second time, modifying the smoke test script to 
> not run solr tests (again) and the script passed.
> 
> started up a solr server from the unpacked download and verified it against a 
> few log4j injections, server responded appropriately each time
> 
> manually verified a few of the other bugs having been fixed going into 8.11.1
> 
> SUCCESS! [0:35:37.290016]
> 
> On Tue, Dec 14, 2021 at 7:24 PM Timothy Potter  <mailto:thelabd...@gmail.com>> wrote:
> +1 (binding) ~ just ran smoke tester this time
> 
> SUCCESS! [1:16:20.247006]
> 
> On Tue, Dec 14, 2021 at 7:36 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> >
> > Please vote for release candidate 1 for Lucene/Solr 8.11.1
> >
> > The artifacts can be downloaded from:
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> >  
> > <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
> >
> > You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
> > with this command:
> >
> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> > https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> >  
> > <https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50>
> >
> > The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
> >
> > SUCCESS! [0:54:56.979538]
> >
> > NOTE: You must run the smoke tester from latest commit on branch_8_11, 
> > since my surname contains a unicode-character, needing a fix in the gpg 
> > command ran by the smoketester.
> > 

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

The only question I have is regarding Lucene, which lists (no changes). 
There IS one change though - it ships with log4j 2.16, but I guess that's only 
relevant for Luke since everyone else consume Lucene through maven. Is it worth 
a mention in the Lucene release-notes 
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1 ? Feel 
free to edit!

Jan

> 14. des. 2021 kl. 15:35 skrev Jan Høydahl :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.11.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> 
> You can run the smoke tester directly (from a fresh branch_8_11 checkout), 
> with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50
> 
> The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> SUCCESS! [0:54:56.979538]
> 
> NOTE: You must run the smoke tester from latest commit on branch_8_11, since 
> my surname contains a unicode-character, needing a fix in the gpg command ran 
> by the smoketester.


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

[VOTE] Release Lucene/Solr 8.11.1 RC1

[Jan Høydahl]

Please vote for release candidate 1 for Lucene/Solr 8.11.1

The artifacts can be downloaded from:
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50

You can run the smoke tester directly (from a fresh branch_8_11 checkout), with 
this command:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.1-RC1-rev0b002b11819df70783e83ef36b42ed1223c14b50

The vote will be open for at least 72 hours i.e. until 2021-12-17 15:00 UTC.

[ ] +1  approve
[ ] +0  no opinion
[ ] -1  disapprove (and reason why)

Here is my +1

SUCCESS! [0:54:56.979538]

NOTE: You must run the smoke tester from latest commit on branch_8_11, since my 
surname contains a unicode-character, needing a fix in the gpg command ran by 
the smoketester.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Lucene/Solr 8.11.1 release

[Jan Høydahl]

Yes, I'm building with log4j 2.16 now.
Will BadApple a few tests, yes..

Jan

> 14. des. 2021 kl. 10:39 skrev Uwe Schindler :
> 
> I think we should update log4j to 2.16.0:
> 
> Reason: It has all JNDI and expansion of ${...} in log messages disabled. So 
> we also prevent that people enable this with buggy logging configs.
> 
> Uwe
> 
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
> 
>> -Original Message-
>> From: Adrien Grand 
>> Sent: Tuesday, December 14, 2021 8:57 AM
>> To: Lucene Dev 
>> Subject: Re: Lucene/Solr 8.11.1 release
>> 
>> Jan, if you remember the names of the tests that fail, can you
>> annotate them with @BadApple so that they will not fail when building
>> new RCs or future 8.11 patch releases?
>> 
>> 
>> On Tue, Dec 14, 2021 at 8:41 AM Jan Høydahl 
>> wrote:
>>> 
>>> I've had one run which passed tests, but then it failed signing due to me 
>>> using
>> Ant 1.10. After that I had 2 runs with one test failure each.. This beast is 
>> hard
>> to please.
>>> Will continue with Ant 1.9 until there is a passing build and then announce
>> RC1.
>>> 
>>> Jan
>>> 
>>> 14. des. 2021 kl. 01:08 skrev Jan Høydahl :
>>> 
>>> +1
>>> 
>>> Feel free to merge it if you feel an itch. Then I'll git pull before next 
>>> build
>> attempt.
>>> 
>>> Jan
>>> 
>>> 14. des. 2021 kl. 01:00 skrev Mike Drob :
>>> 
>>> There's been a log4j 2.16 release as well, should we pick that one up if 
>>> your
>> next attempt fails?
>>> 
>>> https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0
>>> 
>>> On Mon, Dec 13, 2021 at 5:58 PM Jan Høydahl 
>> wrote:
>>>> 
>>>> Currently running 4th attempt at making buildAndPushRelease.py happy.
>> Always different tests failing...
>>>> 
>>>> Jan
>>>> 
>>>> 13. des. 2021 kl. 21:00 skrev David Smiley :
>>>> 
>>>> Looks good; thanks Jan!
>>>> 
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>> 
>>>> 
>>>> On Mon, Dec 13, 2021 at 9:34 AM Jan Høydahl 
>> wrote:
>>>>> 
>>>>> Including Lucene dev as well.
>>>>> 
>>>>> As I see no Lucene level bug fixes for 8.11.1, I have prepared an "empty"
>> release announcement:
>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1
>>>>> Please edit as you see fit.
>>>>> 
>>>>> The Solr announcement is slightly updated, proof-read welcome
>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1
>>>>> 
>>>>> There are now 18 CHANGES entries for Solr:
>> https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt
>>>>> 
>>>>> Jan
>>>>> 
>>>>>> 13. des. 2021 kl. 02:24 skrev Jan Høydahl :
>>>>>> 
>>>>>> There seems to be no open blockers for 8.11.1, so I'll proceed with RC1
>> soon.
>>>>>> Shout out if you want me to wait for a specific important bugfix.
>>>>>> 
>>>>>> Please also review the Release Notes at
>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 8. des. 2021 kl. 02:48 skrev Timothy Potter :
>>>>>>> 
>>>>>>> agreed! thanks for stepping up to be the RM Jan ;-)
>>>>>>> 
>>>>>>> On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl 
>> wrote:
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no
>> changes.
>>>>>>>> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1
>> release.
>>>>>>>> 
>>>>>>>> I volunteer as RM and propose a first RC on Monday 13th. That should
>> allow some time to merge any last bug fixes both for Lucene and Solr.
>>>>>>>> Please feel free to backport bug fixes with your own judgement (no
>> new features please). If you are uncertain whether a backport is "saf

Re: Lucene/Solr 8.11.1 release

[Jan Høydahl]

I've had one run which passed tests, but then it failed signing due to me using 
Ant 1.10. After that I had 2 runs with one test failure each.. This beast is 
hard to please.
Will continue with Ant 1.9 until there is a passing build and then announce RC1.

Jan

> 14. des. 2021 kl. 01:08 skrev Jan Høydahl :
> 
> +1
> 
> Feel free to merge it if you feel an itch. Then I'll git pull before next 
> build attempt.
> 
> Jan
> 
>> 14. des. 2021 kl. 01:00 skrev Mike Drob > <mailto:md...@mdrob.com>>:
>> 
>> There's been a log4j 2.16 release as well, should we pick that one up if 
>> your next attempt fails?
>> 
>> https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0 
>> <https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0>
>> 
>> On Mon, Dec 13, 2021 at 5:58 PM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> Currently running 4th attempt at making buildAndPushRelease.py happy. Always 
>> different tests failing...
>> 
>> Jan
>> 
>>> 13. des. 2021 kl. 21:00 skrev David Smiley >> <mailto:dsmi...@apache.org>>:
>>> 
>>> Looks good; thanks Jan!
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley 
>>> <http://www.linkedin.com/in/davidwsmiley>
>>> 
>>> On Mon, Dec 13, 2021 at 9:34 AM Jan Høydahl >> <mailto:jan@cominvent.com>> wrote:
>>> Including Lucene dev as well.
>>> 
>>> As I see no Lucene level bug fixes for 8.11.1, I have prepared an "empty" 
>>> release announcement: 
>>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1 
>>> <https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1>
>>> Please edit as you see fit.
>>> 
>>> The Solr announcement is slightly updated, proof-read welcome 
>>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
>>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
>>> 
>>> There are now 18 CHANGES entries for Solr: 
>>> https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt 
>>> <https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt>
>>> 
>>> Jan
>>> 
>>> > 13. des. 2021 kl. 02:24 skrev Jan Høydahl >> > <mailto:jan@cominvent.com>>:
>>> > 
>>> > There seems to be no open blockers for 8.11.1, so I'll proceed with RC1 
>>> > soon.
>>> > Shout out if you want me to wait for a specific important bugfix.
>>> > 
>>> > Please also review the Release Notes at 
>>> > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
>>> > <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
>>> > 
>>> > Jan
>>> > 
>>> >> 8. des. 2021 kl. 02:48 skrev Timothy Potter >> >> <mailto:thelabd...@gmail.com>>:
>>> >> 
>>> >> agreed! thanks for stepping up to be the RM Jan ;-)
>>> >> 
>>> >> On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl >> >> <mailto:jan@cominvent.com>> wrote:
>>> >>> 
>>> >>> Hi,
>>> >>> 
>>> >>> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no 
>>> >>> changes.
>>> >>> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 
>>> >>> release.
>>> >>> 
>>> >>> I volunteer as RM and propose a first RC on Monday 13th. That should 
>>> >>> allow some time to merge any last bug fixes both for Lucene and Solr.
>>> >>> Please feel free to backport bug fixes with your own judgement (no new 
>>> >>> features please). If you are uncertain whether a backport is "safe", 
>>> >>> please raise a question here.
>>> >>> 
>>> >>> I'll re-enable Jenkins for branch_8_11 now. Commits that fix or 
>>> >>> @BadApples unstable tests highly appreciated.
>>> >>> 
>>> >>> Jan
>>> >>> 
>>> >>> 
>>> >>> -
>>> >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
>>> >>> <mailto:dev-unsubscr...@solr.apache.org>
>>> >>> For additional commands, e-mail: dev-h...@solr.apache.org 
>>> >>> <mailto:dev-h...@solr.apache.org>
>>> >>> 
>>> >> 
>>> >> -
>>> >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
>>> >> <mailto:dev-unsubscr...@solr.apache.org>
>>> >> For additional commands, e-mail: dev-h...@solr.apache.org 
>>> >> <mailto:dev-h...@solr.apache.org>
>>> >> 
>>> > 
>>> 
>>> 
>>> -
>>> 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>
>>> 
>> 
> 

Re: Lucene/Solr 8.11.1 release

[Jan Høydahl]

+1

Feel free to merge it if you feel an itch. Then I'll git pull before next build 
attempt.

Jan

> 14. des. 2021 kl. 01:00 skrev Mike Drob :
> 
> There's been a log4j 2.16 release as well, should we pick that one up if your 
> next attempt fails?
> 
> https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0 
> <https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0>
> 
> On Mon, Dec 13, 2021 at 5:58 PM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> Currently running 4th attempt at making buildAndPushRelease.py happy. Always 
> different tests failing...
> 
> Jan
> 
>> 13. des. 2021 kl. 21:00 skrev David Smiley > <mailto:dsmi...@apache.org>>:
>> 
>> Looks good; thanks Jan!
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley 
>> <http://www.linkedin.com/in/davidwsmiley>
>> 
>> On Mon, Dec 13, 2021 at 9:34 AM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>> Including Lucene dev as well.
>> 
>> As I see no Lucene level bug fixes for 8.11.1, I have prepared an "empty" 
>> release announcement: 
>> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1 
>> <https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1>
>> Please edit as you see fit.
>> 
>> The Solr announcement is slightly updated, proof-read welcome 
>> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
>> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
>> 
>> There are now 18 CHANGES entries for Solr: 
>> https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt 
>> <https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt>
>> 
>> Jan
>> 
>> > 13. des. 2021 kl. 02:24 skrev Jan Høydahl > > <mailto:jan@cominvent.com>>:
>> > 
>> > There seems to be no open blockers for 8.11.1, so I'll proceed with RC1 
>> > soon.
>> > Shout out if you want me to wait for a specific important bugfix.
>> > 
>> > Please also review the Release Notes at 
>> > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
>> > <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
>> > 
>> > Jan
>> > 
>> >> 8. des. 2021 kl. 02:48 skrev Timothy Potter > >> <mailto:thelabd...@gmail.com>>:
>> >> 
>> >> agreed! thanks for stepping up to be the RM Jan ;-)
>> >> 
>> >> On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl > >> <mailto:jan@cominvent.com>> wrote:
>> >>> 
>> >>> Hi,
>> >>> 
>> >>> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no 
>> >>> changes.
>> >>> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 
>> >>> release.
>> >>> 
>> >>> I volunteer as RM and propose a first RC on Monday 13th. That should 
>> >>> allow some time to merge any last bug fixes both for Lucene and Solr.
>> >>> Please feel free to backport bug fixes with your own judgement (no new 
>> >>> features please). If you are uncertain whether a backport is "safe", 
>> >>> please raise a question here.
>> >>> 
>> >>> I'll re-enable Jenkins for branch_8_11 now. Commits that fix or 
>> >>> @BadApples unstable tests highly appreciated.
>> >>> 
>> >>> Jan
>> >>> 
>> >>> 
>> >>> -
>> >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
>> >>> <mailto:dev-unsubscr...@solr.apache.org>
>> >>> For additional commands, e-mail: dev-h...@solr.apache.org 
>> >>> <mailto:dev-h...@solr.apache.org>
>> >>> 
>> >> 
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
>> >> <mailto:dev-unsubscr...@solr.apache.org>
>> >> For additional commands, e-mail: dev-h...@solr.apache.org 
>> >> <mailto:dev-h...@solr.apache.org>
>> >> 
>> > 
>> 
>> 
>> -
>> 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>
>> 
> 

Re: Lucene/Solr 8.11.1 release

[Jan Høydahl]

Currently running 4th attempt at making buildAndPushRelease.py happy. Always 
different tests failing...

Jan

> 13. des. 2021 kl. 21:00 skrev David Smiley :
> 
> Looks good; thanks Jan!
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> <http://www.linkedin.com/in/davidwsmiley>
> 
> On Mon, Dec 13, 2021 at 9:34 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> Including Lucene dev as well.
> 
> As I see no Lucene level bug fixes for 8.11.1, I have prepared an "empty" 
> release announcement: 
> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1 
> <https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1>
> Please edit as you see fit.
> 
> The Solr announcement is slightly updated, proof-read welcome 
> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
> 
> There are now 18 CHANGES entries for Solr: 
> https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt 
> <https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt>
> 
> Jan
> 
> > 13. des. 2021 kl. 02:24 skrev Jan Høydahl  > <mailto:jan@cominvent.com>>:
> > 
> > There seems to be no open blockers for 8.11.1, so I'll proceed with RC1 
> > soon.
> > Shout out if you want me to wait for a specific important bugfix.
> > 
> > Please also review the Release Notes at 
> > https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
> > <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1> 
> > 
> > Jan
> > 
> >> 8. des. 2021 kl. 02:48 skrev Timothy Potter  >> <mailto:thelabd...@gmail.com>>:
> >> 
> >> agreed! thanks for stepping up to be the RM Jan ;-)
> >> 
> >> On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl  >> <mailto:jan@cominvent.com>> wrote:
> >>> 
> >>> Hi,
> >>> 
> >>> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no 
> >>> changes.
> >>> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 
> >>> release.
> >>> 
> >>> I volunteer as RM and propose a first RC on Monday 13th. That should 
> >>> allow some time to merge any last bug fixes both for Lucene and Solr.
> >>> Please feel free to backport bug fixes with your own judgement (no new 
> >>> features please). If you are uncertain whether a backport is "safe", 
> >>> please raise a question here.
> >>> 
> >>> I'll re-enable Jenkins for branch_8_11 now. Commits that fix or 
> >>> @BadApples unstable tests highly appreciated.
> >>> 
> >>> Jan
> >>> 
> >>> 
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
> >>> <mailto:dev-unsubscr...@solr.apache.org>
> >>> For additional commands, e-mail: dev-h...@solr.apache.org 
> >>> <mailto:dev-h...@solr.apache.org>
> >>> 
> >> 
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org 
> >> <mailto:dev-unsubscr...@solr.apache.org>
> >> For additional commands, e-mail: dev-h...@solr.apache.org 
> >> <mailto:dev-h...@solr.apache.org>
> >> 
> > 
> 
> 
> -
> 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>
> 

Re: Lucene/Solr 8.11.1 release

[Jan Høydahl]

Including Lucene dev as well.

As I see no Lucene level bug fixes for 8.11.1, I have prepared an "empty" 
release announcement: 
https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_1
Please edit as you see fit.

The Solr announcement is slightly updated, proof-read welcome 
https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 

There are now 18 CHANGES entries for Solr: 
https://github.com/apache/lucene-solr/blob/branch_8_11/solr/CHANGES.txt

Jan

> 13. des. 2021 kl. 02:24 skrev Jan Høydahl :
> 
> There seems to be no open blockers for 8.11.1, so I'll proceed with RC1 soon.
> Shout out if you want me to wait for a specific important bugfix.
> 
> Please also review the Release Notes at 
> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_1 
> 
> Jan
> 
>> 8. des. 2021 kl. 02:48 skrev Timothy Potter :
>> 
>> agreed! thanks for stepping up to be the RM Jan ;-)
>> 
>> On Tue, Dec 7, 2021 at 6:05 PM Jan Høydahl  wrote:
>>> 
>>> Hi,
>>> 
>>> Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no 
>>> changes.
>>> Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 
>>> release.
>>> 
>>> I volunteer as RM and propose a first RC on Monday 13th. That should allow 
>>> some time to merge any last bug fixes both for Lucene and Solr.
>>> Please feel free to backport bug fixes with your own judgement (no new 
>>> features please). If you are uncertain whether a backport is "safe", please 
>>> raise a question here.
>>> 
>>> I'll re-enable Jenkins for branch_8_11 now. Commits that fix or @BadApples 
>>> unstable tests highly appreciated.
>>> 
>>> Jan
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
> 


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

Re: Closing GitHub PRs

[Jan Høydahl]

5178 status=Resolved, resolution=Fixed, 
resolutiondate=2021-03-19T07:21:16.000+ (SOLR-15178 Non-existent dependency 
listed in solr-core)

Jan

> 8. des. 2021 kl. 13:55 skrev Jan Høydahl :
> 
>> This is a proposal for a one-time action, introducing a stale-bot for the 
>> project, which I can see is more controversial and annoying for sure.
> 
> Correction: This is a proposal for a one-time action, NOT introducing a 
> stale-bot for the project, which I can see is more controversial and annoying 
> for sure.
> 


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

Re: Closing GitHub PRs

[Jan Høydahl]

> This is a proposal for a one-time action, introducing a stale-bot for the 
> project, which I can see is more controversial and annoying for sure.

Correction: This is a proposal for a one-time action, NOT introducing a 
stale-bot for the project, which I can see is more controversial and annoying 
for sure.


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

Re: Closing GitHub PRs

[Jan Høydahl]

Calm down :)

As you can read from the last comment, we can choose whether to 
* Close with comment and label
* Comment and label only
* Comment only
* Do nothing

The lucene-solr repo is not dead, it will still be used for back-porting 
bugfixes to branch_8_11 for probably another 12 months.
Byt several branches are dead/archived, and it really makes no sense to keep 
PRs for those alive either.

This is a proposal for a one-time action, introducing a stale-bot for the 
project, which I can see is more controversial and annoying for sure.

Jan

> 8. des. 2021 kl. 13:04 skrev Robert Muir :
> 
> i mean you dont even have anything close to fucking consensus about
> "bulk close" on this thread. most are against it. why be so fucking
> sneaky about it? I don't get it!
> 
> On Wed, Dec 8, 2021 at 7:03 AM Robert Muir  wrote:
>> 
>> On Wed, Dec 8, 2021 at 7:01 AM Robert Muir  wrote:
>>> 
>>> I added my vote against bulk close functionality.
>>> it is pretty clear from this thread that several of us are opposed to
>>> bulk close.
>>> 
>>> somehow the discussion jumped from bulk commenting to bulk close. fuck that!
>>> 
>>> On Wed, Dec 8, 2021 at 5:39 AM Jan Høydahl  wrote:
>>>> 
>>>> I gave it a shot, and it works, so with this change to githubPRs.py 
>>>> script: https://github.com/apache/lucene-solr/pull/2625 we can close all 
>>>> open PRs with a comment and label with a single command. The script can 
>>>> also easily be adapted to other use cases.
>>>> 
>>>> Jan
>>>> 
>>>>> 8. des. 2021 kl. 01:33 skrev Jan Høydahl :
>>>>> 
>>>>> +1 to bulk commenting on the 274 open PRs with a standard message about 
>>>>> the need for new PRs.
>>>>> We already have a "stale-closed" label in GitHub, so if we add that label 
>>>>> to all the issues they can safely be closed without information loss.
>>>>> My script 
>>>>> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py 
>>>>> can probably be tweaked to do these actions. It uses a python GitHub 
>>>>> library and already fetches all open PRs, and allows to pass a token, so 
>>>>> I guess that the token will also allow edits on behalf of the user.
>>>>> 
>>>>> Jan
>>>>> 
>>>>>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov :
>>>>>> 
>>>>>> In this specific instance, I don't see the harm in leaving these
>>>>>> issues there since the entire repo is essentially an archival artifact
>>>>>> at this point. If we actually want to notify people that "hey your
>>>>>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>>>>>> could maybe generate some emails? Although I really have no idea how
>>>>>> we would accomplish that.
>>>>>> 
>>>>>> In general, I'm in favor of cleaning up / closing issues that are
>>>>>> clearly not going to be worked.
>>>>>> 
>>>>>> For example in JIRA we have so many old issues that they can clutter
>>>>>> up search results, making it much harder for new contributors
>>>>>> (especially) to find "interesting" issues that might be relevant today
>>>>>> and workable.  I have heard various arguments for keeping these old
>>>>>> issues: they represent an historical view of the project; "you never
>>>>>> know" maybe they become relevant again; and this idea of not annoying
>>>>>> people by arbitrarily closing their issue. These all have some
>>>>>> validity, but I we have to strike a balance. I wonder if we can
>>>>>> address them in another way. In JIRA can we keep these old issues
>>>>>> while hiding them from default searches. Can we "archive" old issues
>>>>>> in some way? Maybe there is a "Status" like Archived that is different
>>>>>> from Closed. Anything but Open!
>>>>>> 
>>>>>> 
>>>>>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob  wrote:
>>>>>>> 
>>>>>>> I understand the frustrations around closing somebody’s PR as stale, 
>>>>>>> but I also think that there is value in informing the contributors I 
>>>>>>> this is never getting solved/fixed/looked at, if this is still 
>>&g

Re: Closing GitHub PRs

[Jan Høydahl]

I gave it a shot, and it works, so with this change to githubPRs.py script: 
https://github.com/apache/lucene-solr/pull/2625 we can close all open PRs with 
a comment and label with a single command. The script can also easily be 
adapted to other use cases.

Jan

> 8. des. 2021 kl. 01:33 skrev Jan Høydahl :
> 
> +1 to bulk commenting on the 274 open PRs with a standard message about the 
> need for new PRs.
> We already have a "stale-closed" label in GitHub, so if we add that label to 
> all the issues they can safely be closed without information loss.
> My script 
> https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can 
> probably be tweaked to do these actions. It uses a python GitHub library and 
> already fetches all open PRs, and allows to pass a token, so I guess that the 
> token will also allow edits on behalf of the user.
> 
> Jan
> 
>> 2. des. 2021 kl. 17:55 skrev Michael Sokolov :
>> 
>> In this specific instance, I don't see the harm in leaving these
>> issues there since the entire repo is essentially an archival artifact
>> at this point. If we actually want to notify people that "hey your
>> issue is in a dead zone, do you want to revive it? Here's how ..." we
>> could maybe generate some emails? Although I really have no idea how
>> we would accomplish that.
>> 
>> In general, I'm in favor of cleaning up / closing issues that are
>> clearly not going to be worked.
>> 
>> For example in JIRA we have so many old issues that they can clutter
>> up search results, making it much harder for new contributors
>> (especially) to find "interesting" issues that might be relevant today
>> and workable.  I have heard various arguments for keeping these old
>> issues: they represent an historical view of the project; "you never
>> know" maybe they become relevant again; and this idea of not annoying
>> people by arbitrarily closing their issue. These all have some
>> validity, but I we have to strike a balance. I wonder if we can
>> address them in another way. In JIRA can we keep these old issues
>> while hiding them from default searches. Can we "archive" old issues
>> in some way? Maybe there is a "Status" like Archived that is different
>> from Closed. Anything but Open!
>> 
>> 
>> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob  wrote:
>>> 
>>> I understand the frustrations around closing somebody’s PR as stale, but I 
>>> also think that there is value in informing the contributors I this is 
>>> never getting solved/fixed/looked at, if this is still important please go 
>>> over there instead.
>>> 
>>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir  wrote:
>>>> 
>>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>>  wrote:
>>>>> 
>>>>> Could we maybe instead bulk-add a comment explaining the split and how to 
>>>>> take the PR forwards if someone (in the future) has itch/time?
>>>>> 
>>>>> I know we humans love to clean things up, but I think leaving such 
>>>>> "unclean" things open serves an important purpose.  They all had 
>>>>> importance to at least one person at one point in time, and likely many 
>>>>> of them are still relevant if they piqued someones curiosity to dig back 
>>>>> into them.  Closing them makes them harder to find for the future 
>>>>> developer.
>>>>> 
>>>>> I'm sure some of them are already resolved/duplicates too.  If only we 
>>>>> could divine which are which.
>>>>> 
>>>>> 
>>>> 
>>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>>> I see it in other trackers. Is there a rush to close these for some
>>>> reason?
>>>> 
>>>> -
>>>> 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
>> 
> 


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

Lucene/Solr 8.11.1 release

[Jan Høydahl]

Hi,

Solr has 13 bug fixes lined up in branch_8_11 already. Lucene has no changes.
Now that Lucene 9.0 is out the door (congrats!), let's do the 8.11.1 release.

I volunteer as RM and propose a first RC on Monday 13th. That should allow some 
time to merge any last bug fixes both for Lucene and Solr.
Please feel free to backport bug fixes with your own judgement (no new features 
please). If you are uncertain whether a backport is "safe", please raise a 
question here.

I'll re-enable Jenkins for branch_8_11 now. Commits that fix or @BadApples 
unstable tests highly appreciated.

Jan


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

Re: Closing GitHub PRs

[Jan Høydahl]

+1 to bulk commenting on the 274 open PRs with a standard message about the 
need for new PRs.
We already have a "stale-closed" label in GitHub, so if we add that label to 
all the issues they can safely be closed without information loss.
My script 
https://github.com/apache/lucene/blob/main/dev-tools/scripts/githubPRs.py can 
probably be tweaked to do these actions. It uses a python GitHub library and 
already fetches all open PRs, and allows to pass a token, so I guess that the 
token will also allow edits on behalf of the user.

Jan

> 2. des. 2021 kl. 17:55 skrev Michael Sokolov :
> 
> In this specific instance, I don't see the harm in leaving these
> issues there since the entire repo is essentially an archival artifact
> at this point. If we actually want to notify people that "hey your
> issue is in a dead zone, do you want to revive it? Here's how ..." we
> could maybe generate some emails? Although I really have no idea how
> we would accomplish that.
> 
> In general, I'm in favor of cleaning up / closing issues that are
> clearly not going to be worked.
> 
> For example in JIRA we have so many old issues that they can clutter
> up search results, making it much harder for new contributors
> (especially) to find "interesting" issues that might be relevant today
> and workable.  I have heard various arguments for keeping these old
> issues: they represent an historical view of the project; "you never
> know" maybe they become relevant again; and this idea of not annoying
> people by arbitrarily closing their issue. These all have some
> validity, but I we have to strike a balance. I wonder if we can
> address them in another way. In JIRA can we keep these old issues
> while hiding them from default searches. Can we "archive" old issues
> in some way? Maybe there is a "Status" like Archived that is different
> from Closed. Anything but Open!
> 
> 
> On Mon, Nov 29, 2021 at 4:15 PM Mike Drob  wrote:
>> 
>> I understand the frustrations around closing somebody’s PR as stale, but I 
>> also think that there is value in informing the contributors I this is never 
>> getting solved/fixed/looked at, if this is still important please go over 
>> there instead.
>> 
>> On Mon, Nov 29, 2021 at 1:55 PM Robert Muir  wrote:
>>> 
>>> On Mon, Nov 29, 2021 at 2:49 PM Michael McCandless
>>>  wrote:
 
 Could we maybe instead bulk-add a comment explaining the split and how to 
 take the PR forwards if someone (in the future) has itch/time?
 
 I know we humans love to clean things up, but I think leaving such 
 "unclean" things open serves an important purpose.  They all had 
 importance to at least one person at one point in time, and likely many of 
 them are still relevant if they piqued someones curiosity to dig back into 
 them.  Closing them makes them harder to find for the future developer.
 
 I'm sure some of them are already resolved/duplicates too.  If only we 
 could divine which are which.
 
 
>>> 
>>> +1, I'd rather not auto-close PRs. I'm always frustrated by this when
>>> I see it in other trackers. Is there a rush to close these for some
>>> reason?
>>> 
>>> -
>>> 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
> 


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

Re: Maven publication with the Gradle build

[Jan Høydahl]

There may be some loose ends here. See 
https://issues.apache.org/jira/browse/LUCENE-9809?focusedCommentId=17433373=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-17433373
 as a starting point for gradle command.
Related:LUCENE-10174, Umbrella: LUCENE-9488

So the wizard should probably run the gradle equivalent 

./gradlew mavenToApacheReleases -Dversion.release= 
-PasfNexusUsername= -PasfNexusPassword=

Jan

> 6. des. 2021 kl. 14:19 skrev Adrien Grand :
> 
> Hello,
> 
> The release wizard still suggests using Ant for Maven publication:
> 
>  cd ~/.lucene-releases/9.0.0/lucene
>  ant clean stage-maven-artifacts \
>  
> -Dmaven.dist.dir=~/.lucene-releases/9.0.0/RC4/dist/lucene-9.0.0-RC4-rev-0b18b3b965cedaf5eb129aa41243a44c83ca826d/lucene/maven
> \
>  -Dm2.repository.id=apache.releases.https \
>  
> -Dm2.repository.url=https://repository.apache.org/service/local/staging/deploy/maven2
> 
> The Gradle build has a `mavenToApacheReleases` task that seems to do
> what I want, but I can't find how to tell it to use the JARs of RC4
> rather than those produced by `gradlew assembleRelease`. Can someone
> help me with this?
> 
> -- 
> Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 

Re: [VOTE] Release Lucene 9.0.0 RC4

[Jan Høydahl]

SUCCESS! [0:20:42.942934]

+1

Jan

> 1. des. 2021 kl. 17:56 skrev Adrien Grand :
> 
> Please vote for release candidate 4 for Lucene 9.0.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC4-rev-0b18b3b965cedaf5eb129aa41243a44c83ca826d
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC4-rev-0b18b3b965cedaf5eb129aa41243a44c83ca826d
> 
> The vote will be open until 2021-12-06 08:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> 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: Welcome Julie Tibshirani to the Lucene PMC

[Jan Høydahl]

Welcome, Julie!

Jan

> 30. nov. 2021 kl. 22:49 skrev Adrien Grand :
> 
> I'm pleased to announce that Julie Tibshirani has accepted an invitation to 
> join the Lucene PMC!
> 
> Congratulations Julie, and welcome aboard!
> 
> -- 
> Adrien


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

Re: [VOTE] Release Lucene 9.0.0 RC3

[Jan Høydahl]

+1 SUCCESS! [0:23:41.775448]

Only ran smoketester this time.

Jan

> 26. nov. 2021 kl. 15:31 skrev Adrien Grand :
> 
> Please vote for release candidate 3 for Lucene 9.0.0.
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
> 
> The vote will be open until 2021-11-30 9:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1.
> 
> -- 
> 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: [VOTE] Release Lucene 9.0.0 RC2

[Jan Høydahl]

+1 SUCCESS! [0:20:30.247277]

Ran smoketester and browsed around the archives. Lincense and Notice on 
top-level of src dist looks good.

Tested launching Luke from bin/luke.sh - OK
Minor: Luke started on macOS Monterey complains about Times font not being 
available:
> Warning: the fonts "Times" and "Times" are not available for the Java logical 
> font "Serif", which may have unexpected appearance or behavior. Re-enable the 
> "Times" font to remove this warning.


Minor: README.md in binary dist says "The following sub-folders are included in 
the binary distribution of Lucene: bin/, modules/, modules-thirdparty/, 
licenses/". But it fails to mention "docs/" and "modules-test-framework/"

Jan

> 23. nov. 2021 kl. 09:40 skrev Adrien Grand :
> 
> Please vote for release candidate 2 for Lucene 9.0.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC2-rev-95072f3b71e67e308d71a6149323bf7dd04c8f75
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC2-rev-95072f3b71e67e308d71a6149323bf7dd04c8f75
> 
> The vote will be open until 2021-11-26 09:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> 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: What should we do of branch_8x?

[Jan Høydahl]

+1 to remove / lock branch_8x in the lucene-solr repo, i.e. there will not be 
an 8.12 release by Lucene PMC.

Whether Solr needs to release an 8.12 from own repos or not can be discussed in 
dev@solr if/when needed. So far there is only loose talk, and I think Solr 
PMC's energy should be devoted to the Solr 9.0 release.

Jan

> 22. nov. 2021 kl. 08:28 skrev Atri Sharma :
> 
> +1, agree with Uwe.
> 
> On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
>  wrote:
>> 
>> +1 to Uwe's suggestion
>> 
>> On Mon, 22 Nov, 2021, 11:13 am Gus Heck,  wrote:
>>> 
>>> +1 to uwe's suggestion
>>> 
>>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul  wrote:
 
 I think this is a reasonable suggestion Uwe.
 
 - We don't need to bring Gradle to 8.x
 - We can release 8.12 from a fork of 8.11.
 - we don't need to keep the Lucene source files in that branch. We can 
 nuke it and just keep the Lucene binaries
 
 On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler  wrote:
> 
> Hi,
> 
> If this is really needed, I'd propose the following:
> 
> - fork the branch_8_11 to solr's repo
> - delete all subdirectories below lucene, keep common-build and other 
> stuff.
> - add a single ivy.xml there that refers to all lucene jars of 8.11.x 
> (latest)
> - adapt solr's "copy-lucene-jars" ant task to copy the ivy output dir
> - delete the lucene stuff from release wizard.
> 
> This is quick and easy. Adapting Gradle for a minor release is too hard.
> 
> Am 21. November 2021 21:34:40 UTC schrieb Noble Paul 
> :
>> 
>> All Solr users using 8x and they will need some time to get comfortable 
>> with 9x . So, there is a good chance we may need to release an 8.12 
>> based on Lucene 8.11
>> 
>> On Mon, Nov 22, 2021, 8:22 AM Adrien Grand  wrote:
>>> 
>>> +1 to making branch_8x read-only as Uwe suggested
>>> 
>>> I think Uwe's other point is also important: if we ever wanted to do a 
>>> Solr 8.12, it'd probably be a better option to fork the 8.11 branch 
>>> than to try to reuse branch_8x. So we don't need to tie the decision 
>>> about what we want to do with branch_8x with future plans around an 
>>> 8.12 release?
>>> 
>>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
 
 This is of course all possible, but: WHY the heck do this?
 
 
 
 Lucene 9.0 will come out likely very soon. After that just update the 
 gradle file of Solr main and remove the temporary repository (better 
 comment it out). After that adapt some changes and release Solr 9.0.
 
 
 
 From that point on both projects have a clear split point and 
 everybody can make sure that the backwards compatibility is handled 
 according to project’s needs.
 
 
 
 If the Solr 9.0 release is a intermediary point (not all deprecations 
 removed), release Solr 10.0 four months later, who cares? Solr 9.0 
 will be the release with many new features and Java 11 as minimum 
 requirement.
 
 
 
 I would really, really not start and fuck up the release process for 
 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to 
 do? Why do this release needs to be called 8.12? It is just a version 
 number, so why the heck this big issues? I won’t think that Solr will 
 add any major features before Solr 9. So what is your exact problem?
 
 
 
 Sorry, but this discussion is complete nonsense. Its just version 
 numbers and some hick-hack between two parties that disagree. Keep 
 calm and don’t try to make it overcomplicated!
 
 
 
 I never said that we should kill or delete branch_8x. It can stay 
 there forever. I just suggested to make it read-only and add a note. 
 Unless there’s really a need to do some 8.12 release (in which case, 
 I’d fork 8.11 branch and move Lucene) I see no reason to act and fuck 
 up the repositories of both projects which have now a very clear state.
 
 
 
 Uwe
 
 
 
 -
 
 Uwe Schindler
 
 Achterdiek 19, D-28357 Bremen
 
 https://www.thetaphi.de
 
 eMail: u...@thetaphi.de
 
 
 
 From: Gus Heck 
 Sent: Sunday, November 21, 2021 5:05 PM
 To: dev 
 Subject: Re: What should we do of branch_8x?
 
 
 
 Release of Solr 8.12 It should require the current lucene-solr 8.x 
 branch to remove the lucene bits and declare a dependency on lucene 
 8.11 lucene, that bit shouldn't be too hard if done soon... and the 
 release process for 

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

[Jan Høydahl]

+1

SUCCESS! [1:06:33.517455]

Jan

> 9. nov. 2021 kl. 21:50 skrev Adrien Grand :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.11.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.0-RC1-reve912fdd5b632267a9088507a2a6bcbc75108f381
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2021-11-12 21:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -- 
> Adrien

Re: 8.11 release candidate

[Jan Høydahl]

I added a PR https://github.com/apache/lucene-solr/pull/2603 for SOLR-14438, 
that I had in the workings. I think it will do...

Jan

> 4. nov. 2021 kl. 10:34 skrev Adrien Grand :
> 
> Joel recommended not treating SOLR-15762 as a blocker, so we are left with 
> the following issues as blockers:
>  - SOLR-15706, which should hopefully be addressed soon.
>  - SOLR-14438, which hasn't had activity for a long time. Is someone looking 
> into it? Can someone comment on whether it should actually be treated as a 
> blocker for 8.11?
> 
> On Wed, Nov 3, 2021 at 7:32 PM Adrien Grand  > wrote:
> Jason's above issue isn't fixed yet but it looks like we should be able to 
> have a fix in the very near future.
> 
> However we seem to still have these two other open Solr blockers for 8.11:
>  - SOLR-14438 : Mention 
> decodeAES in LICENSE.txt
>  - SOLR-15762 : 
> IllegalStateException: Recursive update thrown when executing complex Join 
> queries
> 
> Can someone who is more familiar with Solr than I am help confirm that we 
> should indeed treat these two issues as blockers?
> 
> On Tue, Nov 2, 2021 at 9:45 PM Adrien Grand  > wrote:
> Hi Jason,
> 
> This looks bad indeed. Please feel free to backport to 8.11 and update this 
> thread when you are done?
> 
> On Tue, Nov 2, 2021 at 8:24 PM Jason Gerlowski  > wrote:
> Hey Adrien,
> 
> A pretty bad bug in Solr backups came in last week or so: SOLR-15706.
> If it's not too late I'd like to try to get it into 8.11.  Would that
> be ok?
> 
> I'm just digging into things now so I don't have a complete
> understanding yet, but I'm optimistic it won't long delay your
> timeline for cutting the RC.
> 
> Best,
> 
> Jason
> 
> On Tue, Nov 2, 2021 at 1:31 PM Adrien Grand  > wrote:
> >
> > Hello,
> >
> > Assuming CI is green and no blockers have been raised until then, I plan to 
> > build the first release candidate for Lucene/Solr 8.11 on Thursday November 
> > 4th.
> >
> > Please let me know if you are aware of any blocker that we should address 
> > before building the first RC.
> >
> > --
> > Adrien
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Adrien
> 
> 
> -- 
> Adrien
> 
> 
> -- 
> Adrien

Re: should we clean up dev-docs?

[Jan Høydahl]

A cleanup is needed. One dev-docs folder is enough now :) 
We also have the help/ folder which is plaintext since it can be invoked with 
./gradlew helpXXX. Someone should decide what goes in help/ vs dev-docs/

Asciidoc is more capable than MD, and renders well in GitHub as well: 
https://github.com/apache/lucene/blob/main/dev-docs/pmc-chair.adoc
I think there may be some future idea to compile dev-docs into some dev guide 
online, if so, adoc will make it much easier to cross-link, add images, tables  
etc.

Jan

> 15. okt. 2021 kl. 16:51 skrev Adrien Grand :
> 
> I suspect that the adoc format got used because it was the format that was 
> already being used for the Solr ref guide. +1 to move to Markdown.
> 
> 
> 
> On Fri, Oct 15, 2021 at 3:49 PM Michael Sokolov  > wrote:
> I was poking around looking for info on how we release Lucene, and I
> stumbled into this dev-docs folder. It seems to have info that's
> mostly useful for solr workflows, assumes you are working in
> lucene-solr repo, etc. The info about pmc-chair seems helpful, and
> maybe Putnam's guide to using git worktree, which was new to me, but
> the rest should probably go / get updated to refer to lucene repo.
> 
> One question I have is about this adoc format - is it processed by
> something and published somewhere, or is this just intended to be read
> in the source tree (or maybe on github). If it's the latter, maybe we
> should switch to markdown?
> 
> Also, I did find the dev-tools folder and the release wizard. The
> README.md in there is very helpful. I wonder if we ought to simply
> consolidate the docs in dev-docs in here so they are easier to
> discover together?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.10.1 RC1

[Jan Høydahl]

Ran the smoke tester

SUCCESS! [1:21:37.076780]

+1

Jan (binding)

> 13. okt. 2021 kl. 01:59 skrev Mayya Sharipova :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.10.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.1-RC1-rev2f24e6a49d48a032df1f12e146612f59141727a9
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.1-RC1-rev2f24e6a49d48a032df1f12e146612f59141727a9
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2021-10-15 23:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 : SUCCESS! [1:07:19.906103]
> 

Re: Simplify the release artifacts

[Jan Høydahl]

+1 to all suggestions.

ASF has a release policy 
(https://www.apache.org/legal/release-policy.html#release-distribution) and 
artifacts must be uploaded to the mirrors.
There is also a release distribution policy 
(https://infra.apache.org/release-distribution.html#download-links) that says 

   "The website documentation for any Apache product must provide public 
download links where interested parties may obtain current official source 
releases and accompanying cryptographic files."

So I see no reason to stop publishing binary convenience releases in the apache 
mirrors, although few will use that channel.

Jan

> 12. okt. 2021 kl. 01:55 skrev Tomoko Uchida :
> 
> For what it's worth, I did a little survey on how other
> library/sdk/framework projects distribute their artifacts other than
> Maven repositories.
> 
> - Log4j distributes tgz and zip artifacts via the "Download" page.
> https://logging.apache.org/log4j/2.x/download.html
> 
> - JavaFX distributes only zip artifacts via the "Download" page
> https://gluonhq.com/products/javafx/
> 
> - Jersey has a "Download" page but it is actually a facade to Maven Central.
> https://eclipse-ee4j.github.io/jersey/download.html
> 
> - JUnit5 has no "download" page
> https://junit.org/junit5/
> 
> - Spring has no "download" page (as far as I know)
> https://spring.io/projects/spring-framework
> 
> - Jackson has no "download" page (github repo also serves as their
> documentation).
> https://github.com/FasterXML/jackson-core
> 
> They are only small examples, but it seems to me that recent or
> recently renewed projects would tend to have no explicit "download"
> page at all. (?)
> I'm not sure there are any ASF rules or policies about that.
> 
> Tomoko
> 
> 2021年10月11日(月) 21:59 Robert Muir :
>> 
>> +1 overall, comments inline.
>> 
>> On Mon, Oct 11, 2021 at 7:48 AM Dawid Weiss  wrote:
>>> 
>>> Hi.
>>> 
>>> These are the thoughts that occurred to me while rewriting the
>>> packaging in the build system. I think they're worth the discussion
>>> because they could limit the size of the published artifacts as well
>>> as their perceptive quality.
>>> 
>>> 1. Who is going to use the lib/*.jar files we distribute in binary
>>> releases? I don't think they are useful for anything. The dependency
>>> information for modules is stored in maven POMs (and can be easily
>>> written to text files, if it's really something people are dying to
>>> preserve).
>> 
>> +1
>> 
>>> 
>>> I don't think redistributing those JARs makes any sense other than to
>>> make Luke work... What I would suggest is to remove third-party JARs
>>> entirely from the binary distribution and have a separate binary
>>> artifact with a fully functional top-level Luke application.
>>> Alternatively, move those third-party JARs to the top-level
>>> /thirdparty folder and Luke can access them from there.
>> 
>> +1, I think there is already an issue open to give luke its own
>> "release artifact"
>> 
>>> 
>>> 2. Some of the *.txt files both at the top-level and inside subfolders
>>> contain obsolete information. We should at least re-read these. My
>>> personal opinion is that some of the README.txt files inside modules
>>> have little practical use - their content should go inside the javadoc
>>> (package level, perhaps) and this should be the only source of
>>> documentation.
>> 
>> +1, either nuke it, or fold it into javadoc, or at the very least
>> rename to README.md
>> 
>>> 
>>> 3. I would remove the "zip" binary distribution. I'm on Windows myself
>>> so tgz is a tad more difficult to work with but Lucene is a library.
>>> If somebody downloads a binary distribution they should know how to
>>> unpack a tgz file (cygwin, total commander, whatever else).
>> 
>> +1
>> 
>> -
>> 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: Bugfix release Lucene/Solr 8.10.1

[Jan Høydahl]

Remember that the releaseWizard on 8x repo is not prepared with correct 
commands to update the 'main' repos properly. So each time it asks you to do 
stuff on 'master'/unstable branch you must instead manually adapt andd perform 
those steps on the new apache/lucene and apache/solr repos.

Jan

> 10. okt. 2021 kl. 13:45 skrev Mayya Sharipova :
> 
> Hi Houston,
> Thank you for bringing this to my attention, I've corrected the 8.10.1 
> changelog for all the branches.
> 
> Thanks a lot. 
> 
> On Fri, Oct 8, 2021 at 11:44 PM Houston Putman  > wrote:
> Hey Mayya,
> 
> I think there are some issues with the lucene changelog entries in 8.10.1 
> across various branches (branch_8_10, branch_8x, and main).
> I don't see LUCENE-10119, and LUCENE-10126 is marked as an 8.11.0 entry in at 
> least branch_8x.
> 
> - Houston
> 
> On Thu, Oct 7, 2021 at 9:32 PM Mayya Sharipova 
>  wrote:
> Hello everyone,
> 
> I am now preparing for a bugfix release from branch branch_8_10
> 
> Please observe the normal rules for committing to this branch:
> 
> * Before committing to the branch, reply to this thread and argue
>   why the fix needs backporting and how long it will take.
> * All issues accepted for backporting should be marked with 8.10.1
>   in JIRA, and issues that should delay the release must be marked as Blocker
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Only Jira issues with Fix version 8.10.1 and priority "Blocker" will delay
>   a release candidate build.
> 
>  -
> Currently we have the following  committed for 8.10.1
> LUCENE-10119: Do not set single sort with search after
> LUCENE-10126: Fix competitive iterator wrongly skip docs
> SOLR-15572: Fix a test failure caused by simplistic line parsing.
> SOLR-15665: Move polling logic under main
> 
> -
> We have the following bug fixes already resolved in 8.11. 
> Does anyone from the list below want to backport their fixes for 8.10.1 
> release as well?  Please let me know by Monday
> 
> * LUCENE-10110: MultiCollector now handles single leaf collector that wants 
> to skip low-scoring hits but the combined score mode doesn't allow it. (Jim 
> Ferenczi)
> * LUCENE-10111: Missing calculating the bytes used of DocsWithFieldSet in 
> NormValuesWriter. (Lu Xugang)
> * LUCENE-10116: Missing calculating the bytes used of DocsWithFieldSetand 
> currentValues in SortedSetDocValuesWriter. (Lu Xugang)
> * LUCENE-10070 Skip deleted docs when accumulating facet counts for all docs. 
> (Ankur Goel, Greg Miller)
> * LUCENE-10134: ConcurrentSortedSetDocValuesFacetCounts shouldn't share 
> liveDocs Bits across threads. (Ankur Goel)
> * SOLR-15626: Config-read permission does not allow access to 
> /solr/admin/configs?action=LIST  (Jon Senchyna)
> 
> 
> Thanks.
> 
> 

Re: Now that 8.10 is out ... let's get rolling on 9!

[Jan Høydahl]

I don't think the wizard in lucene-solr repo is prepared to check out the new 
solr.git/main and lucene.git/main to run addVersion and backcompat stuff, so 
this likely needs to be done manually during an 8.x release?

Jan

> 30. sep. 2021 kl. 17:25 skrev Timothy Potter :
> 
> I don't know what creates that 8.10 version constant? I didn't skip
> any steps afaik except for this
> https://issues.apache.org/jira/browse/LUCENE-10131 ... could this step
> failing be the cause of the missing version 8.10?
> 
> On Thu, Sep 30, 2021 at 5:45 AM Alan Woodward  wrote:
>> 
>> +1 to start pushing for a 9.0 release.
>> 
>> There isn’t an 8.10 version constant in the 9.0 branch at the moment - are 
>> there some release tasks that have been missed?
>> 
>>> On 29 Sep 2021, at 17:58, Timothy Potter  wrote:
>>> 
>>> Hi Folks,
>>> 
>>> Having just finished up the 8.10 release, it feels like this is a good
>>> time to start pushing harder for a 9.0 release.
>>> 
>>> There are so many improvements in the 9 (main) branches and
>>> backporting features to 8x is becoming onerous. I realize Solr needs a
>>> Lucene 9 release before it can proceed. I'm seeing one open blocker on
>>> the Lucene side: https://issues.apache.org/jira/browse/LUCENE-8638
>>> 
>>> Can we at least start to nail down a more concrete timeline on a 9.0 
>>> release?
>>> 
>>> Cheers,
>>> Tim
>>> 
>>> -
>>> 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
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
> 


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

Re: Lucene 9.0 release

[Jan Høydahl]

+1

Blockers seem to be done with. So I guess we just need an RM to get the ball 
rolling? :)

I know that the Release Wizard in new Lucene repo needs some updates 
https://issues.apache.org/jira/browse/LUCENE-9809 - I may help some with that...

Cross-ref other 9.0 release mail-threads: 
- "Now that 8.10 is out ... let's get rolling on 9!" 
https://lists.apache.org/thread.html/r868028d42a19ae02d5bbe2e3329da26869045002b9bb4760b8056c56%40%3Cdev.lucene.apache.org%3E
- "9.0 release": 
https://lists.apache.org/thread.html/r7bef0af668860fdbfedb4b58261efd01d9fb26dc280915284c121065%40%3Cdev.lucene.apache.org%3E

Jan

> 17. aug. 2021 kl. 11:13 skrev Adrien Grand :
> 
> +1 to your suggestions
> 
> I just commented on LUCENE-9959 
>  to suggest reverting 
> since the changes are currently half baked and I don't think that they should 
> block 9.0. There are no other blockers left to my knowledge.
> 
> On Sat, Aug 14, 2021 at 6:24 PM Michael Sokolov  > wrote:
> It's been two years since our last release, we had lots of +1 when we
> raised this last December, and IMO we are close to baked at this
> point.
> 
> I checked JIRA and found two remaining Blockers
> 
> 1. https://issues.apache.org/jira/browse/LUCENE-10016 
> 
> VectorReader.search needs rethought, o.a.l.search integration?
> 2. https://issues.apache.org/jira/browse/LUCENE-8638 
>  Remove deprecated
> code in main
> 
> The first one is very close to resolved;
> 
> On the deprecations, the issue has lingered for 1-1/2 years now, and
> some progress has been made, but more work remains. Some new
> deprecations have been added since it was opened too. Maybe we make a
> concerted effort to clean out as much as we can, and then decide if
> it's enough? Anyway this seems to be the only outstanding issue, so
> let's see if we can make progress there
> 
> Q: any other blockers?
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Adrien

Re: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Jan Høydahl]

+1

SUCCESS! [1:09:04.477915]

Just ran smoke tester.

Jan

> 22. sep. 2021 kl. 17:41 skrev Timothy Potter :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.10.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.0-RC1-rev377e7349979f8e418eacf03f1379b3dfacf7cccb
> 
> The vote will be open for at least 72 hours i.e. until 2021-09-25 16:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (binding) SUCCESS! [0:56:24.357153]
> 
> 
> Lastly, for those interested in kicking the tires on Solr using
> Docker, I posted an *unofficial* Docker image built locally from the
> RC to: thelabdude/apache-solr-dev:8.10.0-rc1
> 
> We just released v0.4.0 of the Apache Solr Operator, so if you want to
> try out this RC on Kubernetes, you can use the following YAML config
> in your SolrCloud CR definition:
> 
> solrImage:
>  repository: thelabdude/apache-solr-dev
>  tag: 8.10.0-rc1
> 
> 
> Cheers,
> Tim
> 
> -
> 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: Soften Jira's note when opening new issues?

[Jan Høydahl]

+1

Jan

> 20. sep. 2021 kl. 10:32 skrev Adrien Grand :
> 
> Hello,
> 
> Jira gives the following note when opening an issue:
> 
> ```
> This project has a user mailing list and an IRC channel for support. Please 
> ensure that you have discussed your problem using one of those resources 
> BEFORE creating this ticket.
> ```
> 
> This can be quite intimidating for someone who has never worked with us 
> before, and we don't apply this logic for ourselves, for instance I feel free 
> to open JIRAs without discussing them first on IRC or dev@l.a.o. Given that 
> we are not seeing much irrelevant traffic on JIRA, I'd like to soften the 
> message to something like below:
> 
> ```
> If you are looking for support, or if you are not sure whether the behavior 
> that you are observing is expected or not, please discuss your problem on the 
> user mailing-list instead before creating a ticket.
> ```
> 
> What do you think?
> 
> -- 
> Adrien


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

Re: New branch and feature freeze for Lucene/Solr 8.10.0

[Jan Høydahl]

That was not my point, there are several choices - this from 2020 which also 
work ootb: https://pypi.org/project/java-manifest/
It has TWO stars :), conforms to the specs and solves our needs in pure 
python... If other tools cannot follow a spec then IMO that's their problem, 
not ours.

Jan

> 17. sep. 2021 kl. 13:46 skrev Robert Muir :
> 
> Sure, but that package is archived/read-only, GPLv3. with 3 watchers and 1 
> star.
> 
> On Fri, Sep 17, 2021 at 4:27 AM Jan Høydahl  wrote:
>> 
>> Let's just follow the spec and move on.
>> 
>> Just tested this python package, which has no problem parsing the 
>> problematic manifest https://pypi.org/project/jarmanifest/
>> 
>>>>> manifest.getAttributes("/tmp/lucene-manifest.mf")
>> [{'implementationversion': '9.0.0-SNAPSHOT 
>> de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details omitted]'}]
>> 
>> Jan
>> 
>> 17. sep. 2021 kl. 09:32 skrev Dawid Weiss :
>> 
>> 
>> We could do a few things to keep everyone happy -
>> 
>> 1) keep abbreviated hash in the Implementat-Version and use a separate 
>> manifest entry to store a full hash.
>> 2) use a longer version for git show (abbrev=num) so that the chance of 
>> collisions in the future is minimized. It's still not a full hash but a
>> long(er) forced prefix.
>> 
>> D.
>> 
>> On Fri, Sep 17, 2021 at 12:21 AM Chris Hostetter  
>> wrote:
>>> 
>>> 
>>> : I was referring to doing this with languages other than java.
>>> :
>>> : I'm also assuming that exceeding this limit is going to cause indirect
>>> : hassles for users of lucene, e.g. breaking various security / supply
>>> : chain tools. We know a lot of these are total crap but people in the
>>> : corporate world have to suffer under them.
>>> 
>>> Just to be clear -- our 'Implementation-Version:' has been exceeding the
>>> 72 byte "single line" limit for a LONG time -- worrying about how
>>> "security / supply chain" tools will handle parsing that line now seems
>>> kind of silly...
>>> 
>>> If tools can't handle a line wrap in the 8.10 jars, then they haven't
>>> been able to handle the line wrap since we switched from svn to git (when
>>> the Implementation Version values switched from being based svn version#
>>> to git sha)
>>> 
>>> The *ONLY* thing that's new here is where in the value the line wrap
>>> happens (with 8.10.0 it happens in the middle of the SHA) and that our
>>> smoketest tool isn't smart enough to parse the values properly.
>>> 
>>> This is not even the first time we've even had a conversation about the
>>> smoke tester and Implementation Version line wraps: LUCENE-7023.
>>> 
>>> 
>>> : Its super-easy to use a short hash here and avoid problems.
>>> 
>>> 
>>> There is however an actual and practical downside to switching our
>>> implementation version to using a "short" SHA, and that's that we would
>>> lose the ability to garuntee that the information in the
>>> Implementation-Version uniquely identifies what commit a given jar was
>>> built from.  Multiple commits with the same short(end) hash are possible
>>> -- Multiple commits with identical (full) commits is not.
>>> 
>>> Folks may think that using git tags is useful enough for figuring this
>>> out from official releases, but being able to look at the jar metadata
>>> from arbitrary builds off of arbitrary branches and sanity check where
>>> exactly they come from has been very useful to me for 10+ years.
>>> 
>>> 
>>> : On Thu, Sep 16, 2021 at 3:03 AM Dawid Weiss  wrote:
>>> : >
>>> : > Jar command doesn't have it, true. But it's fairly trivial to do, even
>>> : > with an inline snippet like this one?
>>> : >
>>> : > public class PrintManifest {
>>> : >   public static void main(String[] jars) throws IOException {
>>> : > for (var jar : jars) {
>>> : >   var manifest = new JarFile(Paths.get(jar).toFile()).getManifest();
>>> : >   var attrs = manifest.getMainAttributes();
>>> : >   System.out.println(jar + ": " + 
>>> attrs.getValue("Implementation-Version"));
>>> : > }
>>> : >   }
>>> : > }
>>> : >
>>> : > I have this in my lucene-core-9.0.0-SNAPSHOT.jar:
>>> : >
>>> : > Implementation-Version: 9

Re: New branch and feature freeze for Lucene/Solr 8.10.0

[Jan Høydahl]

Let's just follow the spec and move on.

Just tested this python package, which has no problem parsing the problematic 
manifest https://pypi.org/project/jarmanifest/

>>> manifest.getAttributes("/tmp/lucene-manifest.mf")
[{'implementationversion': '9.0.0-SNAPSHOT 
de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details omitted]'}]

Jan

> 17. sep. 2021 kl. 09:32 skrev Dawid Weiss :
> 
> 
> We could do a few things to keep everyone happy - 
> 
> 1) keep abbreviated hash in the Implementat-Version and use a separate 
> manifest entry to store a full hash.
> 2) use a longer version for git show (abbrev=num) so that the chance of 
> collisions in the future is minimized. It's still not a full hash but a 
> long(er) forced prefix.
> 
> D.
> 
> On Fri, Sep 17, 2021 at 12:21 AM Chris Hostetter  > wrote:
> 
> : I was referring to doing this with languages other than java.
> : 
> : I'm also assuming that exceeding this limit is going to cause indirect
> : hassles for users of lucene, e.g. breaking various security / supply
> : chain tools. We know a lot of these are total crap but people in the
> : corporate world have to suffer under them.
> 
> Just to be clear -- our 'Implementation-Version:' has been exceeding the 
> 72 byte "single line" limit for a LONG time -- worrying about how 
> "security / supply chain" tools will handle parsing that line now seems 
> kind of silly...
> 
> If tools can't handle a line wrap in the 8.10 jars, then they haven't 
> been able to handle the line wrap since we switched from svn to git (when
> the Implementation Version values switched from being based svn version# 
> to git sha)
> 
> The *ONLY* thing that's new here is where in the value the line wrap 
> happens (with 8.10.0 it happens in the middle of the SHA) and that our 
> smoketest tool isn't smart enough to parse the values properly.
> 
> This is not even the first time we've even had a conversation about the 
> smoke tester and Implementation Version line wraps: LUCENE-7023.
> 
> 
> : Its super-easy to use a short hash here and avoid problems.
> 
> 
> There is however an actual and practical downside to switching our 
> implementation version to using a "short" SHA, and that's that we would 
> lose the ability to garuntee that the information in the 
> Implementation-Version uniquely identifies what commit a given jar was 
> built from.  Multiple commits with the same short(end) hash are possible 
> -- Multiple commits with identical (full) commits is not.
> 
> Folks may think that using git tags is useful enough for figuring this 
> out from official releases, but being able to look at the jar metadata 
> from arbitrary builds off of arbitrary branches and sanity check where 
> exactly they come from has been very useful to me for 10+ years.
> 
> 
> : On Thu, Sep 16, 2021 at 3:03 AM Dawid Weiss  > wrote:
> : >
> : > Jar command doesn't have it, true. But it's fairly trivial to do, even
> : > with an inline snippet like this one?
> : >
> : > public class PrintManifest {
> : >   public static void main(String[] jars) throws IOException {
> : > for (var jar : jars) {
> : >   var manifest = new JarFile(Paths.get(jar).toFile()).getManifest();
> : >   var attrs = manifest.getMainAttributes();
> : >   System.out.println(jar + ": " + 
> attrs.getValue("Implementation-Version"));
> : > }
> : >   }
> : > }
> : >
> : > I have this in my lucene-core-9.0.0-SNAPSHOT.jar:
> : >
> : > Implementation-Version: 9.0.0-SNAPSHOT de45b68c909815ce5ea7b6b9e1a2ce337
> : >  5b6334d [snapshot build, details omitted]
> : >
> : > and running:
> : >
> : > java PrintManifest.java lucene-core-9.0.0-SNAPSHOT.jar
> : >
> : > shows:
> : >
> : > lucene-core-9.0.0-SNAPSHOT.jar: 9.0.0-SNAPSHOT
> : > de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details
> : > omitted]
> : >
> : > This seems easier to me than trying to remember and keep the length of
> : > that line shorter than an arbitrary limit.
> : >
> : > Dawid
> : >
> : >
> : > On Wed, Sep 15, 2021 at 9:46 PM Robert Muir  > wrote:
> : > >
> : > > But its irrelevant that is "valid" when virtually no tools match it.
> : > >
> : > > In other words, I'd agree with you if the "jar" command had some
> : > > ability to read these manifests and print stuff to stdout, e.g. if
> : > > there was ANY interop at all here.
> : > >
> : > > But there isn't. So IMO it makes no sense to cause confusion and chaos
> : > > by adding an unnecessarily long git commit hash.
> : > >
> : > > On Wed, Sep 15, 2021 at 3:26 PM Dawid Weiss  > wrote:
> : > > >
> : > > >
> : > > > This is valid manifest line-breaking though... Can we read the 
> manifest properly on the smoke tester side somehow (for example, run a Java 
> process that reads and extracts the required attribute)? This way we wouldn't 
> care about the implementation details of how manifest wraps the lines (or 

Re: Welcome Mayya Sharipova to the Lucene PMC

[Jan Høydahl]

Welcome Mayya!

Jan

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

Re: Propose changing the "dist" layout

[Jan Høydahl]

When we collapse the solr/solr structure I hope we can keep the number of 
top-level folders in git to a minimum. There are too many already, so adding 
all contribs don’t help.

I hope the cobtribs will be converted to 1st party packages soon, so perhaps 
“plugins” or “packages” is a good top level folder name?

Those that are not yet converted can stay in “contribs”? 

Can we make solr-exporter a separate git repo? With separate artifacts and 
separate docker image. Don’t know if that means it must also be a full sub 
project?

Jan Høydahl

> 11. jun. 2021 kl. 22:46 skrev David Smiley :
> 
> 
> We (all?) agree to do away with "contrib" :-). 
> I think a folder grouping the modules (that which can plug inside Solr) is 
> useful as there are a number of them -- as such this is a nice organization 
> IMO.  There's a bunch of other stuff at the top level and I'd rather not 
> intermix all our modules at this layer.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Fri, Jun 11, 2021 at 4:41 PM Mike Drob  wrote:
>> We can have modules, but why do they need to be in an additional folder 
>> deep? Why not just have langid next to solrj and core? Contrib to me 
>> connotes experimental or unsupported, which these things are decidedly not. 
>> 
>>> On Fri, Jun 11, 2021 at 2:59 PM David Smiley  wrote:
>>> The contrib folder is just a folder of modules -- optional plugins for 
>>> solr-core.  IMO we should simply rename "contrib" to "modules".  I think 
>>> the only non-module in there is the prometheus exporter which could move 
>>> out.  Mike, I'm not sure if you have a different notion of what "module" 
>>> is?  I believe most of us would be happy to move away from "contrib" 
>>> wording, anyway.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> 
>>>> On Fri, Jun 11, 2021 at 3:03 PM Mike Drob  wrote:
>>>> I think related to this, I would like to see some "contibs" moved out
>>>> from the contrib folder and into proper modules. Right now the
>>>> definition of contrib seems to be anything that isn't core or solrj,
>>>> but maybe there is room for a backup module that has gcs and s3 and
>>>> hdfs all under it. LangId is already mentioned in our ref guide but we
>>>> pretend like it is always present and don't think of it as a contrib.
>>>> We kind of think of contrib as optional extra stuff, so maybe we call
>>>> the things what they are - plugins and extensions? Then we don't have
>>>> to think as hard about why certain things are showing up in which lib
>>>> folders.
>>>> 
>>>> Also, minor benefit, I would then be able to type c instead of
>>>> having to type cor to disambiguate from con in my terminal.
>>>> 
>>>> On Fri, Jun 11, 2021 at 8:09 AM David Smiley  wrote:
>>>> >
>>>> > I believe we can do a fair amount of re-organization pertaining to Jetty 
>>>> > without losing the Jetty configuration that I think is valuable to users 
>>>> > who want to tweak something.
>>>> >
>>>> > ~ David Smiley
>>>> > Apache Lucene/Solr Search Developer
>>>> > http://www.linkedin.com/in/davidwsmiley
>>>> >
>>>> >
>>>> > On Fri, Jun 11, 2021 at 8:01 AM Jan Høydahl  
>>>> > wrote:
>>>> >>
>>>> >> +1 to a cleanup here for 9.0. As clean and neat organization as 
>>>> >> possible. Perhaps rename "dist" -> "lib"?
>>>> >>
>>>> >> I wish we could get rid of the server (jetty) folder altogether, and 
>>>> >> move everything from server/solr-webapp/webapp/WEB-INF/lib to 
>>>> >> "lib/deps/". But that ties into custom boot-class, getting rid of 
>>>> >> web.xml and building Jetty context in Java code.. I'm willing to help 
>>>> >> here if others also want to go this direction. This would further hide 
>>>> >> Jetty as an impl detail and let us organize stuff more freely.
>>>> >>
>>>> >> Jan
>>>> >>
>>>> >> 11. jun. 2021 kl. 13:29 skrev David Smiley :
>>>> >>
>>>> >> Bumping this conversation up, based on recent communication.  I have 
>>>> >> yet to take action but rea

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Jan Høydahl]

Does it reproduce for you? Are you suspecting a bug in Solr that we cannot 
ship, or only a bug in the smoketester py itself? The -1 should be about the 
released bits, not about other tooling?
My JVM is OpenJDK 64-Bit Server VM (AdoptOpenJDK)(build 25.292-b10, mixed mode)

Jan

> 11. jun. 2021 kl. 13:48 skrev Robert Muir :
> 
> Jan, I'm using the same automated smoketester as everyone else. It
> fails, so my vote is -1.
> 
> On Fri, Jun 11, 2021 at 7:22 AM Jan Høydahl  wrote:
>> 
>> Tested on MacOS (Intel), No other verification than smoketester done
>> 
>> SUCCESS! [1:08:19.953492]
>> 
>> +1
>> 
>> Robert - not sure if one test-run failure should cancel the build. Our 
>> smoketester and tests are sometimes a bit picky, and does not mean that the 
>> artifacts are faulty.
>> 
>> Jan
>> 
>> 11. jun. 2021 kl. 04:14 skrev Mayya Sharipova 
>> :
>> 
>> Please vote for release candidate 1 for Lucene/Solr 8.9.0
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
>> 
>> The vote will be open for at least 72 hours i.e. until 2021-06-16 02:00 UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1
>> SUCCESS! [0:01:43.815224]
>> 
>> 
> 
> -
> 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: Propose changing the "dist" layout

[Jan Høydahl]

+1 to a cleanup here for 9.0. As clean and neat organization as possible. 
Perhaps rename "dist" -> "lib"?

I wish we could get rid of the server (jetty) folder altogether, and move 
everything from server/solr-webapp/webapp/WEB-INF/lib to "lib/deps/". But that 
ties into custom boot-class, getting rid of web.xml and building Jetty context 
in Java code.. I'm willing to help here if others also want to go this 
direction. This would further hide Jetty as an impl detail and let us organize 
stuff more freely.

Jan

> 11. jun. 2021 kl. 13:29 skrev David Smiley :
> 
> Bumping this conversation up, based on recent communication.  I have yet to 
> take action but really any of us can.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Mon, Nov 23, 2020 at 8:48 AM David Smiley  > wrote:
> I'll proceed on this with lazy consensus.  I suspect most of us don't care, 
> unsurprisingly since I doubt anyone has any fondness for the "dist" folder.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> 
> 
> On Sun, Nov 15, 2020 at 7:31 AM Erick Erickson  > wrote:
> Well, Solr has grown “organically” so some things just _are_, like sunrises 
> and plagues ;)
> 
> On a serious note, AFAIC rearrange as you see fit. I wonder how much of this 
> is left over from the war days? Anything that’s lasted through all the 
> transformations Solr has is bound to need cleaning up betimes.
> 
> How would it relate to splitting Solr off into its own TLP? On the surface, 
> I’d guess the two efforts would be orthogonal, I mention it just in case 
> rearranging the layout would make that task easier or harder...
> 
> > On Nov 15, 2020, at 12:18 AM, David Smiley  > > wrote:
> > 
> > I've been doing a bit of dependency work in one of our contribs, and 
> > observing more closely than usual exactly what we produce in the 
> > distribution layout (result of gradlew assemble).  There are some tricks 
> > Dawid did in gradle/solr/packaging.gradle to pull off this stunt to keep 
> > things as they have been for many years.  The distribution layout is 
> > awkward, I think.  We produce this "dist" folder at the top level that has 
> > every JAR this project produces, *even contribs*.  But why?  I think 
> > contribs should keep to themselves.  It's ridiculous that /contribs/ltr/ is 
> > empty except for a README.txt... IMO it ought to have the JAR in a "lib" 
> > subdirectory there mixed with its dependencies (LTR has none but others 
> > sure do).  Today, each contrib's JAR is in "/dist".  And what about SolrJ?  
> > I think SolrJ is important enough that it deserves its very own top-level 
> > directory "solrj", and like the contribs, with a "lib" alongside it.  Maybe 
> > Solrj's optional dependencies could be in a lib-optional dir next to it or 
> > lib/opt/ (beneath it).  Then... we don't need "dist" at all.  It contains 
> > the solr-core JAR but this is redundant.  Furthermore, the server webapp 
> > could be configured to add the SolrJ libs so that we don't need to 
> > redundantly put any of them in the distribution.  There might be some 
> > duplicated jars overall, but not many.  Logging libs might be explicitly 
> > excluded so that they are only in one spot.  (Logging in Java is a mess)
> > 
> > WDYT?
> > 
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley 
> > 
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Jan Høydahl]

Tested on MacOS (Intel), No other verification than smoketester done

SUCCESS! [1:08:19.953492]

+1

Robert - not sure if one test-run failure should cancel the build. Our 
smoketester and tests are sometimes a bit picky, and does not mean that the 
artifacts are faulty.

Jan

> 11. jun. 2021 kl. 04:14 skrev Mayya Sharipova 
> :
> 
> Please vote for release candidate 1 for Lucene/Solr 8.9.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
>  
> 
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
>  
> 
> 
> The vote will be open for at least 72 hours i.e. until 2021-06-16 02:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> SUCCESS! [0:01:43.815224]

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

[Jan Høydahl]

Thanks Mayya. I took a stab at summarizing Solr highlights in 
https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote89 

Jan

> 6. jun. 2021 kl. 16:43 skrev Mayya Sharipova 
> :
> 
> Hello everyone, I would appreciate help with with following for 8.9 release:
> Release Highlights. I gave it a try for Lucene (but I don't have experience 
> to judge what qualifies as a release highlight, so please edit/remove/add). 
> Edits can be done here: Lucene Release Note 8.9 
> <https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote89>,  Solr 
> Release Note 8.9 
> <https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote89>. 
>  Resolve failures in Lucene-Solr-SmokeRelease-8.9 
> <http://lucene-solr-smokerelease-8.9/>,  currently fails with an error:
>[smoker]   File 
> "/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.9/dev-tools/scripts/smokeTestRelease.py",
>  line 125, in noJavaPackageClasses
>[smoker] raise RuntimeError('%s contains sheisty class "%s"' %  (desc, 
> name2))
>[smoker] RuntimeError: JAR file 
> "/home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-SmokeRelease-8.9/lucene/build/smokeTestRelease/tmp/unpack/solr-8.9.0/contrib/gcs-repository/lib/jsr305-3.0.2.jar"
>  contains sheisty class "javax/annotation/CheckForNull.class"
> 
> Thank you in advance.
> 
> On Fri, Jun 4, 2021 at 9:40 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> SOLR-15316 / PR 2502 is now merged to branch_8_9
> 
> Jan
> 
>> 3. jun. 2021 kl. 20:53 skrev Mayya Sharipova 
>> > <mailto:mayya.sharip...@elastic.co.INVALID>>:
>> 
>> I can wait till this PR 2502 is backported (hopefully by tomorrow? and 
>> hopefully will be the last item to wait for).
>> And tomorrow I will try to build a RC.
>> 
>> 
>> 
>> On Thu, Jun 3, 2021 at 8:57 AM Cassandra Targett > <mailto:casstarg...@gmail.com>> wrote:
>> It’s OK with me, but I’m not really in a position to understand the changes 
>> and/or test it. And while we have a branch, I’m not clear on when the first 
>> RC is planned, so Mayya should weigh in I think.
>> 
>> Cassandra
>> On Jun 3, 2021, 5:49 AM -0500, Jan Høydahl > <mailto:jan@cominvent.com>>, wrote:
>>> Mayya, Cassandra, I'd like to merge the Jetty upgrade, SOLR-15316 to 
>>> branch_8x and branch_8_9. See backport PR 
>>> https://github.com/apache/lucene-solr/pull/2502 
>>> <https://github.com/apache/lucene-solr/pull/2502>
>>> Is that ok?
>>> 
>>> Jan
>>> 
>>>> 2. jun. 2021 kl. 01:00 skrev Jan Høydahl >>> <mailto:jan@cominvent.com>>:
>>>> 
>>>> Cassandra,
>>>> 
>>>> Thanks for spotting the Jetty JIRA (SOLR-15316 
>>>> <https://issues.apache.org/jira/browse/SOLR-15316>). I put up a quck PR 
>>>> <https://github.com/apache/solr/pull/157> 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 >>>> <mailto:casstarg...@gmail.com>>:
>>>>> 
>>>>> 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 
>>>>> <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 >>>> <mailto:jan@cominvent.com>>, wrote:
>>>>>> Let's not hold up the r

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

[Jan Høydahl]

SOLR-15316 / PR 2502 is now merged to branch_8_9

Jan

> 3. jun. 2021 kl. 20:53 skrev Mayya Sharipova 
> :
> 
> I can wait till this PR 2502 is backported (hopefully by tomorrow? and 
> hopefully will be the last item to wait for).
> And tomorrow I will try to build a RC.
> 
> 
> 
> On Thu, Jun 3, 2021 at 8:57 AM Cassandra Targett  <mailto:casstarg...@gmail.com>> wrote:
> It’s OK with me, but I’m not really in a position to understand the changes 
> and/or test it. And while we have a branch, I’m not clear on when the first 
> RC is planned, so Mayya should weigh in I think.
> 
> Cassandra
> On Jun 3, 2021, 5:49 AM -0500, Jan Høydahl  <mailto:jan@cominvent.com>>, wrote:
>> Mayya, Cassandra, I'd like to merge the Jetty upgrade, SOLR-15316 to 
>> branch_8x and branch_8_9. See backport PR 
>> https://github.com/apache/lucene-solr/pull/2502 
>> <https://github.com/apache/lucene-solr/pull/2502>
>> Is that ok?
>> 
>> Jan
>> 
>>> 2. jun. 2021 kl. 01:00 skrev Jan Høydahl >> <mailto:jan@cominvent.com>>:
>>> 
>>> Cassandra,
>>> 
>>> Thanks for spotting the Jetty JIRA (SOLR-15316 
>>> <https://issues.apache.org/jira/browse/SOLR-15316>). I put up a quck PR 
>>> <https://github.com/apache/solr/pull/157> 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 >>> <mailto:casstarg...@gmail.com>>:
>>>> 
>>>> 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 
>>>> <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 >>> <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 >>>>> <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, >>>>> <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 
>>>>>&

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

[Jan Høydahl]

Mayya, Cassandra, I'd like to merge the Jetty upgrade, SOLR-15316 to branch_8x 
and branch_8_9. See backport PR https://github.com/apache/lucene-solr/pull/2502
Is that ok?

Jan

> 2. jun. 2021 kl. 01:00 skrev Jan Høydahl :
> 
> Cassandra,
> 
> Thanks for spotting the Jetty JIRA (SOLR-15316 
> <https://issues.apache.org/jira/browse/SOLR-15316>). I put up a quck PR 
> <https://github.com/apache/solr/pull/157> 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 > <mailto:casstarg...@gmail.com>>:
>> 
>> 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 
>> <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 > <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 >>> <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, >>> <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 >>>> <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 

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

[Jan Høydahl]

Cassandra,

Thanks for spotting the Jetty JIRA (SOLR-15316 
<https://issues.apache.org/jira/browse/SOLR-15316>). I put up a quck PR 
<https://github.com/apache/solr/pull/157> 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 
> <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 >> <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, >> <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 >>> <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 >>>> <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

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: 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
 
<https://lists.apache.org/thread.html/r9875b53aeaebca8678ee0127562d8a35c7938906fbd318ac17ba011d@%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 <mailto: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 
> <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  <mailto:a...@getopt.org>> 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 inadve

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: Welcome Greg Miller as Lucene committer

[Jan Høydahl]

Welcome, Greg!

Jan

> 29. mai 2021 kl. 21:47 skrev Adrien Grand :
> 
> 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: Release Lucene/Solr 8.9.0 should we have it soon

[Jan Høydahl]

+1 to a 8.9 release

I'm working on a few Solr backports that will land soon.

Jan

> 12. mai 2021 kl. 09:46 skrev Peter Gromov 
> :
> 
> I can try backporting Hunspell improvements 
> (https://issues.apache.org/jira/browse/LUCENE-9687 
> ) to 8.x, unless you think 
> it's too large a change.
> 
> On Tue, May 11, 2021 at 7: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:
> I'm also looking to find time to get 
> 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  > 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  > wrote:
> +1
> 
> Mayya, are you volunteering to be the release manager?
> 
> Le jeu. 6 mai 2021 à 18:06, Ishan Chattopadhyaya  > a écrit :
> +1
> 
> On Thu, May 6, 2021 at 7:50 PM Mayya Sharipova 
>  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  (work)
> http://www.the111shift.com  (play)

Re: Separate git repo(s) for Solr modules

[Jan Høydahl]

Folks

1. This is the dev@lucene list, please move discussions over to dev@solr
2. The thread about simultaneous lucene/solr dev is in dev@solr with subject 
"Proposal to pin the Lucene snapshot version on main"
3. If you want to discuss whether Solr should be a monorepo or multiple repos, 
start a new thread at dev@solr

Jan

> 4. mai 2021 kl. 20:15 skrev Dawid Weiss :
> 
> A submodule is nothing more than a checkout of a different repository
> (at a given commit). It's not a fork, unless you clone that repository
> and place it somewhere else.
> 
> In any case, I agree Solr should stick to official Lucene releases. If
> there is a need to have a "sticky" intermediate tagged release of
> Lucene for internal (development branch) purposes, Cassandra showed
> what seems like an adequate place to host it until an official Lucene
> release is out.
> 
> If you're working on both projects at once and wish to modify code in both,
> IDEs in many cases help you out by substituting code/classpaths from multiple
> sources. I know Eclipse can do it, I'm pretty sure you could try to do
> the same with
> IntelliJ.
> 
> Dawid
> 
> On Tue, May 4, 2021 at 4:40 PM Atri Sharma  wrote:
>> 
>> I am a bit confused -- if Lucene was to become a sub module of Solr, are we 
>> essentially forking Lucene?
>> 
>> I am in agreement with Ilan and Houston -- Solr should be depending on 
>> Lucene only as a dependency.
>> 
>> 
>> On Tue, 4 May 2021, 19:52 Noble Paul,  wrote:
>>> 
>>> @Ilan Ginzburg
>>> 
>>> I don't think the project split is counter productive because we have 
>>> lucene as a sub module. Solr does not use lucene like a simple library. 
>>> It's an integral part of Solr
>>> 
>>> 
>>> On Tue, May 4, 2021 at 10:02 PM Ilan Ginzburg  wrote:
 
 As with any dependency on any project, you update the dependency project 
 first then consume the updated dependency in Solr.
 
 If the idea is to be able to modify Lucene and Solr in parallel, then the 
 project split is counterproductive.
 
 From the Solr perspective, Lucene and Zookerper are really two “similar”
 dependencies and IMO we should think about them in that way.
 
 Ilan
 
 On Tue 4 May 2021 at 09:45, Noble Paul  wrote:
> 
> @Houston
> 
> So, Are you suggesting we should not do that ?
> 
> On Tue, May 4, 2021 at 2:35 PM Houston Putman  
> wrote:
>> 
>> In the future we wont be able to “work on both at the same time”, once 
>> Lucene 9 is cut. Why not pull that bandaid now?
>> 
>> On Mon, May 3, 2021 at 11:32 PM Noble Paul  wrote:
>>> 
>>> I'm still struggling to understand the workflow when I'm working on a 
>>> feature that spans lucene and solr.
>>> 
>>> I'm yet to see an argument against sub-modules
>>> 
>>> On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski  
>>> wrote:
 
> Shoving such a component into lucene-solr repo makes no sense, given 
> its branching strategy is based on master / branch_8x
 
 I get how this could cause issues - I def hadn't thought much about
 multi-version support and branching.  But I don't think moving plugins
 to a separate repo solves that problem for us.  If our first class
 plugins are set up to have different release "lines" that don't line
 up with major Solr versions, it's only a matter of time before two of
 those plugins have branch requirements that conflict.  Unless I'm
 missing something here?
 
> I'd prefer that a module only leave our "contribs" area when the 
> concerns/limitations become real.  Doing it prematurely could lead to 
> atrophy of the module
 
 +1 to David's comment.   I def hadn't considered the branching-scheme
 issues that Ishan brought up in his last reply, and they seem like
 valid concerns to me.  But the risk and the downsides of "atrophy" are
 serious enough that I'd vote to not risk them until this starts to
 cause us issues in practice.  Even if, for now, that means we won't be
 able to build a single plugin jar that supports (e.g.) 3 major Solr
 versions.  IMO that's a much smaller loss.
 
 On Tue, Feb 16, 2021 at 9:40 AM David Smiley  
 wrote:
> 
> On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh 
>  wrote:
>> 
>> Testing across multiple versions is always very difficult ;-).  I 
>> recently saw this very interesting approach to using our Dockerized 
>> Solr’s to test a component against a number of previous versions of 
>> Solr.  https://github.com/querqy/querqy/pull/147. I’m hopeful it 
>> could be a model for other packages to adopt.
> 
> 
> Thanks for the link to that Querqy PR.  That is *very* similar to 
> what I do at work (minus multi-version testing), and also 

Re: Moving usage documentation of Luke to Lucene Website

[Jan Høydahl]

Hi

That could be feasible. Have a look at the website git repo at 
https://github.com/apache/lucene-site.
Should be fairly easy to move the Markdown files from github to this site, 
which also accepts Markdown...

Jan

> 30. apr. 2021 kl. 08:41 skrev Michael Wechner :
> 
> Hi
> 
> I just noticed that Luke became a Lucene Module
> 
> https://github.com/DmitryKey/luke#important-notice
> https://mocobeta.medium.com/luke-become-an-apache-lucene-module-as-of-lucene-8-1-7d139c998b2
> https://lucene.apache.org/core/8_8_2/luke/index.html
> 
> Wouldn't it make sense to move the "Usage documentation of Luke" from 
> https://github.com/DmitryKey/luke#luke to somewhere inside lucene.apache.org?
> 
> Thanks
> 
> Michael
> 
> 
> -
> 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: [RESULT] [VOTE] Release Lucene/Solr 8.8.2 RC1

[Jan Høydahl]

Sorry, my vote was +1, forgot to add an explicit +1 to my vote. 

Jan

> 12. apr. 2021 kl. 17:43 skrev Mike Drob :
> 
> It's been >72h since the vote was initiated and the result is:
> 
> +1  5 (Mike Drob, Tim Potter, Anshum Gupta, Bruno Roustant, Ignacio Vera)
>  0  2 (Uwe Schindler, Jan Høydahl)
> -1  0
> 
> This vote has PASSED


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

Re: Welcome Peter Gromov as Lucene committer

[Jan Høydahl]

Welcome Peter!

> 6. apr. 2021 kl. 19:47 skrev Robert Muir :
> 
> I'm pleased to announce that Peter Gromov has accepted the PMC's invitation 
> to become a committer.
> 
> Peter, the tradition is that new committers introduce themselves with a brief 
> bio.
> 
> Congratulations and welcome!
> 


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

Re: 9.0 release

[Jan Høydahl]

Hi,

Where are we at with the Lucene 9.0 release planning?

The git split is largely done. Not sure about the build.
Let's update the umbrella issue 
https://issues.apache.org/jira/browse/LUCENE-9375 
 for known remaining cleanup 
tasks.
The one on that list is releaseWizard, but as Adrien says there are also other 
scripts that need updating.

Jan

> 13. jan. 2021 kl. 15:10 skrev Adrien Grand :
> 
> +1 to start planning 9.0.
> 
> Since you mentioned the Gradle build, I believe that we still need to migrate 
> some of the release tooling from Ant to Gradle, e.g. 
> dev-tools/scripts/addBackcompatIndexes.py. These scripts are not easy to test 
> without actually doing a release so the 9.0 RM might have some debugging to 
> do.
> 
> 
> On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov  > wrote:
> Hi everyone, as we head into a new year full of optimism, is it time
> to start discussing the next major release? We released 8.0 on Jun 18,
> 2019, over 18 months ago. Since then we've switched to a gradle-based
> build. We have added vector-valued fields and an HNSW neighbor search
> algorithm for them.  At the same time Solr has been getting a major
> overhaul which should justify a release, I think? IIRC there was talk
> of making 9.0 be the first release of Solr as its own TLP. Is it time
> to start planning for that now?
> 
> -Mike
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org 
> 
> For additional commands, e-mail: dev-h...@lucene.apache.org 
> 
> 
> 
> 
> -- 
> Adrien

Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)

[Jan Høydahl]

Hi all,

Today, all the old git branches in lucene.git are gone.

If you like to sync up your local git checkout so you don't see those phantom 
branches, please run this command in your local checkout:

git fetch --prune origin

Jan

> 16. mar. 2021 kl. 16:04 skrev Jan Høydahl :
> 
> This time around I'll have Infra mute the emails to commits list during the 
> bulk change.
> I'll probably get around to this on Friday or Monday. If anyone wants to grab 
> this and do it earlier then that's ok with me.
> 
> Jan
> 
>> 15. mar. 2021 kl. 16:06 skrev Uwe Schindler > <mailto:u...@thetaphi.de>>:
>> 
>> Deleting unneeded tags is easy, so starting with the automatied script is 
>> fine.
>>  
>> I agree to remove those “orking” branches/tags in the lucene and solr repos. 
>> Once done, the disk space may reduce, as “git gc” will remove all refs.
>>  
>> Uwe
>>  
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de <https://www.thetaphi.de/>
>> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>>  
>> From: David Smiley mailto:dsmi...@apache.org>> 
>> Sent: Monday, March 15, 2021 3:30 PM
>> To: lucene-dev mailto:dev@lucene.apache.org>>
>> Subject: Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)
>>  
>> What's the point of even having a tag for "branch_8x", "branch_7x" etc.?  
>> Their very existence was fundamentally to commit code to, and were 
>> constantly moving forward as work happens.  They will still exist in 
>> lucene-solr repo, so "no history is lost" will be true as well.
>> Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for doing 
>> quick IDE comparisons to see how code changed.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley 
>> <http://www.linkedin.com/in/davidwsmiley>
>>  
>>  
>> On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl > <mailto:jan@cominvent.com>> wrote:
>>> Hi,
>>>  
>>> With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to 
>>> get rid of some clutter.
>>>  
>>> We  discussed on Slack and later her on list[1] the option of pruning all 
>>> the 112 old branches. It makes no sense to keep stale branch_x_y branches 
>>> in lucene.git repo, as any future 8.x or 7.x release will happen from 
>>> lucene-solr.git, so keeping them as branches in lucene.git is duplication 
>>> and only gives room for developer mistakes. If branch_8_8 does not exist in 
>>> lucene.git repo, noone will push to it, and rather remember to make a patch 
>>> for lucene-solr.git instead.
>>>  
>>> So my plan is to remove all branches in the new lucene.git repostiory and 
>>> leave only the "main" branch. We just did this in solr.git repo (SOLR-15253 
>>> [3]).
>>>  
>>> We'll do this by replacing each branch with a git tag, e.g. branch_8x will 
>>> be replaced with tag history/branches/lucene-solr/branch_8x. This is the 
>>> same procedure we did when moving from svn to git. No history is lost!
>>>  
>>> The script I intend to run in a few days is attached on LUCENE-9835 [2].
>>>  
>>> Should you have a work-in-progress on a branch currently scheduled for 
>>> removal, please reply here to excempt it from removal until it is merged.
>>> 
>>> After the removal you can run "git fetch --prune origin" to not see the 
>>> remote branches in your local clone.
>>> 
>>> PS: The lucene-solr.git repo, where 8.x development continues, will not be 
>>> affected.
>>>  
>>> [1] 
>>> https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E
>>>  
>>> <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>
>>> [2] https://issues.apache.org/jira/browse/LUCENE-9835 
>>> <https://issues.apache.org/jira/browse/LUCENE-9835> 
>>> [3] https://issues.apache.org/jira/browse/SOLR-15253 
>>> <https://issues.apache.org/jira/browse/SOLR-15253>

Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)

[Jan Høydahl]

This time around I'll have Infra mute the emails to commits list during the 
bulk change.
I'll probably get around to this on Friday or Monday. If anyone wants to grab 
this and do it earlier then that's ok with me.

Jan

> 15. mar. 2021 kl. 16:06 skrev Uwe Schindler :
> 
> Deleting unneeded tags is easy, so starting with the automatied script is 
> fine.
>  
> I agree to remove those “orking” branches/tags in the lucene and solr repos. 
> Once done, the disk space may reduce, as “git gc” will remove all refs.
>  
> Uwe
>  
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de <https://www.thetaphi.de/>
> eMail: u...@thetaphi.de <mailto:u...@thetaphi.de>
>  
> From: David Smiley  
> Sent: Monday, March 15, 2021 3:30 PM
> To: lucene-dev 
> Subject: Re: [NOTICE] Old git branches will be pruned (in lucene.git repo)
>  
> What's the point of even having a tag for "branch_8x", "branch_7x" etc.?  
> Their very existence was fundamentally to commit code to, and were constantly 
> moving forward as work happens.  They will still exist in lucene-solr repo, 
> so "no history is lost" will be true as well.
> Having tags for actual releases (e.g. for 8.8, 8.7, etc.) is great for doing 
> quick IDE comparisons to see how code changed.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley 
> <http://www.linkedin.com/in/davidwsmiley>
>  
>  
> On Mon, Mar 15, 2021 at 9:50 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
>> Hi,
>>  
>> With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to 
>> get rid of some clutter.
>>  
>> We  discussed on Slack and later her on list[1] the option of pruning all 
>> the 112 old branches. It makes no sense to keep stale branch_x_y branches in 
>> lucene.git repo, as any future 8.x or 7.x release will happen from 
>> lucene-solr.git, so keeping them as branches in lucene.git is duplication 
>> and only gives room for developer mistakes. If branch_8_8 does not exist in 
>> lucene.git repo, noone will push to it, and rather remember to make a patch 
>> for lucene-solr.git instead.
>>  
>> So my plan is to remove all branches in the new lucene.git repostiory and 
>> leave only the "main" branch. We just did this in solr.git repo (SOLR-15253 
>> [3]).
>>  
>> We'll do this by replacing each branch with a git tag, e.g. branch_8x will 
>> be replaced with tag history/branches/lucene-solr/branch_8x. This is the 
>> same procedure we did when moving from svn to git. No history is lost!
>>  
>> The script I intend to run in a few days is attached on LUCENE-9835 [2].
>>  
>> Should you have a work-in-progress on a branch currently scheduled for 
>> removal, please reply here to excempt it from removal until it is merged.
>> 
>> After the removal you can run "git fetch --prune origin" to not see the 
>> remote branches in your local clone.
>> 
>> PS: The lucene-solr.git repo, where 8.x development continues, will not be 
>> affected.
>>  
>> [1] 
>> https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41%40%3Cdev.lucene.apache.org%3E
>>  
>> <https://lists.apache.org/thread.html/rc5ac744aa8b081e1e0edb17281d7bb42398a04dcaf6f47421e4a6c41@%3Cdev.lucene.apache.org%3E>
>> [2] https://issues.apache.org/jira/browse/LUCENE-9835 
>> <https://issues.apache.org/jira/browse/LUCENE-9835> 
>> [3] https://issues.apache.org/jira/browse/SOLR-15253 
>> <https://issues.apache.org/jira/browse/SOLR-15253>

[NOTICE] Old git branches will be pruned (in lucene.git repo)

[Jan Høydahl]

Hi,

With the new lucene.git repo up and running, we (Uwe, Dawid and I) like to get 
rid of some clutter.

We  discussed on Slack and later her on list[1] the option of pruning all the 
112 old branches. It makes no sense to keep stale branch_x_y branches in 
lucene.git repo, as any future 8.x or 7.x release will happen from 
lucene-solr.git, so keeping them as branches in lucene.git is duplication and 
only gives room for developer mistakes. If branch_8_8 does not exist in 
lucene.git repo, noone will push to it, and rather remember to make a patch for 
lucene-solr.git instead.

So my plan is to remove all branches in the new lucene.git repostiory and leave 
only the "main" branch. We just did this in solr.git repo (SOLR-15253 [3]).

We'll do this by replacing each branch with a git tag, e.g. branch_8x will be 
replaced with tag history/branches/lucene-solr/branch_8x. This is the same 
procedure we did when moving from svn to git. No history is lost!

The script I intend to run in a few days is attached on LUCENE-9835 [2].

Should you have a work-in-progress on a branch currently scheduled for removal, 
please reply here to excempt it from removal until it is merged.

After the removal you can run "git fetch --prune origin" to not see the remote 
branches in your local clone.

PS: The lucene-solr.git repo, where 8.x development continues, will not be 
affected.

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

[2] https://issues.apache.org/jira/browse/LUCENE-9835 
[3] https://issues.apache.org/jira/browse/SOLR-15253

Re: Branch cleaning/ archiving

[Jan Høydahl]

I thought a simple git fetch would detect deleted branches?
Probably wise to send a mail to separate mail to dev@

-
Subject: [NOTICE] All branches will be gone on Monday

We plan to remove up all historic branches in the new solr.git repostiory, and 
leave
only the "main" branch. We'll do this by replacing the branch with a git tag, 
e.g.
branch_8x will be replaced with tag history/branches/lucene-solr/branch_8x.
This is the same procedure we did when moving from svn to git. No history is 
lost!

We encourage all committers to work on features in feature branches in your
private git fork instead of pushing your branches to the central repository.
For larger collaborative efforts like reference_branch and refactorings, it's ok
to use central branches.

Should you have a work-in-progress on a central feature branch, such as an
active PR against lucene-solr.git, please push the PR branch to your private
fork and re-create the PR in new repo using the private branch. All PRs will
need to be re-created anyway so this is a small extra step.

If you are aware of branches that should stay central, other than 
reference_impl_dev and reference_impl, please reply to this email.

The removal of these branches will happen on Monday March 15th.
After the removal you will need to run "git remote prune origin"

PS: The lucene-solr.git repo, where 8.x development continues, will not be 
affected.

-

> 11. mar. 2021 kl. 07:47 skrev Dawid Weiss :
> 
> This will also require people who already made their clones/ forks to
> prune their copy of the remote as this isn't done automatically.
> 
> git remote prune origin
> 
> Other than that -- looks good to me.
> 
> D.
> 
> On Wed, Mar 10, 2021 at 11:19 PM Jan Høydahl  wrote:
>> 
>> Yep, I updated it with a check that the command succeeded.
>> 
>> Jan
>> 
>> 10. mar. 2021 kl. 23:09 skrev Ilan Ginzburg :
>> 
>> Any risk in the script that command:
>> git push ${REMOTE} 
>> cominvent/$BRANCH:refs/tags/history/branches/lucene-solr/$BRANCH
>> errors out in some exotic way (?) but the script continues anyway and 
>> proceeds with the delete:
>> git push ${REMOTE} --delete $BRANCH
>> 
>> 
>> On Wed, Mar 10, 2021 at 10:35 PM Jan Høydahl  wrote:
>>> 
>>> Ok, I took a stab at this
>>> 
>>> We have 113 branches. Here is a script I prepared that will work directly 
>>> on a git remote, first creating the tag then deleting the branch.
>>> https://gist.github.com/80a7eea6bacd4e32646a7958d1e9a870
>>> 
>>> In the script I have added the list of branches that I propose to "archive".
>>> 
>>> Below that there is a commented section of branches that are reported as 
>>> "active" by GitHub that should probably stay for now
>>> Finally, we have some branches we might want to keep around for refernce?
>>> I'm not sure how useful it is to keep a branch in solr.git for, say 
>>> branch_8_8, as it will fall behind as branch_8_8 in lucene-solr.git gets 
>>> updated. So probably archive those as well?
>>> 
>>> The pure lucene branches like LUCENE-9004 won't need a tag at all I 
>>> suppose, but it won't hurt either.
>>> 
>>> Jan
>>> 
>>>> 10. mar. 2021 kl. 21:16 skrev Dawid Weiss :
>>>> 
>>>>> We already did this before, see list of existing tags (git tag -l)
>>>> 
>>>> I know, I did it, after all... :) This was a move from subversion
>>>> though... slightly different. Anyway - if you guys want to proceed
>>>> with this, please go ahead, I don't mind. A spring cleaning is needed
>>>> every couple of years... If we just leave the main branch it'll be
>>>> very elegant. People work on their local repos these days anyway, it's
>>>> not like everyone pollutes the same workspace.
>>>> 
>>>> D.
>>>> 
>>>> -
>>>> 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
>>> 
>> 
> 
> -
> 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: Branch cleaning/ archiving

[Jan Høydahl]

Yep, I updated it with a check that the command succeeded.

Jan

> 10. mar. 2021 kl. 23:09 skrev Ilan Ginzburg :
> 
> Any risk in the script that command:
> git push ${REMOTE} 
> cominvent/$BRANCH:refs/tags/history/branches/lucene-solr/$BRANCH
> errors out in some exotic way (?) but the script continues anyway and 
> proceeds with the delete:
> git push ${REMOTE} --delete $BRANCH
> 
> 
> On Wed, Mar 10, 2021 at 10:35 PM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> Ok, I took a stab at this
> 
> We have 113 branches. Here is a script I prepared that will work directly on 
> a git remote, first creating the tag then deleting the branch.
> https://gist.github.com/80a7eea6bacd4e32646a7958d1e9a870 
> <https://gist.github.com/80a7eea6bacd4e32646a7958d1e9a870>
> 
> In the script I have added the list of branches that I propose to "archive".
> 
> Below that there is a commented section of branches that are reported as 
> "active" by GitHub that should probably stay for now
> Finally, we have some branches we might want to keep around for refernce?
> I'm not sure how useful it is to keep a branch in solr.git for, say 
> branch_8_8, as it will fall behind as branch_8_8 in lucene-solr.git gets 
> updated. So probably archive those as well?
> 
> The pure lucene branches like LUCENE-9004 won't need a tag at all I suppose, 
> but it won't hurt either.
> 
> Jan
> 
> > 10. mar. 2021 kl. 21:16 skrev Dawid Weiss  > <mailto:dawid.we...@gmail.com>>:
> > 
> >> We already did this before, see list of existing tags (git tag -l)
> > 
> > I know, I did it, after all... :) This was a move from subversion
> > though... slightly different. Anyway - if you guys want to proceed
> > with this, please go ahead, I don't mind. A spring cleaning is needed
> > every couple of years... If we just leave the main branch it'll be
> > very elegant. People work on their local repos these days anyway, it's
> > not like everyone pollutes the same workspace.
> > 
> > D.
> > 
> > -
> > 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>
> > 
> 
> 
> -
> 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>
> 

Re: Does CVE-2020-27223 impact Solr 8.6.1

[Jan Høydahl]

Hi,

Please see https://solr.apache.org/security.html for how to handle potential 
security issues responsibly.
From time to time we upgrade our Jetty dependencies, so feel free to file a 
public JIRA to upgrade Jetty in next release.
Normally you'd not be vulnerable to this DoS attach since you would of course 
not expose the Solr servers to the internet or other hostile networks...

Jan

> 10. mar. 2021 kl. 22:12 skrev Steven White :
> 
> Hi everyone,
> 
> Sorry for the double post, as I posted this on the Solr mailing list too.
> 
> Does anyone know if CVE-2020-27223 [1] impacts Solr?  This is a vulnerability 
> in jetty-http-9.4.27.v20200227.jar which we ship with Solr 8.6.1.
> 
> Thanks,
> 
> Steven
> 
> [1] https://nvd.nist.gov/vuln/detail/CVE-2020-27223 
>