Re: [VOTE] Release Lucene 9.12.0 RC2

[Houston Putman]

SUCCESS! [0:56:04.683348]

+1 (binding)

- Houston

On Thu, Sep 26, 2024 at 4:02 AM Uwe Schindler  wrote:

> The latest smoketester run with all JDKs including JDK 23 succeeded
> after 3.5 hrs:
>
> https://jenkins.thetaphi.de/job/Lucene-Release-Tester/37/console
>
> Tested were:
> Java 11 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk11
> Java 17 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk17
> Java 19 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk19
> Java 20 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk20
> Java 21 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk21
> Java 22 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk22
> Java 23 JAVA_HOME=/home/jenkins/tools/java/64bit/hotspot/latest-jdk23
>
> SUCCESS! [3:25:40.656500]
> Finished: SUCCESS
>
> For me all looks fine otherwise, so here is my:
>
> +1 to release
>
> Uwe
>
> Am 25.09.2024 um 18:57 schrieb Chris Hegarty:
> > Please vote for release candidate 2 for Lucene 9.12.0
> >
> > This build includes the bwc stuff with 8.11.4.
> >
> > The artifacts can be downloaded from:
> >
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.12.0-RC2-rev-e913796758de3d9b9440669384b29bec07e6a5cd
> >
> > 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.12.0-RC2-rev-e913796758de3d9b9440669384b29bec07e6a5cd
> >
> > The vote will be open for at least 72 hours i.e. until 2024-09-28 17:00
> UTC.
> >
> > [ ] +1  approve
> > [ ] +0  no opinion
> > [ ] -1  disapprove (and reason why)
> >
> > Here is my +1
> >
> > -Chris.
> >
> > P.S. Uwe, could I please ask you to run this new RC2 through your
> Policeman build and test?
> >
> >
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene 9.12.0 RC1

[Houston Putman]

Thanks so much for getting the back compat stuff started Chris, that's a
lot of help.

I'm comparing these to the commits I made for the 8.11.3 release, and there
are some discrepancies. But we can take care of that on the PRs.

- Houston

On Wed, Sep 25, 2024 at 8:37 AM Chris Hegarty <
christopher.hega...@elastic.co> wrote:

> Hi,
>
> > On 25 Sep 2024, at 13:08, Michael McCandless 
> wrote:
> >
> > On Wed, Sep 25, 2024 at 7:01 AM Chris Hegarty <
> christopher.hega...@elastic.co> wrote:
> >
> > > +1 for release, unless the uncovered issue with TieredMergePolicy
> causes malfunction.
> >
> > My analysis concludes that there is no product bug here. Yeah, maybe the
> policy could be a little more aggressive in its merging, but the issue that
> the test runs into looks like a corner case on the boundary of what the
> heuristics look for.
> >
> > https://github.com/apache/lucene/issues/13818#issuecomment-2371868712
> >
> > It would be good to have Adrien or Mike confirm.
> >
> > I added a comment -- this looks like a rare corner case bug or test
> issue.  It should not be a 9.12.0 release blocker
>
> Thank you Mike.
>
> Ok, so no blocker bugs found. We have some votes, not too many, but maybe
> enough.
>
> Last thing. Backward compat with the recently released 8.11.4. I finally
> managed to build the lucene-solr and generate these bw compat indices. I
> opened the following PR’s - one for main and one for branch_9_12:
>
> * https://github.com/apache/lucene/pull/13824
> * https://github.com/apache/lucene/pull/13823
>
> We don’t strictly need it, but the smoke testing may fail. If I can get
> some sanity on the PR’s, and they look sufficient, then I’m happy to respin
> a new RC for 9.12 - to include support for 8.11.4 ( in the amount of the
> version constant and test verification )
>
> -Chris.

Re: [RESULT] [VOTE] Release Lucene/Solr 8.11.4 RC1

[Houston Putman]

Great catch! I'll remove that from this release and fix it before sending
out the announcement to the mailing lists.

- Houston

On Tue, Sep 24, 2024 at 10:05 PM Koji Sekiguchi 
wrote:

> Hi
>
> > This vote has PASSED
>
> Congrats!
>
> I've read the release news at
> https://solr.apache.org/news.html#apache-solrtm-8114-available and it says
>
> -
> Solr is the blazing-fast, open source, multi-modal search platform built
> on Apache Lucene. It powers full-text, vector, analytics, and geospatial
> search at many of the world's largest organizations. Other major features
> include Kubernetes and docker integration, streaming, highlighting,
> faceting, and spellchecking.
> -
>
> It says that Solr supports multi-modal and vector search, but this release
> news is for Solr 8.11.4, so should we remove them?
>
> Koji
>
>
>
> 2024年9月25日(水) 6:01 Houston Putman :
>
>> It's been >72h since the vote was initiated and the result is:
>>
>> +1  5  (5 binding)
>>  0  0
>> -1  0
>>
>> This vote has PASSED
>>
>
>
> --
> ChatGPT vs セマンティック検索： https://youtu.be/q_kPN6zImbY
> セマンティック検索デモ： https://demo.rondhuit.com/
> ==
> 株式会社 ロンウイット
> 関口宏司
> 101-0047 東京都千代田区内神田1-18-11
> 東京ロイヤルプラザ 5階
> TEL 03-6205-7227
> FAX 03-6205-7228
> https://www.rondhuit.com/
> ブログ http://lucene.jugem.jp/
>

Re: [VOTE] Release Lucene/Solr 8.11.4 RC1

[Houston Putman]

It's been >72h since the vote was initiated and the result is:

+1  5  (5 binding)
 0  0
-1  0

This vote has PASSED

On Tue, Sep 24, 2024 at 12:41 PM Jan Høydahl  wrote:

> +1
>
> SUCCESS! [1:29:27.098734] (on fifth run or something)
>
> Jan
>
> 19. sep. 2024 kl. 20:51 skrev Houston Putman :
>
> Please vote for release candidate 1 for Lucene/Solr 8.11.4
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.4-RC1-reve27f44e3d78dfcec230c97e0a1240e3751daeff9
>
> 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.4-RC1-reve27f44e3d78dfcec230c97e0a1240e3751daeff9
>
> The vote will be open for at least 72 hours i.e. until 2024-09-22 19:00
> UTC.
>
>
>

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

[Houston Putman]

It's been >72h since the vote was initiated and the result is:

+1  5  (5 binding)
 0  0
-1  0

This vote has PASSED

Re: [VOTE] Release Lucene/Solr 8.11.4 RC1

[Houston Putman]

Btw I am +1 (binding) too, I must have missed copying that part of the
message.

- Houston

On Tue, Sep 24, 2024 at 10:01 AM Anshum Gupta 
wrote:

> +1 (binding)
>
> SUCCESS! [1:01:01.305159]
>
> On Thu, Sep 19, 2024 at 11:51 AM Houston Putman 
> wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.11.4
>>
>> The artifacts can be downloaded from:
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.11.4-RC1-reve27f44e3d78dfcec230c97e0a1240e3751daeff9
>>
>> 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.4-RC1-reve27f44e3d78dfcec230c97e0a1240e3751daeff9
>>
>> The vote will be open for at least 72 hours i.e. until 2024-09-22 19:00
>> UTC.
>>
>
>
> --
> Anshum Gupta
>

Re: [VOTE] Release Lucene 9.12.0 RC1

[Houston Putman]

Thanks for the offer Chris, I'll definitely take you up on that! And
hopefully its done in a day or two.

- Houston

On Mon, Sep 23, 2024 at 3:28 PM Chris Hegarty
 wrote:

> Thanks Uwe,
>
> I reproduced this failure on main and branch_9_12.
>
> The following issue has been created to track this,
> https://github.com/apache/lucene/issues/13818.
>
> Git bisect has identified the first failure as "Add target search
> concurrency to TieredMergePolicy (#13430)"
>
> -Chris.
>
> > On 23 Sep 2024, at 18:10, Uwe Schindler  wrote:
> >
> > Unfortunately, the first Smoketester run failed with a test failure (in
> Java 19):
> >
> > TestTieredMergePolicy > testSimulateAppendOnly FAILED
> > java.lang.AssertionError: mergeFactor=4 minSegmentBytes=38,046,720
> maxMergedSegmentBytes=5,213,519,872 segmentsPerTier=4.0
> maxMergeAtOnce=24 numSegments=43 allowed=41. totalBytes=8,132,505,600
> delPercentage=0.0 deletesPctAllowed=39.9912 targetNumSegments=32
> >
> > NOTE: reproduce with: gradlew test --tests
> TestTieredMergePolicy.testSimulateAppendOnly -Dtests.seed=B90724898E61B17C
> -Dtests.multiplier=1 -Dtests.nightly=true -Dtests.locale=bm
> -Dtests.timezone=America/Metlakatla -Dtests.asserts=true
> -Dtests.file.encoding=UTF-8
>
>
> -
> 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.4 RC1

[Houston Putman]

Please vote for release candidate 1 for Lucene/Solr 8.11.4

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

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.4-RC1-reve27f44e3d78dfcec230c97e0a1240e3751daeff9

The vote will be open for at least 72 hours i.e. until 2024-09-22 19:00 UTC.

Bugfix release Lucene/Solr 8.11.4

[Houston Putman]

NOTICE:

I am now preparing for a bugfix release from branch branch_8_11

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.11.4
  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.4 and priority "Blocker" will delay
  a release candidate build.

Re: [VOTE] Release Lucene 9.11.1 RC1

[Houston Putman]

+1

SUCCESS! [0:37:06.564011]

- Houston

On Tue, Jun 25, 2024 at 1:27 PM Anshum Gupta  wrote:

> +1
>
> SUCCESS! [0:44:08.897482]
>
> On Sun, Jun 23, 2024 at 10:29 PM Ignacio Vera  wrote:
>
>> Please vote for release candidate 1 for Lucene 9.11.1
>>
>>
>> The artifacts can be downloaded from:
>>
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.11.1-RC1-rev-0c087dfdd10e0f6f3f6faecc6af4415e671a9e69
>>
>>
>> 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.11.1-RC1-rev-0c087dfdd10e0f6f3f6faecc6af4415e671a9e69
>>
>>
>> The vote will be open for at least 72 hours i.e. until 2024-06-27 07:00
>> UTC.
>>
>>
>> [ ] +1  approve
>>
>> [ ] +0  no opinion
>>
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Here is my +1
>>
>
>
> --
> Anshum Gupta
>

Re: [VOTE] Release Lucene 9.11.0 RC1

[Houston Putman]

+1

SUCCESS! [1:49:36.192513]

- Houston Putman

On Wed, Jun 5, 2024 at 12:58 PM Michael McCandless <
luc...@mikemccandless.com> wrote:

> +1 SUCCESS! [0:24:55.332837]
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Wed, Jun 5, 2024 at 11:21 AM Adrien Grand  wrote:
>
>> +1 SUCCESS! [1:09:30.262027]
>>
>> On Wed, Jun 5, 2024 at 4:15 PM Tomás Fernández Löbbe <
>> tomasflo...@gmail.com> wrote:
>>
>>> +1
>>>
>>> SUCCESS! [1:12:30.029470]
>>>
>>> On Wed, Jun 5, 2024 at 9:22 AM Bruno Roustant 
>>> wrote:
>>>
>>>> +1
>>>>
>>>> SUCCESS! [0:41:14.593265]
>>>>
>>>> Bruno
>>>>
>>>>>
>>
>> --
>> Adrien
>>
>

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

[Houston Putman]

+1

- Houston

On Mon, Feb 26, 2024 at 7:00 AM Jan Høydahl  wrote:

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

[ANNOUNCE] Apache Lucene 8.11.3 released

[Houston Putman]

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

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 numerous bug fixes, optimizations, and improvements,
some of which are highlighted below. The release is available for immediate
download at:

  

### Lucene 8.11.3 Release Highlights:

 * A number of bugs in polygon tessellating have been fixed.
 * GC Load during indexing has been reduced by estimating FST BysteStore
block size.
 * BKD trees will no longer possibly overflow when more than 4 billion
points are added.

Please read CHANGES.txt for a full list of changes:

  

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

[Houston Putman]

It's been >72h since the vote was initiated and the result is:

+1  6  (6 binding)
 0  0
-1  0

This vote has PASSED

Re: [VOTE] Release Lucene/Solr 8.11.3 RC1

[Houston Putman]

It's been >72h since the vote was initiated and the result is:

+1  6  (6 binding)
 0  0
-1  0

This vote has PASSED

On Thu, Feb 8, 2024 at 1:52 PM Anshum Gupta  wrote:

> +1 (binding)
>
> SUCCESS! [1:20:38.669502]
>
> On Wed, Feb 7, 2024 at 10:27 AM Kevin Risden  wrote:
>
>> +1 (binding)
>>
>> SUCCESS! [1:05:24.985760]
>>
>> My issue was ANT_ARGS being set to color - fixed with `unset ANT_ARGS`
>> were ANT_ARGS was being set by oh-my-zsh
>> https://github.com/ohmyzsh/ohmyzsh/blob/master/plugins/ant/ant.plugin.zsh.
>> The colored output wouldn't match the regex for the backwards compat
>> testing.
>>
>> Kevin Risden
>>
>>
>> On Wed, Feb 7, 2024 at 8:24 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> +1 (binding)
>>>
>>> SUCCESS! [1:18:24.494917]
>>>
>>> On Wed, 7 Feb 2024 at 18:24, Jan Høydahl  wrote:
>>>
>>>> +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
>>>>
>>>>
>>>>
>
> --
> Anshum Gupta
>

[VOTE] Release Lucene/Solr 8.11.3 RC1

[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

Bugfix release Lucene/Solr 8.11.3

[Houston Putman]

NOTICE:

I am now preparing for a bugfix release from branch branch_8_11

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.11.3
  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.3 and priority "Blocker" will delay
  a release candidate build.

Re: github milestones vs. releases mystery

[Houston Putman]

Making a release in github is quite easy. You can do it from the release
git tag, so it's "retroactive". (we can do it for 9.7.0 right now)

For the release wizard, the Solr Operator has a section to do this:
https://github.com/apache/solr-operator/blob/main/hack/release/wizard/releaseWizard.yaml#L1392-L1400

I'm surprised it's not in the Lucene one already, since I think Solr has it
as well. But it's easy to add nonetheless.

- Houston

On Thu, Sep 28, 2023 at 1:17 PM Christine Poerschke (BLOOMBERG/ LONDON) <
cpoersc...@bloomberg.net> wrote:

> Hello Everyone,
>
> I just semi-randomly noticed that
> https://github.com/apache/lucene/releases shows 9.6.0 as the latest
> release i.e. not 9.7.0 but on https://github.com/apache/lucene/milestones
> the 9.7.0 milestone is marked as closed, as expected.
>
>
> https://github.com/apache/lucene/blob/releases/lucene/9.7.0/dev-tools/scripts/releaseWizard.yaml#L1517-L1524
> looks to be the relevant section of the release wizard.
>
> Is anyone else also surprised or puzzled by this and/or has any insights
> on what (if anything) to do for 9.7.0 retrospectively and 9.8.0 and others
> in future?
>
> Thanks,
> Christine
>

Final CFP Reminder: Community Over Code

[Houston Putman]

Hello everyone,

Today is the last day that you can submit a presentation for
Community Over Code (formerly known as ApacheCon).
Submissions will be accepted until 23:59:59 GMT.

https://communityovercode.org/call-for-presentations/

There is a Search track that is perfect for presentations concerning Apache
Lucene.

The event will be held in Halifax, Nova Scotia, October 7th through
10th. More details about the event may be found on the event website at
https://communityovercode.org/

- Houston

Re: JavaDoc generated with -noindex

[Houston Putman]

Yeah my bad, didnt read which list it was.

On Sun, Jul 9, 2023 at 10:19 AM Uwe Schindler  wrote:

> Isn't this about Lucene? So 9.8 is right version.
> Am 07.07.2023 um 23:43 schrieb Houston Putman:
>
> Agreed, should be an easy change to include for 9.3.
>
> - Houston
>
> On Fri, Jul 7, 2023 at 5:42 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> +1 to include this in release. Thanks for noticing!
>>
>> On Sat, 8 Jul, 2023, 12:33 am Mike Drob,  wrote:
>>
>>> Why is our javadoc currently generated with -noindex? I did some digging
>>> and found that we set that back in LUCENE-3977 to save 10MB, and then added
>>> a property to re-enable it in LUCENE-4237, but I think that got lost in the
>>> gradle migration.
>>>
>>> While the index might have been useless at the time, it now powers the
>>> javadoc search box, see a demo at https://youtu.be/VrI6rJNO2x4?t=925 --
>>> The full spec is described at
>>> https://docs.oracle.com/en/java/javase/17/docs/specs/javadoc/javadoc-search-spec.html
>>>
>>>
>>> I think this would be a useful thing to include, at least for releases.
>>> WDYT?
>>>
>>> Mike
>>>
>> --
> Uwe SchindlerAchterdiek 19, D-28357 Bremen 
> <https://www.google.com/maps/search/Achterdiek+19,+D-28357+Bremen?entry=gmail&source=g>https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>

Re: JavaDoc generated with -noindex

[Houston Putman]

Agreed, should be an easy change to include for 9.3.

- Houston

On Fri, Jul 7, 2023 at 5:42 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> +1 to include this in release. Thanks for noticing!
>
> On Sat, 8 Jul, 2023, 12:33 am Mike Drob,  wrote:
>
>> Why is our javadoc currently generated with -noindex? I did some digging
>> and found that we set that back in LUCENE-3977 to save 10MB, and then added
>> a property to re-enable it in LUCENE-4237, but I think that got lost in the
>> gradle migration.
>>
>> While the index might have been useless at the time, it now powers the
>> javadoc search box, see a demo at https://youtu.be/VrI6rJNO2x4?t=925 --
>> The full spec is described at
>> https://docs.oracle.com/en/java/javase/17/docs/specs/javadoc/javadoc-search-spec.html
>>
>>
>> I think this would be a useful thing to include, at least for releases.
>> WDYT?
>>
>> Mike
>>
>

Re: [VOTE] Dimension Limit for KNN Vectors

[Houston Putman]

+1 on the combination of #3 and #4.

Also good things to make sure of Uwe, thanks for calling those out.
(Especially about the limit only being used on write, not on read).

- Houston

On Tue, May 16, 2023 at 9:57 AM Uwe Schindler  wrote:

> I agree with Dawid,
>
> I am +1 for those two options in combination:
>
>- option 3 (make limit an HNSW specific thing). New formats may use
>other limits (lower or higher).
>- option 4 (make a system property with HNSW prefix). Adding the
>system property must be done in same way like new properties for MMAP
>directory (including access controller) so it can be denied by system admin
>to be set in code (see
>
> https://github.com/apache/lucene/blob/f53eb28af053d7612f7e4d1b2de05d33dc410645/lucene/core/src/java/org/apache/lucene/store/MMapDirectory.java#L327-L346
>for example). Care has to be taken that the static initializers won't fail
>is system properties cannot be read/set (system adminitrator enforces
>default -> see mmap code). It also has to be made sure that an index
>written with raised limit can still be read without the limit, so the limit
>should not be glued into the file format. Otherwise I disagree with option
>4.
>
> In short: I am fine with making it configurable only for HNSW if the limit
> is not glued into index format. The default should only be there to by
> default prevent people from doing wrong things, but changing default should
> not break reading/modifiying those indexes.
>
> Uwe
> Am 16.05.2023 um 15:37 schrieb Dawid Weiss:
>
>
> I'm for option 3 (limit at algorithm level), with the default there
> tunable via property (option 4).
>
> I understand Robert's concerns and I'd love to contribute a faster
> implementation but the reality is - I can't do it at the moment. I feel
> like experiments are good though and we shouldn't just ban people from
> trying - if somebody changes the (sane) default and gets burned by
> performance, perhaps it'll be an itch to work on speeding things up (much
> like it's already happening with Jonathan's patch).
>
> Dawid
>
> On Tue, May 16, 2023 at 10:50 AM Alessandro Benedetti <
> a.benede...@sease.io> wrote:
>
>> Hi all,
>> we have finalized all the options proposed by the community and we are
>> ready to vote for the preferred one and then proceed with the
>> implementation.
>>
>> *Option 1*
>> Keep it as it is (dimension limit hardcoded to 1024)
>> *Motivation*:
>> We are close to improving on many fronts. Given the criticality of Lucene
>> in computing infrastructure and the concerns raised by one of the most
>> active stewards of the project, I think we should keep working toward
>> improving the feature as is and move to up the limit after we can
>> demonstrate improvement unambiguously.
>>
>> *Option 2*
>> make the limit configurable, for example through a system property
>> *Motivation*:
>> The system administrator can enforce a limit its users need to respect
>> that it's in line with whatever the admin decided to be acceptable for
>> them.
>> The default can stay the current one.
>> This should open the doors for Apache Solr, Elasticsearch, OpenSearch,
>> and any sort of plugin development
>>
>> *Option 3*
>> Move the max dimension limit lower level to a HNSW specific
>> implementation. Once there, this limit would not bind any other potential
>> vector engine alternative/evolution.
>> *Motivation:* There seem to be contradictory performance interpretations
>> about the current HNSW implementation. Some consider its performance ok,
>> some not, and it depends on the target data set and use case. Increasing
>> the max dimension limit where it is currently (in top level
>> FloatVectorValues) would not allow potential alternatives (e.g. for other
>> use-cases) to be based on a lower limit.
>>
>> *Option 4*
>> Make it configurable and move it to an appropriate place.
>> In particular, a simple Integer.getInteger("lucene.hnsw.maxDimensions",
>> 1024) should be enough.
>> *Motivation*:
>> Both are good and not mutually exclusive and could happen in any order.
>> Someone suggested to perfect what the _default_ limit should be, but I've
>> not seen an argument _against_ configurability.  Especially in this way --
>> a toggle that doesn't bind Lucene's APIs in any way.
>>
>> I'll keep this [VOTE] open for a week and then proceed to the
>> implementation.
>> --
>> *Alessandro Benedetti*
>> Director @ Sease Ltd.
>> *Apache Lucene/Solr Committer*
>> *Apache Solr PMC Member*
>>
>> e-mail: a.benede...@sease.io
>>
>>
>> *Sease* - Information Retrieval Applied
>> Consulting | Training | Open Source
>>
>> Website: Sease.io 
>> LinkedIn  | Twitter
>>  | Youtube
>>  | Github
>> 
>>
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremenhttps://www.thetaphi.de
> eMail: u...@the

Re: Running 10.0 build with a custom lucene 9.5

[Houston Putman]

Gus, I haven't done this myself, but are you using the instructions
provided in Solr's "gradle/lucene-dev/lucene-dev-repo-composite.gradle"?

It looks like you need to specify the development lucene version
differently than other dependencies...

- Houston

On Sat, May 13, 2023 at 10:14 AM Michael Sokolov  wrote:

> doh I actually read your email and you said you already checked that -
> I'm going to send out one of those "sokolov would like to retract the
> previous email" emails. Does GMail even pretend to do that? I don't
> know what's going on there! sorry
>
> On Sat, May 13, 2023 at 10:13 AM Michael Sokolov 
> wrote:
> >
> > sorry - META-INF not WEB-INF
> >
> > On Sat, May 13, 2023 at 10:12 AM Michael Sokolov 
> wrote:
> > >
> > > You are probably missing the contents of WEB-INF in your custom jar?
> > > Roughly speaking the files in there define run-time-bound "services"
> > > that are looked up by name by the JDK's service-loader API.
> > >
> > > On Sat, May 13, 2023 at 9:33 AM Gus Heck  wrote:
> > > >
> > > > Cross posting to lucene on the possibility that folks here are more
> likely to add customized lucene to Solr and recognize what I'm stumbling
> on? (zero responses on solr list)
> > > >
> > > > Note that the specific test that I happened to copy is not the
> issue, all tests are doing this (or at least so many tests are failing I
> can't see the ones that are passing easily).
> > > >
> > > > -- Forwarded message -
> > > > From: Gus Heck 
> > > > Date: Wed, May 10, 2023 at 6:50 PM
> > > > Subject: Running 10.0 build with a custom lucene 9.5
> > > > To: 
> > > >
> > > >
> > > > Lucene:
> > > >
> > > > I made a tweak to lucene for something I'm investigating, gave it a
> new version, deployed to mavenLocal()
> > > > I have verified that the jars are built with correct
> META-INF/services files
> > > >
> > > > Solr:
> > > >
> > > > I added mavenLocal() in gradle/globals.gradle
> > > > I removed the license file sha1 sigs for the default lucene &
> creates signatures for my test version
> > > > I updated versions.props
> > > > I updated versions.lock
> > > >
> > > > Now when I run individual solr tests via my ide they seem to pass,
> but virtually every test run via gradle fails with something like:
> > > >
> > > > org.apache.solr.embedded.TestJettySolrRunner > classMethod FAILED
> > > > java.lang.ExceptionInInitializerError
> > > > at org.apache.lucene.codecs.Codec.getDefault(Codec.java:141)
> > > > at
> org.apache.lucene.tests.util.TestRuleSetupAndRestoreClassEnv.before(TestRuleSetupAndRestoreClassEnv.java:137)
> > > > at
> org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:42)
> > > > at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > > > at
> org.apache.lucene.tests.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
> > > > at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> > > > at
> com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:40)
> > > > at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > > > at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > > > at
> org.apache.lucene.tests.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:53)
> > > > at
> org.apache.lucene.tests.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:43)
> > > > at
> org.apache.lucene.tests.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:44)
> > > > at
> org.apache.lucene.tests.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:60)
> > > > at
> org.apache.lucene.tests.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:47)
> > > > at org.junit.rules.RunRules.evaluate(RunRules.java:20)
> > > > at
> com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
> > > > at
> com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:390)
> > > > at
> com.carrotsearch.randomizedtesting.ThreadLeakControl.lambda$forkTimeoutingTask$0(ThreadLeakControl.java:850)
> > > > at java.base/java.lang.Thread.run(Thread.java:829)
> > > >
> > > > Caused by:
> > > > java.lang.IllegalArgumentException: An SPI class of type
> org.apache.lucene.codecs.Codec with name 'Lucene95' does not exist.  You
> need to add the corresponding JAR file supporting this SPI to your
> classpath.  The current classpath supports the following names: []
> > > > at
> org.apache.lucene.util.NamedSPILoader.lookup(NamedSPILoad

Re: Lucene PMC Chair Greg Miller

[Houston Putman]

Thanks Bruno, and good luck Greg!

- Houston

On Tue, Mar 7, 2023 at 3:29 PM Gus Heck  wrote:

> Congratulations Greg and thanks Bruno!
>
> On Tue, Mar 7, 2023 at 3:13 PM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
>> Thanks Bruno! and Congratulations Greg!
>>
>> On Tue, Mar 7, 2023 at 10:49 AM Patrick Zhai  wrote:
>>
>>> Thank you Bruno and Greg!
>>>
>>> On Tue, Mar 7, 2023, 10:40 Mikhail Khludnev  wrote:
>>>
 Thank you, Bruno. Congratulations, Greg.

 On Mon, Mar 6, 2023 at 8:16 PM Bruno Roustant 
 wrote:

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


 --
 Sincerely yours
 Mikhail Khludnev
 https://t.me/MUST_SEARCH
 A caveat: Cyrillic!

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

Re: [VOTE] Release Lucene 9.4.1 RC1

[Houston Putman]

SUCCESS! [0:47:29.586134]

+ 1

On Fri, Oct 21, 2022 at 10:33 AM Michael Sokolov  wrote:

> SUCCESS! [0:49:28.580122]
>
> +1
>
> On Fri, Oct 21, 2022 at 5:57 AM Robert Muir  wrote:
> >
> > I change my vote to +1 based on Julie's test. It fails for me with
> > 9.4.0 and passes for me with 9.4.1
> >
> > :lucene:core:test (SUCCESS): 1 test(s)
> >
> > > Task :lucene:core:wipeTaskTemp
> > The slowest tests (exceeding 500 ms) during this run:
> >   8511.54s TestManyKnnVectors.testLargeSegment (:lucene:core)
> > The slowest suites (exceeding 1s) during this run:
> >   8512.27s TestManyKnnVectors (:lucene:core)
> >
> > BUILD SUCCESSFUL in 2h 22m 55s
> > 19 actionable tasks: 13 executed, 6 up-to-date
> >
> > On Thu, Oct 20, 2022 at 3:57 PM Robert Muir  wrote:
> > >
> > > Thank you Julie for the draft test! I will try to reproduce/test with
> it.
> > >
> > > On Thu, Oct 20, 2022 at 3:45 PM Julie Tibshirani 
> wrote:
> > > >
> > > > Thank you Ignacio for taking over as release manager! I ran into
> some issues with my signing key and Ignacio saved the day.
> > > >
> > > > Robert, I understand your perspective. I uploaded a draft PR with a
> monster test you could try out:
> https://github.com/apache/lucene/pull/11867. It requires downloading an
> external dataset based on some StackOverflow data where I found the bug.
> Let me know if you run into problems with the test -- maybe we can discuss
> on the draft PR.
> > > >
> > > > Julie
> > > >
> > > > On Thu, Oct 20, 2022 at 10:17 AM Uwe Schindler 
> wrote:
> > > >>
> > > >> Hi,
> > > >>
> > > >> Policeman Jenkins ran the smoke checks for me with Java 11 and Java
> 17, still no Java 19 :(
> > > >>
> > > >> SUCCESS! [1:26:17.692239]
> > > >> Finished: SUCCESS
> > > >>
> > > >> I did not do any special checks beyond smoke tester. To me the
> Bugfix looks fine.
> > > >>
> > > >> +1 to release!
> > > >>
> > > >> Uwe
> > > >>
> > > >> Am 20. Oktober 2022 16:24:23 MESZ schrieb Ignacio Vera <
> iver...@gmail.com>:
> > > >>>
> > > >>> Please vote for release candidate 1 for Lucene 9.4.1
> > > >>>
> > > >>>
> > > >>> The artifacts can be downloaded from:
> > > >>>
> > > >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.1-RC1-rev-810817993e0956e63e29906e78a245949501b77d
> > > >>>
> > > >>>
> > > >>> 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.4.1-RC1-rev-810817993e0956e63e29906e78a245949501b77d
> > > >>>
> > > >>>
> > > >>> The vote will be open for at least 72 hours i.e. until 2022-10-23
> 15:00 UTC.
> > > >>>
> > > >>>
> > > >>> [ ] +1  approve
> > > >>>
> > > >>> [ ] +0  no opinion
> > > >>>
> > > >>> [ ] -1  disapprove (and reason why)
> > > >>>
> > > >>>
> > > >>> Here is my +1
> > > >>>
> > > >>> 
> > > >>
> > > >> --
> > > >> Uwe Schindler
> > > >> Achterdiek 19, 28357 Bremen
> > > >> https://www.thetaphi.de
> >
> > -
> > 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: Label vs. Milestone for version management?

[Houston Putman]

So the Solr Operator has been using Github Issues for a few releases now,
and the Milestone feature has worked really well for a blockers list.

I agree that it should not be the canonical list of things that were
included in that release (although it will likely be very close), but it is
very good for easily seeing what PRs/Issues are still open for a particular
version.
You can also see the milestone in the Issues & PR list, so it's easy to see
what version the Issues/PRs are targeted for at a quick glance.

- Houston

On Thu, Aug 25, 2022 at 10:12 AM Robert Muir  wrote:

> On Thu, Aug 25, 2022 at 9:47 AM Michael Sokolov 
> wrote:
> >
> > I agree; I've always used CHANGES for a quick historical view. What
> > about the release manager use case? I haven't done a release, but I
> > think we generally want to know if people are targeting changes for an
> > upcoming release, especially if they are blockers. We could just use
> > email to find out about these, but I think it's better if we can look
> > them up in the issue db.
>
> Mark them as priority blocker with a tag? that's all you could do with
> JIRA, too.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Vigya Sharma as Lucene committer

[Houston Putman]

Welcome Vigya!

On Mon, Aug 1, 2022 at 11:38 AM Alan Woodward  wrote:

> Congratulations and welcome, Vigya!
>
> - Alan
>
> On 28 Jul 2022, at 20:44, Vigya Sharma  wrote:
>
> Thanks everyone for the warm welcome. It is an honor to be invited as a
> Lucene committer, and I look forward to contributing more to the community.
>
> A little bit about me - I currently work for the Product Search team at
> Amazon, and am based out of the San Francisco Bay Area in California, US.
> I am interested in a wide variety of computer science areas, and, in the
> last few years, have focused more on distributed systems, concurrency,
> system software and performance. Outside of tech., I like spending my time
> outdoors - running, skiing, and long road trips. I completed my first
> marathon (the SFMarathon) last week, and now, getting this invitation has
> made this month a highlight of the year.
>
> I had known that Lucene powers some of the most popular search and
> analytics use cases across the globe, but as I've gotten more involved, the
> depth and breadth of this software has blown my mind. I am deeply impressed
> by what this community has built, and how it continues to work together and
> grow. It is a great honor to be trusted with committer privileges, and I
> look forward to learning and contributing to multiple different parts of
> the library.
>
> Thank you,
> Vigya
>
>
> On Thu, Jul 28, 2022 at 12:20 PM Anshum Gupta 
> wrote:
>
>> Congratulations and welcome, Vigya!
>>
>> On Thu, Jul 28, 2022 at 12:34 AM Adrien Grand  wrote:
>>
>>> I'm pleased to announce that Vigya Sharma has accepted the PMC's
>>> invitation to become a committer.
>>>
>>> Vigya, the tradition is that new committers introduce themselves with a
>>> brief bio.
>>>
>>> Congratulations and welcome!
>>>
>>> --
>>> Adrien
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>
>
> --
> - Vigya
>
>
>

Re: [DISCUSS] Read-only Jira after the GitHub issues migration?

[Houston Putman]

I think missing a few updates would be preferable to having 10k messages.
Just my opinion though.

On Tue, Jul 19, 2022 at 10:11 AM Tomoko Uchida 
wrote:

> > 1. Make Jira read only
>>
>> At the very last step, we'll add comments saying "This was moved GitHub
>> " to each Jira issue. It has to be done after the migration was
>> completed.
>>
>
> > Is this going to send 10k emails to the mailing list? I’ll need to
> update my filters so that these skip my inbox in that case.
>
> Yes, I will let you all know the mail template before starting the
> migration.
> Or, a Jira project admin could completely disable notifications from Jira
> - but this could bury real notifications (issues/comments by humans who
> don't recognize the migration).
>
> 2022年7月19日(火) 23:05 Tomoko Uchida :
>
>> > 2. Send a message to dev@ stating new issues should now be opened in
>> github
>> > 3. Start the migration
>>
>> Maybe we can do a simulation for this.
>> I plan a rehearsal that migrates whole existing issues into a test repo
>> next week. Could some people help/test it (randomly open/close issues, add
>> comments, etc. while the migration script is running)?
>>
>>
>> 2022年7月19日(火) 22:47 Tomoko Uchida :
>>
>>> > 1. Make Jira read only
>>>
>>> At the very last step, we'll add comments saying "This was moved GitHub
>>> " to each Jira issue. It has to be done after the migration was
>>> completed.
>>>
>>> > 2. Send a message to dev@ stating new issues should now be opened in
>>> github
>>> > 3. Start the migration
>>>
>>> In theory, it would be okay to me. I just wanted to avoid any risks
>>> during migration. Let me give time to consider/check if the migration can
>>> be safely done while new issues are created (by humans).
>>>
>>>
>>> 2022年7月19日(火) 21:56 Ryan Ernst :
>>>
 > Yes, it won't be a really atomic switch

 While it may not be completely atomic, could it be closer? GitHub
 already supports new issues, developers are just advised against opening
 there. Could the order of events be:

 1. Make Jira read only
 2. Send a message to dev@ stating new issues should now be opened in
 github
 3. Start the migration
 4. When the migration is complete, send another message notifying devs
 that pre-existing Jiras are now in GitHub,so they can then be commented on
 and edited there.

 I think the difference with this and what was previously described on
 this thread is there would be no downtime for new issues.

 On Tue, Jul 19, 2022 at 00:07 Tomoko Uchida <
 tomoko.uchida.1...@gmail.com> wrote:

> OK, thank you everyone for your comments/suggestions.
> I will ask infra to make Lucene Jira read-only after the migration is
> completed (if there are no explicit objections). For people who are
> critically affected by this change, please let me know about your
> inconvenience. I'll try to find acceptable solutions.
>
> > I would prefer that we make a nearly atomic switch -- up until time
> X we use Jira, then it goes read-only and at time X + t (t being how long
> the migration takes, likely a day or two?), GitHub issues opens for
> business.
>
> Yes, it won't be a really atomic switch - there will be a moratorium
> in our issue system (where GitHub issue is not lifted yet, but a Jira
> snapshot is already taken). I estimate the whole migration process will
> take at least three days; will make a mail thread about the detailed
> schedule.
>
> Tomoko
>
>
> 2022年7月19日(火) 2:38 Gus Heck :
>
>> I am 100% for preventing creation of new issues in Jira, new issues
>> should only be created in one system at any one time. I feel that 
>> existing
>> issues should be completed in their original system for continuity, and
>> anticipate that in any case Jira will mean readable in perpetuity. The
>> copying of old issues to github as a convenience for users so they aren't
>> forced to look at 2 places also sounds good. Raising the standard for 
>> what
>> we consider a stale issue and closing out things in Jira faster to get 
>> to a
>> one system situation sooner also seems good.
>>
>> Things I think we should strive to avoid:
>> 1) An issue in Jira that is unresolved and duplicated (possibly
>> resolved) in github... possibly leading to someone wasting time 
>> repeating a
>> solution or giving up thinking there isn't a solution etc.
>> 2) Any issues for which the discussion is split across systems and
>> thus it would be easy to miss part of the discussion and/or not have the
>> issue come up in searches that are relevant to that issue.
>>
>> Also, a common pattern for me is to throw an issue ticket number that
>> I have noted somewhere (i.e LUCENE-12345) into google and browse to the
>> ticket if it comes up directly or to a mail archive result which has a 
>> link
>> to the Jir

Re: A prototype migration tool Jira to GitHub

[Houston Putman]

>
> Is there anybody who kindly provides a github account to make sure that
> "any notifications are never triggered" when executing migration? I
> confirmed this with my account, just wanted to test it with other one or
> two accounts.
>

I've subscribed to all notifications for that sandbox-lucene-10557 repo.
Let me know if you are going to create a different repo and I'll subscribe
to that as well.

- Houston

On Fri, Jun 24, 2022 at 12:47 PM Tomoko Uchida 
wrote:

> I started to play around with the (unofficial) Issue Import API
>  and so far so
> good.
> - Original timestamps (created, updated) are preserved
> - An issue and its comments can be imported with one post request;
> importing is done asynchronously but the background job looks sufficiently
> fast.
> - Notifications are not triggered with mentions in the issue comments
> (e.g. https://github.com/mocobeta/sandbox-lucene-10557/issues/249)
>
> I will do more tests and rewrite the scripts with this API and if it works
> as expected, try to migrate whole Jira issues into a test repo next time;
> it still needs two-pass migration but could be done in a few hours with the
> default rate limit.
> Is there anybody who kindly provides a github account to make sure that
> "any notifications are never triggered" when executing migration? I
> confirmed this with my account, just wanted to test it with other one or
> two accounts.
>
> Tomoko
>
> 2022年6月24日(金) 21:12 Adrien Grand :
>
>> FWIW I don't mind receiving these one-time notifications for the purpose
>> of the migration.
>>
>> On Fri, Jun 24, 2022 at 12:58 PM Tomoko Uchida <
>> tomoko.uchida.1...@gmail.com> wrote:
>>
>>> > If you could give me some "example mail", I can add a "feed to trash"
>>> sieve rule before you start it.
>>>
>>> If we decide to migrate all Jira issues to GItHub with reporter/author
>>> account re-mapping (hyperlinks), and we still cannot find a workaround
>>> not to trigger notifications, I'll let you all know the example mail
>>> text.
>>> I can also trigger some real notifications by simulating a few
>>> migrations for people who wish to know what will happen in their
>>> mailbox/github UI beforehand. I'm really not sure what will happen to
>>> everyone by triggering so many notifications.
>>>
>>> Precisely speaking, you will receive the same number of notifications
>>> to your all activities in Jira so far: reporting an issue, assigning
>>> yourself to an issue, and leaving a comment.
>>> GitHub UI and mailers will aggregate them into "issues", I think.
>>>
>>> > Another question: With the alternative API is it possible to keep
>>> original Reporters and Authors of comments, too?
>>>
>>> I haven't tried the unofficial API yet, but as far as I read the
>>> examples, it is not possible to keep original reporters or authors.
>>> You cannot change/tweak GitHub issue reporter or author by any means -
>>> it looks a sane decision to me.
>>>
>>>
>>> 2022年6月24日(金) 16:18 Uwe Schindler :
>>> >
>>> > Hi,
>>> >
>>> > Am 23.06.2022 um 19:09 schrieb Tomoko Uchida:
>>> >
>>> > uschindler,Uwe Schindler,2474
>>> >
>>> > If you could give me some "example mail", I can add a "feed to trash"
>>> sieve rule before you start it.
>>> >
>>> > We have 109158 resources (10608 issues + 98550 comments) in total.
>>> With the default rate limit of 5000 reqs per hour, it will take 22 hours if
>>> there are no failures/retries. With an enterprise account, it will take 7-8
>>> hours I think.
>>> >
>>> > So a sieve rule would be good to not get constant mail all the time,
>>> because my 2474 issues (or notifications?) will be distrubuted over the
>>> whole day.
>>> >
>>> > Another question: With the alternative API is it possible to keep
>>> original Reporters and Authors of comments, too?
>>> >
>>> > Uwe
>>> >
>>> > Tomoko
>>> >
>>> >
>>> > 2022年6月24日(金) 0:39 Tomoko Uchida :
>>> >>
>>> >> It seems not new - I don't figure out why this is not published as a
>>> public API yet but according to the comments there, it could be
>>> buggy/unstable (still worth a try to me).
>>> >>
>>> >>
>>> >>
>>> >> 2022年6月24日(金) 0:26 Tomoko Uchida :
>>> >>>
>>> >>> I just browsed through this article about the "import issues" API
>>> (looks pretty new and on technical preview status?)
>>> >>> https://gist.github.com/jonmagic/5282384165e0f86ef105
>>> >>>
>>> >>> Seems it solves many of our considerations - preserving original
>>> timestamp, bulk importing issue comments, and not triggering notifications.
>>> >>>
>>> >>> I'll try it later; thank you Rob for providing the information.
>>> >>>
>>> >>>
>>> >>> 2022年6月23日(木) 23:18 Michael Sokolov :
>>> 
>>>  oh phew! glad to hear this was expected
>>> 
>>>  On Thu, Jun 23, 2022 at 10:17 AM Tomoko Uchida
>>>   wrote:
>>>  >
>>>  > > Many comments were lost in the transfer. The last one in the
>>> copy is
>>>  > > only about 1/4 of the way through this gigantic issue. This
>>> really is
>>>  

Re: Deleting old RCs

[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: [VOTE] Release Lucene/Solr 8.11.2 RC2

[Houston Putman]

+1 (binding)

SUCCESS! [1:10:19.762602]

- Houston

On Wed, Jun 15, 2022 at 10:04 PM Anshum Gupta 
wrote:

> Thanks for reporting that, Tim.
>
> Seems like this one is known to fail. I tried reproducing this w/ same
> seed as well as randomizing, but wasn't able to do that over 100 runs.
>
>
> On Wed, Jun 15, 2022 at 11:12 AM Timothy Potter 
> wrote:
>
>> I guess this is a -0 ? test suite failed and I don't have time to
>> fight with it :-(
>>
>>[junit4] Tests with failures [seed: B73581D35178CCBC]:
>>[junit4]   - org.apache.solr.cloud.LeaderVoteWaitTimeoutTest.basicTest
>>
>> On Tue, Jun 14, 2022 at 4:36 AM Jan Høydahl 
>> wrote:
>> >
>> > +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
>> > 
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>

Re: [VOTE] Release Lucene/Solr 8.11.2 RC1

[Houston Putman]

+0

SUCCESS! [1:02:38.547629]

I saw this in the example logs during the smoketester:

> ps: Invalid process id: i��\r\001
> Waiting up to 180 seconds to see Solr running on port 8983 [/]
> Started Solr server on port 8983 (pid=16758). Happy searching!
>
This seems related to SOLR-16191
, which is included in
this release.
Not exactly sure what went wrong, but the example still passed?

- Houston

On Wed, Jun 8, 2022 at 8:50 PM Mike Drob  wrote:

> to: dev@lucene, dev@solr
>
> Please vote for release candidate 1 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-RC1-reva9ed1e5fccbd1a84c78194a1329a7e1a3032ffc6
>
> 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-RC1-reva9ed1e5fccbd1a84c78194a1329a7e1a3032ffc6
>
> Please see draft release notes (and edit as appropriate) at
> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote8_11_2
> https://cwiki.apache.org/confluence/display/SOLR/ReleaseNote8_11_2
>
> The vote will be open for at least 72 hours not including weekend i.e.
> until 2022-06-14 01:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>

Re: Welcome Chris Hegarty as Lucene committer

[Houston Putman]

Congrats Chris!

On Thu, Jun 2, 2022 at 4:07 PM Mikhail Khludnev  wrote:

> Welcome, Chirs!
>
> On Wed, Jun 1, 2022 at 10:29 AM Chris Hegarty
>  wrote:
>
>> Hi,
>>
>> I am both honoured and humbled to have been invited to become a
>> committer. Thank you.
>>
>> I've been working on the development of the Java Platform and the JDK for
>> a little more than 20 years. First in the Javasoft group at Sun
>> Microsystems, and later in the Java Platform Group at Oracle. After
>> spending much of my working life as a "producer of Java", I'm now with
>> Elastic and looking forward to seeing what it is like as a "user of Java”.
>> There is so much exciting and interesting work happening in this space, I
>> hope to be able to make some positive contributions, even in a small way.
>>
>> -Chris.
>>
>> > On 1 Jun 2022, at 08:04, Adrien Grand  wrote:
>> >
>> > 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
>>
>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Re: Welcome Lu Xugang as Lucene committer

[Houston Putman]

Congrats Lu!

On Thu, Jun 2, 2022 at 4:09 PM Mikhail Khludnev  wrote:

> Welcome, Lu.
>
> On Wed, Jun 1, 2022 at 12:59 PM 陆徐刚  wrote:
>
>> Thanks Adrien for the announcement and all for the welcome! It’s a great
>> honor for me be a Lucene committer.
>>
>> I live in ShangHai, China and work at EOI company which focus on AIOps.
>> Thanks to Lucene such a great project which bring me to the Java world
>> since 2017.
>>
>> Since Lucene 7.5.0, I start to read source and write blogs on my personal
>> page (http://www.amazingkoala.com.cn) to help other lucene enthusiast
>> understand Lucene internal.
>>
>> some of my favorite things:
>>   - video game: World of Warcraft
>>   - Java keyword: finally
>>
>> Lu Xugang
>>
>> On Jun 1, 2022, at 16:34, Anshum Gupta  wrote:
>>
>> 
>> Congratulations and welcome, Xugang!
>>
>> On Wed, Jun 1, 2022 at 12:07 AM Adrien Grand  wrote:
>>
>>> 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
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>>
>
> --
> Sincerely yours
> Mikhail Khludnev
>

Re: Welcome Greg Miller to the Lucene PMC

[Houston Putman]

Welcome Greg!

On Tue, Jun 7, 2022 at 11:35 AM Gautam Worah  wrote:

> Congratulations Greg!
>
> On Tue, Jun 7, 2022 at 8:04 AM Patrick Zhai  wrote:
>
>> Congrats Greg!
>>
>> Patrick
>>
>> On Tue, Jun 7, 2022, 07:53 Julie Tibshirani  wrote:
>>
>>> Congratulations Greg!!
>>>
>>> On Tue, Jun 7, 2022 at 7:22 AM Ignacio Vera  wrote:
>>>
 Welcome Greg!

 On Tue, Jun 7, 2022 at 1:40 PM 陆徐刚  wrote:

> Congratulations, Greg.
>
> Xugang
>
> > 在 2022年6月7日，17:48，Dawid Weiss  写道：
> >
> > Congratulations and welcome, Greg.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
> Regards,
> Gautam Worah.
>

Re: [VOTE] Migration to GitHub issue from Jira (LUCENE-10557)

[Houston Putman]

+1 Approve (PMC)

Thanks so much for doing all of the work for this Tomoko!

- Houston

On Mon, May 30, 2022 at 5:38 PM David Smiley  wrote:

> +1 Approve (PMC)
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, May 30, 2022 at 11:40 AM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
>> 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: [VOTE] Release Lucene 9.2.0 RC2

[Houston Putman]

+1

SUCCESS! [2:17:07.370407] (java 11 & 17)

- Houston

On Fri, May 20, 2022 at 8:04 AM Jan Høydahl  wrote:

> +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: [DISCUSS] A proposal for migration to GitHub issue (LUCENE-10557)

[Houston Putman]

I'm not going to get into how the Github automation should be done, that's
a whole separate thread. But I agree too much automation can certainly be
annoying and a burden. You can see this a lot in the kubernetes repos (
https://github.com/kubernetes), though it does come with its reasons.

Kubernetes is a good example of a project MUCH bigger than Solr
successfully using Github Issues & PRs. So I don't really think it's a
question if Github is feature-rich enough to handle our use case, it's
pretty clear that it is. It will certainly be a change in process, but I
think that all of these very successful open source projects show that it's
a valid option for our projects. I think the ultimate questions are:

   - Which will be easier for users to find relevant information?
   - Which reduces the amount of bureaucracy needed to contribute to the
   project?
   - Which fits into the workflows of existing committers the best?

To me Github comes up on top, even though there are things that JIRA does
better.

P.S. I think you mean https://github.com/helm/charts, marcus. I don't think
helm is deprecated

On Tue, May 10, 2022 at 1:41 PM Marcus Eagan  wrote:

> I recommend people take a look at the now deprecated helm project. It was
> very difficult to land PRs because they had so much governance and
> automation. For a data store as mature as SOLR, I would suggest it is
> needed.
>
> Many issues are worth a read: https://github.com/helm/helm
>
> On Tue, May 10, 2022 at 10:16 AM Gus Heck  wrote:
>
>>
>>
>> On Tue, May 10, 2022 at 10:40 AM Houston Putman 
>> wrote:
>>
>>>
>>>>
>>> Most modern open source projects use Github Issues for their issue
>>> tracking, so it's definitely doable, and really what new
>>> users/contributors will be expecting. Also I see that much discussion is
>>> already done on PRs, and JIRAs are mainly there just for
>>> bureaucratic purposes. So I think it would be a wonderful direction to go
>>> in.
>>>
>>>
>> On that note, many such projects I find it more difficult to get clarity
>> on whether or not I'm affected by the issue, or in what version it was
>> resolved. Usually i can be achieved by clicking on the referenced commit,
>> and then inspecting what tags are on that commit, but it's several clicks
>> and a minute or two vs just looking at the field in Jira...
>>
>> This can be made easier by using milestones as seen here (random example,
>> used gradle because it's a very large, healthy project):
>> https://github.com/gradle/gradle/issues/20182
>>
>> But I've seen a lot of projects that don't do that... which probably
>> colors my view a bit.
>>
>> -Gus
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>>
>
>
> --
> Marcus Eagan
>
>

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

[Houston Putman]

>
> It's not about features, but about accepting a new framework to me. GitHub
> issue would not be a replacement Jira, and we cannot operate this project
> on GitHub issue in the same way on Jira. We'd need to build our new
> convention and operations on the new toolkit.
>

I think this is a very important point. We have done a good job of using
Github Issues 100% for the Solr Operator, but that is definitely smaller
than Lucene and Solr. I think it's doable but we will definitely have to
build in processes (like other large projects have done). Github Issues is
not as powerful as JIRA, but maybe in the long-term that will be a good
thing? Also Github has been improving over the last few years, and I have
only seen JIRA either stay the same or get worse in the ~decade I've been
working on the project.

Most modern open source projects use Github Issues for their issue
tracking, so it's definitely doable, and really what new
users/contributors will be expecting. Also I see that much discussion is
already done on PRs, and JIRAs are mainly there just for
bureaucratic purposes. So I think it would be a wonderful direction to go
in.

- Houston

On Tue, May 10, 2022 at 8:06 AM Tomoko Uchida 
wrote:

> Thanks Alessandro for openly sharing your perspective!
>
> > I have limited experience with the Github issue system, it looks
> definitely "simpler" than Jira, not sure it covers all our requirements.
>
> I feel I'd need to explain my thoughts on this point. Yes, I think I know
> very well about such kind of discussion - "We're using XXX for YYY, does
> the new shiny ZZZ tool work as its replacement? Does ZZZ satisfy our
> use-cases so far?"
> But - I don't want to make this discuss thread into a feature comparison
> of Jira vs GitHub.
> It's not about features, but about accepting a new framework to me. GitHub
> issue would not be a replacement Jira, and we cannot operate this project
> on GitHub issue in the same way on Jira. We'd need to build our new
> convention and operations on the new toolkit. I myself am optimistic about
> we can do it well if we fully decide to accept the worldview the tool
> provides for us.
>
> If many of you (here I mean, committers) feel "It's okay if our current
> operation will be kept on GitHub.", I won't be able to fulfill your
> expecttations.
> It's my position - and if it's not acceptable, I'd be happy to fail this
> proposal.
>
> Thanks,
> Tomoko
>
>
> 2022年5月10日(火) 18:41 Alessandro Benedetti :
>
>> Hi Tomoko,
>> thanks for raising this!
>>
>> I am always in favor of simplicity and with the idea that code should
>> speak for itself(readable code and meaningful commit messages over dirty
>> code covered by a detailed Jira issue).
>>
>> Now, given that, I have been using Jira for many years, I agree with all
>> the limitations mentioned so far but I am generally happy about using it.
>> I have limited experience with the Github issue system, it looks
>> definitely "simpler" than Jira, not sure it covers all our requirements.
>>
>> Being a bit provocative and thinking out loud, I see a true necessity of
>> raising issues(Jira or Github) in these instances:
>> 1) proposal that needs discussion and doesn't have a clear solution
>> 2) raise a bug/task/story we are not planning to do ourselves immediately
>> (so we want to give the community the chance of doing it while we are busy)
>> 3) planning, using sprints etc (we don't do)
>>
>> Whenever we have a contribution or bugfix ready (as an output of our
>> daily working activity), it feels to me that it's unnecessary to create an
>> issue at all, modern pull requests are perfectly fine for adding all the
>> necessary details, tag people for review or discuss the contribution: to me
>> having to open any kind of issue is just an unnecessary boilerplate
>> activity (and duplication of description, comments, etc).
>> Pretty sure I am missing something, but I just wanted to give a quick
>> glance of a recent feeling of mine.
>>
>> Long story short, if the Github issue system covers all our requirements,
>> I think it's going to be beneficial to keep all in the "same" place and
>> would ease contributions.
>> But I am arguing we should not open an issue for each contribution, most
>> of the time the Pull Request should be enough.
>> Of course, we should estimate the effort, identify people that
>> realistically want to work for that and then vote if the amount of
>> dedication is worth.
>>
>> In regards to nationality bans, and sanctions etc, I am personally not
>> that worried, aren't we relying quite strongly already on Github for the
>> repos, pull requests, etc?(and I assume many other infrastructures
>> potentially owned by organizations that could impose certain bans?)
>> Ideally, we want to just use tools owned by the Apache Software
>> Foundation, but realistically sometimes you need to compromise.
>> I would suggest we organize a voting session to see how strong the
>> banning concern is, across the committers community, because

Re: Lucene PMC Chair Bruno Roustant

[Houston Putman]

Congrats Bruno, and thanks Michael for doing such an incredible job!

- Houston

On Thu, Mar 24, 2022 at 10:45 AM Alessandro Benedetti 
wrote:

> Thanks Michael for the amazing work last year!
> Welcome Bruno, I am sure you'll do great!
> Cheers
>
> On Thu, 24 Mar 2022, 09:23 Uwe Schindler,  wrote:
>
>> Hi,
>>
>> Thanks Michael for all the hard work last year.
>> Welcome Bruno!
>>
>> Uwe
>>
>> -
>> Uwe Schindler
>> Achterdiek 19, D-28357 Bremen
>> https://www.thetaphi.de
>> eMail: u...@thetaphi.de
>>
>> > -Original Message-
>> > From: Michael Sokolov 
>> > Sent: Wednesday, March 23, 2022 2:03 PM
>> > To: Lucene Dev 
>> > Subject: Lucene PMC Chair Bruno Roustant
>> >
>> > 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: Welcome Guo Feng as Lucene committer

[Houston Putman]

Congrats Feng!

On Fri, Jan 28, 2022 at 12:31 AM Michael Gibney 
wrote:

> Welcome, Feng!
>
> On Thu, Jan 27, 2022 at 2:23 PM Mayya Sharipova
>  wrote:
>
>> Welcome and congratulations, Feng!
>>
>> On Wed, Jan 26, 2022 at 11:50 AM Namgyu Kim  wrote:
>>
>>> Congratulations and welcome, Feng! :D
>>>
>>> On Tue, Jan 25, 2022 at 6:09 PM Adrien Grand  wrote:
>>>
 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

Re: Mirroring the later 8.x release tags in the "new" split repositories

[Houston Putman]

Dawid,

I did mean that we should be pushing the tags as well as their associated
commits. I was unaware that you could push the tags without the commits,
sorry if I caused confusion there.

Jan,

Looking in the diff between the "history/branches/lucene-solr/branch_8x"
tag in apache/solr and the current "branch_8_11" in apache/lucene-solr,
there is around 12 MB of commits to add. This is a rough estimate, but it
should be close enough.

The best approximation I have of the apache solr repository is that it's
size is around 400 MB. So adding these tags/refs would cause a 3% increase
in the size of the repo. The lucene repo is a little larger currently, but
the new tag sizes should be identical.

- Houston

On Tue, Jan 4, 2022 at 3:36 PM Jan Høydahl  wrote:

> We have edit history ever since the earliest svn commits, we just lack a
> years worth of commits from the latest 8.x versions, so from a traceability
> view it makes sense, instead of having to look in two repos. Do you know
> how much weight it will add to a full clone?
>
> Jan Høydahl
>
> > 4. jan. 2022 kl. 21:01 skrev Dawid Weiss :
> >
> > 
> >>
> >> You can push a tag to a repo that doesn't already have that commit (or
> history of commits)
> > in an existing branch, without issue.
> >
> > But why do it? These are refs - if they point to non-existing commits
> > then I honestly don't see any value in having them. It would
> > confuse the hell out of me.
> >
> >> They are separate projects, but with a shared history. I'd like to be
> able to go to the apache/solr github
> > and be able to go through the history of a file in different release
> > versions, even if that specific release happened
> > under apache/lucene-solr.
> >
> > This is a different requirement, actually. If Solr (or Lucene) would
> > like to keep such a history then I think it should just fetch those
> > release refs and all the commits leading to them. Since these projects
> > share a common root, there is nothing to prevent this from happening.
> > Then tags point at actual revisions and everything makes sense.
> >
> > This does not change the fact that I don't really see much value in
> > doing all this.
> >
> > Dawid
> >
> >> On Tue, Jan 4, 2022 at 8:30 PM Houston Putman 
> wrote:
> >>
> >> They don't have those commits, but they also don't have the commits for
> the
> >> previous release tags in the repo. You can go to any of the release
> tags, choose
> >> a commit to view and you will get a message saying:
> >>
> >>>
> >>> This commit does not belong to any branch on this repository,
> >>> and may belong to a fork outside of the repository.
> >>
> >>
> >> You can push a tag to a repo that doesn't already have that commit (or
> history of commits)
> >> in an existing branch, without issue.
> >>
> >> They are separate projects, but with a shared history. I'd like to be
> able to go to the apache/solr github
> >> and be able to go through the history of a file in different release
> versions, even if that specific release happened
> >> under apache/lucene-solr.
> >>
> >> - Houston
> >>
> >>> On Tue, Jan 4, 2022 at 2:02 PM Dawid Weiss 
> wrote:
> >>>
> >>>> As mentioned in SOLR-15874, we are not hosting the tags for the
> latest 8.x releases in the split apache/solr and apache/lucene
> repositories. All release tags made prior to the repository split exist in
> the new repos, so I see no reason that the newer 8.x tags cannot exist in
> the new repos as well.
> >>>
> >>> I'm not sure I understand - to create a tag you'd need that particular
> >>> commit - the "new" repositories for each project don't have those
> >>> commits (and arguably shouldn't have since they're, well, separate
> >>> projects now).
> >>>
> >>> Dawid
> >>>
> >>> -
> >>> 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...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Re: Mirroring the later 8.x release tags in the "new" split repositories

[Houston Putman]

They don't have those commits, but they also don't have the commits for the
previous release tags in the repo. You can go to any of the release tags,
choose
a commit to view and you will get a message saying:


> This commit does not belong to any branch on this repository,
> and may belong to a fork outside of the repository.


You can push a tag to a repo that doesn't already have that commit (or
history of commits)
in an existing branch, without issue.

They are separate projects, but with a shared history. I'd like to be able
to go to the apache/solr github
and be able to go through the history of a file in different release
versions, even if that specific release happened
under apache/lucene-solr.

- Houston

On Tue, Jan 4, 2022 at 2:02 PM Dawid Weiss  wrote:

> > As mentioned in SOLR-15874, we are not hosting the tags for the latest
> 8.x releases in the split apache/solr and apache/lucene repositories. All
> release tags made prior to the repository split exist in the new repos, so
> I see no reason that the newer 8.x tags cannot exist in the new repos as
> well.
>
> I'm not sure I understand - to create a tag you'd need that particular
> commit - the "new" repositories for each project don't have those
> commits (and arguably shouldn't have since they're, well, separate
> projects now).
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

Mirroring the later 8.x release tags in the "new" split repositories

[Houston Putman]

Hello all,

As mentioned in SOLR-15874
, we are not hosting the
tags for the latest 8.x releases in the split apache/solr and apache/lucene
repositories. All release tags made prior to the repository split exist in
the new repos, so I see no reason that the newer 8.x tags cannot exist in
the new repos as well.

Eventually once Solr is on 10.x, there will be very little need for the
lucene-solr repository, since Lucene has already moved on past 8.x. At that
point, having all the previous release tags in the new repos will make it
possible to remove the lucene-solr repo. (Although that is not something I
want to discuss on this thread, just merely one reason hosting the tags is
a good idea)

I'm happy to mirror the tags to each repository manually, unless anyone has
objections (for either lucene or solr).

- Houston

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Houston Putman]

Congrats Haoyu!

On Mon, Dec 20, 2021 at 12:42 PM Anshum Gupta 
wrote:

> Congratulations and welcome, Haoyu!
>
> On Sun, Dec 19, 2021 at 1:12 AM Dawid Weiss  wrote:
>
>> 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
>>
>>
>
> --
> Anshum Gupta
>

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Houston Putman]

SUCCESS! [1:10:32.826846]

Also ran Jan's docker image using the Solr Operator and everything looked
good to me. I also tested some of the fixes included in the release.

+1 (binding)

- Houston

On Wed, Dec 15, 2021 at 3:42 PM Timothy Potter  wrote:

> Awesome, thanks Uwe!
>
> On Wed, Dec 15, 2021 at 1:39 PM Uwe Schindler  wrote:
> >
> > Hi,
> >
> > I was able to start the solr.cmd and boot up techproducts. I also
> quickly checked the changed endpoints like "export", "status", "api". Only
> "autoscaling" showed exceptions about zookeeper, not sure if this should
> show some help info instead (I ran scripts without any solr node running)..
> >
> > I haven't any problem with whitespace in my CWD.
> >
> > Uwe
> >
> > -
> > Uwe Schindler
> > Achterdiek 19, D-28357 Bremen
> > https://www.thetaphi.de
> > eMail: u...@thetaphi.de
> >
> > > -Original Message-
> > > From: Uwe Schindler 
> > > Sent: Wednesday, December 15, 2021 9:27 PM
> > > To: dev@lucene.apache.org
> > > Subject: RE: [VOTE] Release Lucene/Solr 8.11.1 RC1
> > >
> > > Will do!
> > >
> > > Uwe
> > >
> > > -
> > > Uwe Schindler
> > > Achterdiek 19, D-28357 Bremen
> > > https://www.thetaphi.de
> > > eMail: u...@thetaphi.de
> > >
> > > > -Original Message-
> > > > From: Timothy Potter 
> > > > Sent: Wednesday, December 15, 2021 9:19 PM
> > > > To: lucene dev 
> > > > Subject: Re: [VOTE] Release Lucene/Solr 8.11.1 RC1
> > > >
> > > > Anyone try manually launching the RC on Windows? There's a change to
> > > > bin/solr.cmd in this release. I tested before I committed but always
> > > > good to re-test with the RC just in case.
> > > >
> > > > Tim
> > > >
> > > > On Wed, Dec 15, 2021 at 12:30 PM Dawid Weiss 
> > > > wrote:
> > > > >
> > > > > SUCCESS! [0:56:37.756257]
> > > > >
> > > > > +1
> > > > >
> > > > > On Tue, Dec 14, 2021 at 3:36 PM Jan Høydahl  >
> > > > 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
> > > > > >
> > > > > > 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
> > >
> > >
> > > -
> > > 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: Welcome Julie Tibshirani to the Lucene PMC

[Houston Putman]

Congrats Julie, welcome!

On Wed, Dec 1, 2021 at 9:27 PM Nhat Nguyen 
wrote:

> Congratulations, Julie!
>
> On Wed, Dec 1, 2021 at 1:17 PM Julie Tibshirani 
> wrote:
>
>> Thank you everyone. I'm really looking forward to contributing!
>>
>> Julie
>>
>> On Wed, Dec 1, 2021 at 9:39 AM Michael Wechner 
>> wrote:
>>
>>> great to hear, congratulations, Julie!
>>>
>>> Am 01.12.21 um 14:29 schrieb Mayya Sharipova:
>>>
>>> Congratulations, Julie ! Very well deserved!
>>>
>>> On Wed, Dec 1, 2021 at 2:45 PM Ignacio Vera  wrote:
>>>
 Congratulations Julie!

 On Wed, Dec 1, 2021 at 10:03 AM Alan Woodward 
 wrote:

> Congratulations and welcome!
>
> - Alan
>
> > On 30 Nov 2021, at 21:49, Adrien Grand  wrote:
> >
> > 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/Solr 8.11.0 RC1

[Houston Putman]

+1
SUCCESS! [1:04:19.544964]

Also tested extensively with the Solr Operator.

On Thu, Nov 11, 2021 at 1:06 PM Bruno Roustant 
wrote:

> +1
> SUCCESS! [1:17:35.209577]
>
> Le jeu. 11 nov. 2021 à 18:30, Julie Tibshirani  a
> écrit :
>
>> +1 (nonbinding)
>> SUCCESS! [1:04:58.967300]
>>
>> On Thu, Nov 11, 2021 at 7:12 AM David Smiley  wrote:
>>
>>> +1
>>> SUCCESS! [0:57:23.948714]
>>>
>>

Re: [VOTE] Release Lucene/Solr 8.10.1 RC1

[Houston Putman]

+1 SUCCESS! [1:05:55.854939]

On Thu, Oct 14, 2021 at 9:29 AM Michael Gibney 
wrote:

> +1 SUCCESS! [1:00:31.099832]
>
> On Thu, Oct 14, 2021 at 7:42 AM Ignacio Vera  wrote:
>
>> +1
>>
>> SUCCESS! [1:01:50.808390]
>>
>> On Thu, Oct 14, 2021 at 1:40 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> +1
>>>
>>>
>>> SUCCESS! [0:44:35.590557]
>>>
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Tue, Oct 12, 2021 at 8:00 PM Mayya Sharipova 
>>> wrote:
>>>
 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: Bugfix release Lucene/Solr 8.10.1

[Houston Putman]

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: [VOTE] Release Lucene/Solr 8.10.0 RC1

[Houston Putman]

SUCCESS! [1:04:04.335749]

I also ran through some manual testing with the new s3-repository contrib
using your convenience docker image, and it worked as expected.

+1

On Fri, Sep 24, 2021 at 4:37 AM Namgyu Kim  wrote:

> +1 SUCCESS! [1:01:04.224368]
>
> On Thu, Sep 23, 2021 at 12:42 AM Timothy Potter 
> wrote:
>
>> 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
>>
>>

Re: [JENKINS-MAVEN] Lucene » Lucene-Solr-Maven-8.x #379: POMs out of sync

[Houston Putman]

Ok all of the ant targets should be fine now with the s3-repository code,
except for the smoketest. That will require a larger fix possibly, and is
tracked in SOLR-15599 <https://issues.apache.org/jira/browse/SOLR-15599>.

- Houston

On Mon, Aug 23, 2021 at 3:26 PM Greg Miller  wrote:

> No worries. Thanks for the confirmation!
>
> Cheers,
> -Greg
>
> On Mon, Aug 23, 2021 at 12:21 PM Houston Putman 
> wrote:
> >
> > Yes it would. I forgot to remove the non-needed dependency from
> everywhere it seems. I'll get it working soon. Sorry for the annoyance.
> >
> > On Mon, Aug 23, 2021 at 3:02 PM Greg Miller  wrote:
> >>
> >> Would this also account for the ant precommit check failing? I'm not
> >> able to repro this locally, but am seeing this failure in a PR I just
> >> published:
> >>
> >> check-lib-versions:
> >> 43218 [echo] Lib versions check under:
> >> /home/runner/work/lucene-solr/lucene-solr/lucene/..
> >> 43219[libversions] :: loading settings :: file =
> >>
> /home/runner/work/lucene-solr/lucene-solr/lucene/top-level-ivy-settings.xml
> >> 43220[libversions] ORPHAN coordinate key
> >> '/com.amazonaws/aws-java-sdk-bom' in ivy-versions.properties is not
> >> found in any ivy.xml file.
> >> 43221[libversions] Found 0 indirect dependency version conflicts.
> >> 43222[libversions] Checked that ivy-versions.properties and
> >> ivy-ignore-conflicts.properties have lexically sorted '/org/name' keys
> >> and no duplicates or orphans.
> >> 43223[libversions] Scanned 51 ivy.xml files for rev="${/org/name}"
> format.
> >> 43224[libversions] Completed in 2.83s., 1 error(s).
> >> 43225
> >> 43226BUILD FAILED
> >> 43227/home/runner/work/lucene-solr/lucene-solr/build.xml:121: The
> >> following error occurred while executing this line:
> >> 43228/home/runner/work/lucene-solr/lucene-solr/lucene/build.xml:108:
> >> The following error occurred while executing this line:
> >>
> 43229/home/runner/work/lucene-solr/lucene-solr/lucene/tools/custom-tasks.xml:108:
> >> Lib versions check failed. Check the logs.
> >>
> >> Cheers,
> >> -Greg
> >>
> >>
> >> On Mon, Aug 23, 2021 at 9:37 AM Houston Putman 
> wrote:
> >> >
> >> > Thanks for calling this out Mike.
> >> >
> >> > It's related to SOLR-15089. I'll get it sorted out, as well as some
> test flakiness that were introduced by that ticket.
> >> >
> >> > - Houston
> >> >
> >> > On Mon, Aug 23, 2021 at 6:56 AM Michael McCandless <
> luc...@mikemccandless.com> wrote:
> >> >>
> >> >> This is the actual error -- ring any bells?:
> >> >>
> >> >>
> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-Maven-8.x/lucene/common-build.xml:726:
> Could not resolve artifacts: Could not find artifact
> com.amazonaws:aws-java-sdk-bom:jar:1.12.42 in central (
> https://repo1.maven.org/maven2/)
> >> >>
> >> >>
> >> >> Mike McCandless
> >> >>
> >> >> http://blog.mikemccandless.com
> >> >>
> >> >>
> >> >> On Fri, Aug 20, 2021 at 8:45 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
> >> >>>
> >> >>> Lucene » Lucene-Solr-Maven-8.x - Build # 379 - Still Failing:
> >> >>>
> >> >>> Check console output at
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Maven-8.x/379/ to
> view the results.
> >> >>>
> >> >>>
> -
> >> >>> 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
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [JENKINS-MAVEN] Lucene » Lucene-Solr-Maven-8.x #379: POMs out of sync

[Houston Putman]

Yes it would. I forgot to remove the non-needed dependency from everywhere
it seems. I'll get it working soon. Sorry for the annoyance.

On Mon, Aug 23, 2021 at 3:02 PM Greg Miller  wrote:

> Would this also account for the ant precommit check failing? I'm not
> able to repro this locally, but am seeing this failure in a PR I just
> published:
>
> check-lib-versions:
> 43218 [echo] Lib versions check under:
> /home/runner/work/lucene-solr/lucene-solr/lucene/..
> 43219[libversions] :: loading settings :: file =
> /home/runner/work/lucene-solr/lucene-solr/lucene/top-level-ivy-settings.xml
> 43220[libversions] ORPHAN coordinate key
> '/com.amazonaws/aws-java-sdk-bom' in ivy-versions.properties is not
> found in any ivy.xml file.
> 43221[libversions] Found 0 indirect dependency version conflicts.
> 43222[libversions] Checked that ivy-versions.properties and
> ivy-ignore-conflicts.properties have lexically sorted '/org/name' keys
> and no duplicates or orphans.
> 43223[libversions] Scanned 51 ivy.xml files for rev="${/org/name}" format.
> 43224[libversions] Completed in 2.83s., 1 error(s).
> 43225
> 43226BUILD FAILED
> 43227/home/runner/work/lucene-solr/lucene-solr/build.xml:121: The
> following error occurred while executing this line:
> 43228/home/runner/work/lucene-solr/lucene-solr/lucene/build.xml:108:
> The following error occurred while executing this line:
>
> 43229/home/runner/work/lucene-solr/lucene-solr/lucene/tools/custom-tasks.xml:108:
> Lib versions check failed. Check the logs.
>
> Cheers,
> -Greg
>
>
> On Mon, Aug 23, 2021 at 9:37 AM Houston Putman 
> wrote:
> >
> > Thanks for calling this out Mike.
> >
> > It's related to SOLR-15089. I'll get it sorted out, as well as some test
> flakiness that were introduced by that ticket.
> >
> > - Houston
> >
> > On Mon, Aug 23, 2021 at 6:56 AM Michael McCandless <
> luc...@mikemccandless.com> wrote:
> >>
> >> This is the actual error -- ring any bells?:
> >>
> >>
> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-Maven-8.x/lucene/common-build.xml:726:
> Could not resolve artifacts: Could not find artifact
> com.amazonaws:aws-java-sdk-bom:jar:1.12.42 in central (
> https://repo1.maven.org/maven2/)
> >>
> >>
> >> Mike McCandless
> >>
> >> http://blog.mikemccandless.com
> >>
> >>
> >> On Fri, Aug 20, 2021 at 8:45 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
> >>>
> >>> Lucene » Lucene-Solr-Maven-8.x - Build # 379 - Still Failing:
> >>>
> >>> Check console output at
> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Maven-8.x/379/ to
> view the results.
> >>>
> >>> -
> >>> 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
>
>

Re: [JENKINS-MAVEN] Lucene » Lucene-Solr-Maven-8.x #379: POMs out of sync

[Houston Putman]

Thanks for calling this out Mike.

It's related to SOLR-15089
. I'll get it sorted out,
as well as some test flakiness that were introduced by that ticket.

- Houston

On Mon, Aug 23, 2021 at 6:56 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> This is the actual error -- ring any bells?:
>
> /home/jenkins/jenkins-slave/workspace/Lucene/Lucene-Solr-Maven-8.x/lucene/common-build.xml:726:
>  Could not resolve artifacts: Could not find artifact 
> com.amazonaws:aws-java-sdk-bom:jar:1.12.42 in central 
> (https://repo1.maven.org/maven2/)
>
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>
>
> On Fri, Aug 20, 2021 at 8:45 PM Apache Jenkins Server <
> jenk...@builds.apache.org> wrote:
>
>> Lucene » Lucene-Solr-Maven-8.x - Build # 379 - Still Failing:
>>
>> Check console output at
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Maven-8.x/379/
>> to view the results.
>>
>> -
>> To unsubscribe, e-mail: builds-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: builds-h...@lucene.apache.org
>
>

Re: Welcome Mayya Sharipova to the Lucene PMC

[Houston Putman]

Congrats and welcome Mayya!

On Wed, Jun 30, 2021 at 3:17 PM Tim Allison  wrote:

> Welcome Mayya!
>
> On Wed, Jun 30, 2021 at 1:07 PM Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> >
> > Welcome Mayya!
> >
> > From: dev@lucene.apache.org At: 06/28/21 14:16:54 UTC+1:00
> > To: dev@lucene.apache.org, mayya.sharip...@elastic.co
> > Subject: Welcome Mayya Sharipova to the Lucene PMC
> >
> > I am pleased to announce that Mayya has accepted an invitation to join
> > the Lucene PMC!
> >
> > Congratulations, and welcome aboard!
> >
> > -
> > 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 Greg Miller as Lucene committer

[Houston Putman]

Congrats and welcome Greg!

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

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

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

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

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

[Houston Putman]

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

- Houston

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

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

 Thank you.

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

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

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

[Houston Putman]

Hey Mayya, would you mind to wait until at least Tuesday (6/1)?

We are trying to backport SOLR-14978 to 8.x, and would really like it
included in 8.9.

- Houston

On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova
 wrote:

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


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

Re: Separate git repo(s) for Solr modules

[Houston Putman]

I completely agree with Ilan.

Keeping the projects in the same repo was the only long term viable way of
having Solr depend on a snapshot version of Lucene.

And I'm sorry if I misspoke earlier. You can always "work on both at
the same time" even when we rely on a release version of Lucene,
but you won't be able to commit the Solr code until a Lucene release has
been made that includes those changes.

Also I think discussion has taken over the wrong thread. The thread was
originally about modules for various Solr plugins and projects.

- Houston

On Tue, May 4, 2021 at 7:02 AM 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 <
>>>>> ep...@opensourceconnections.com> 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 similar to how I
>>>>> test multiple versions in one of my pet projects by using a CI build 
>>>>> matrix
>>>>> of a configurable dependency.  I didn't know Testcontainer.org has its own
>>>>> Solr module -- https://www.testcontainers.org/modules/solr/ but we
>>>>> implemented that ourselves; not hard.
>>>>> >

Re: Separate git repo(s) for Solr modules

[Houston Putman]

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 <
>> ep...@opensourceconnections.com> 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 similar to how I test
>> multiple versions in one of my pet projects by using a CI build matrix of a
>> configurable dependency.  I didn't know Testcontainer.org has its own Solr
>> module -- https://www.testcontainers.org/modules/solr/ but we
>> implemented that ourselves; not hard.
>> >
>> >>
>> >> Trying to maintain across multiple versions is kind of a Sisyphean
>> task, and I don’t think plays to open source communities strengths.   It’s
>> hard enough to keep all components of Solr up to date with the latest
>> Lucene and the latest Solr….  (Try out wt=xlsx Response Writer, it’s
>> currently broken on master) .  Reminds me of the Apache Gump project ;-)
>> >>
>> >> If something is really going to be backcompatible across certain
>> versions, then maybe having it’s own repo makes sense,
>> >
>> >
>> > 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
>> >
>> >>
>> >> but I suspect it means those components may go stale….   Look at DIH
>> and Velocity components that are moved over to their own repos, both are
>> getting stale, and I’d argue it’s because they don’t live in the main
>> project where all of us have oversight and easy access.
>> >
>> >
>> > Agreed :-(
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> -
> Noble Paul
>

Re: Welcome Peter Gromov as Lucene committer

[Houston Putman]

Congrats!

On Wed, Apr 7, 2021 at 12:47 PM Anshum Gupta  wrote:

> Congratulations and welcome, Peter!
>
> On Tue, Apr 6, 2021 at 10:48 AM Robert Muir  wrote:
>
>> 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!
>>
>>
>
> --
> Anshum Gupta
>

Re: Request times metric for collection

[Houston Putman]

Hey Alex,

This is likely a better question for us...@solr.apache.org.

- Houston

On Tue, Mar 16, 2021 at 12:39 AM Alex Bulygin 
wrote:

> Good afternoon everyone! Someone can tell me please, metric request time
> can be taken only by cores? Are there any aggregates on the collection or
> in the collection + host?
> Are there any open best practices for situations where there are many
> cores?
>
> --
> Alex Bulygin
>

Re: [solr-operator] branch main updated (fc76f66 -> 75830c3)

[Houston Putman]

Should be done now.

https://github.com/apache/solr-operator/commit/d236b4f2cc2713c410554cc5166064b566b58342#diff-b4c2a69650f9ac84008ad9f745859a645c9466350ffdfe5f919655039ee2e2c3

- Houston

On Mon, Mar 15, 2021 at 1:37 PM Uwe Schindler  wrote:

> Hi Houston,
>
> Can we change the commit mail address of this repository? Or does this
> need INFRA involvement?
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: hous...@apache.org 
> > Sent: Monday, March 15, 2021 6:01 PM
> > To: comm...@lucene.apache.org
> > Subject: [solr-operator] branch main updated (fc76f66 -> 75830c3)
> >
> > This is an automated email from the ASF dual-hosted git repository.
> >
> > houston pushed a change to branch main
> > in repository https://gitbox.apache.org/repos/asf/solr-operator.git.
> >
> >
> > from fc76f66  Add conditional dependency for zk-operator helm chart
> (#231)
> >  add 75830c3  Upgrade kustomize. Modernize helm manifest generation.
> > (#238)
> >
> > No new revisions were added by this update.
> >
> > Summary of changes:
> >  hack/helm/copy_crds_roles_helm.sh | 34
> +++---
> >  hack/install_dependencies.sh  |  5 ++---
> >  helm/solr-operator/crds/crds.yaml |  3 +++
> >  3 files changed, 24 insertions(+), 18 deletions(-)
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Bruno to the Apache Lucene PMC

[Houston Putman]

Congrats and welcome Bruno!

On Thu, Mar 11, 2021 at 8:32 AM David Smiley  wrote:

> Welcome Bruno!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 10, 2021 at 7:56 PM Mike Drob  wrote:
>
>> I am pleased to announce that Bruno has accepted an invitation to join
>> the Lucene PMC!
>>
>> Congratulations, and welcome aboard!
>>
>> Mike
>>
>

Re: Separate Solr build: help with the remaining last mile needed.

[Houston Putman]

For posterity, the docker build broke because github changed the version of
ubuntu_latest in github actions from 18.04 to 20.04.

The ACL package is installed by default in Ubuntu 18, but not Ubuntu 20.
Installing it at the beginning of the docker action fixes the build.

On Fri, Mar 5, 2021 at 3:21 PM Mike Drob  wrote:

> I created a PR for the tests
> https://github.com/apache/lucene-solr/pull/2462
>
> On Fri, Mar 5, 2021 at 1:43 PM Dawid Weiss  wrote:
>
>> This can be done later too, it's not crucial - these files will be
>> just ignored for compilation immediately after the split.
>>
>> D.
>>
>> On Fri, Mar 5, 2021 at 8:11 PM Mike Drob  wrote:
>> >
>> > I think I can make TestICUCollationField work without depending on
>> Lucene test sources. The other two will be a bit trickier.
>> >
>> > On Fri, Mar 5, 2021 at 1:56 AM Dawid Weiss 
>> wrote:
>> >>
>> >> > ./gradlew -Dskip.lucene=true assemble check -x test -x documentation
>> >> > -x checkBrokenLinks -x checkLocalJavadocLinksSite
>> >>
>> >> I made Solr documentation compile last night. Some of the generated
>> >> links point at void (and thus the broken links checker fails) but I
>> >> think it's enough to make the repository split and then clean up
>> >> what's needed in each corresponding repository.
>> >>
>> >> So... this Sunday? Prior to that, we'd have to disable CI build
>> >> services currently pointing at the master branch so that they don't
>> >> start failing (I'll remove all content from master).
>> >>
>> >> 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: Separate Solr build: help with the remaining last mile needed.

[Houston Putman]

Aha it's broken independently of your PR. I'll try to fix it, sorry for the
noise.

- Houston

On Thu, Mar 4, 2021 at 1:48 PM Dawid Weiss  wrote:

> Thanks. I might have broken something... but it seems unlikely. I
> merely shuffled some things around - it should be an identical build.
>
> D.
>
> On Thu, Mar 4, 2021 at 7:45 PM Houston Putman 
> wrote:
> >
> > It worked as of 10 days ago:
> https://github.com/apache/lucene-solr/actions/workflows/docker-test.yml
> >
> > I created a test PR to see if it works based on master:
> https://github.com/apache/lucene-solr/pull/2454
> >
> > On Thu, Mar 4, 2021 at 1:39 PM Dawid Weiss 
> wrote:
> >>
> >> Thanks Houston. Is this failure on the branch only (does it work on
> master)?
> >>
> >> Dawid
> >>
> >> On Thu, Mar 4, 2021 at 6:48 PM Houston Putman 
> wrote:
> >> >
> >> > I'm not sure why the docker github action is failing... I've tried it
> locally and it works fine. I'll do some more investigation.
> >> >
> >> > On Thu, Mar 4, 2021 at 3:25 AM Dawid Weiss 
> wrote:
> >> >>
> >> >> Hi folks,
> >> >>
> >> >> I'll need some help with some remaining tasks to make the transition
> >> >> easier after the solr repo split. I've made some changes to allow
> >> >> building just Solr or just Lucene on master --
> >> >>
> >> >> https://github.com/apache/lucene-solr/pull/2448
> >> >>
> >> >> 1. I really don't know much about docker testing and why it fails on
> that PR.
> >> >>
> >> >> 2. Lucene build seems to work just fine.
> >> >>
> >> >> 3. You can build Solr independently (with a Lucene snapshot from
> >> >> Apache repository) by running:
> >> >>
> >> >> ./gradlew -Dskip.lucene=true assemble check -x test -x documentation
> >> >> -x checkBrokenLinks -x checkLocalJavadocLinksSite
> >> >>
> >> >> the "-x" tasks are what I'll need some help with - I guess they do
> >> >> have cross-references to Lucene-generated stuff that needs to be
> >> >> replaced (or dropped).
> >> >>
> >> >> 4. There are three tests that need to be removed from the codebase,
> >> >> moved to Lucene or rewritten: TestICUCollationField,
> >> >> TestLuceneIndexBackCompat and TestXmlQParser. These tests require
> >> >> access to Lucene test sources and these won't be published as an
> >> >> artifact.
> >> >>
> >> >> An alternative to trying to solve the above is to just split the repo
> >> >> and let it burn/ crash, but I thought by fixing those issues on
> >> >> current master branch we can prepare the infrastructure while
> >> >> everything else just works.
> >> >>
> >> >> 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
> >>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Separate Solr build: help with the remaining last mile needed.

[Houston Putman]

It worked as of 10 days ago:
https://github.com/apache/lucene-solr/actions/workflows/docker-test.yml

I created a test PR to see if it works based on master:
https://github.com/apache/lucene-solr/pull/2454

On Thu, Mar 4, 2021 at 1:39 PM Dawid Weiss  wrote:

> Thanks Houston. Is this failure on the branch only (does it work on
> master)?
>
> Dawid
>
> On Thu, Mar 4, 2021 at 6:48 PM Houston Putman 
> wrote:
> >
> > I'm not sure why the docker github action is failing... I've tried it
> locally and it works fine. I'll do some more investigation.
> >
> > On Thu, Mar 4, 2021 at 3:25 AM Dawid Weiss 
> wrote:
> >>
> >> Hi folks,
> >>
> >> I'll need some help with some remaining tasks to make the transition
> >> easier after the solr repo split. I've made some changes to allow
> >> building just Solr or just Lucene on master --
> >>
> >> https://github.com/apache/lucene-solr/pull/2448
> >>
> >> 1. I really don't know much about docker testing and why it fails on
> that PR.
> >>
> >> 2. Lucene build seems to work just fine.
> >>
> >> 3. You can build Solr independently (with a Lucene snapshot from
> >> Apache repository) by running:
> >>
> >> ./gradlew -Dskip.lucene=true assemble check -x test -x documentation
> >> -x checkBrokenLinks -x checkLocalJavadocLinksSite
> >>
> >> the "-x" tasks are what I'll need some help with - I guess they do
> >> have cross-references to Lucene-generated stuff that needs to be
> >> replaced (or dropped).
> >>
> >> 4. There are three tests that need to be removed from the codebase,
> >> moved to Lucene or rewritten: TestICUCollationField,
> >> TestLuceneIndexBackCompat and TestXmlQParser. These tests require
> >> access to Lucene test sources and these won't be published as an
> >> artifact.
> >>
> >> An alternative to trying to solve the above is to just split the repo
> >> and let it burn/ crash, but I thought by fixing those issues on
> >> current master branch we can prepare the infrastructure while
> >> everything else just works.
> >>
> >> 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: Separate Solr build: help with the remaining last mile needed.

[Houston Putman]

I'm not sure why the docker github action is failing... I've tried it
locally and it works fine. I'll do some more investigation.

On Thu, Mar 4, 2021 at 3:25 AM Dawid Weiss  wrote:

> Hi folks,
>
> I'll need some help with some remaining tasks to make the transition
> easier after the solr repo split. I've made some changes to allow
> building just Solr or just Lucene on master --
>
> https://github.com/apache/lucene-solr/pull/2448
>
> 1. I really don't know much about docker testing and why it fails on that
> PR.
>
> 2. Lucene build seems to work just fine.
>
> 3. You can build Solr independently (with a Lucene snapshot from
> Apache repository) by running:
>
> ./gradlew -Dskip.lucene=true assemble check -x test -x documentation
> -x checkBrokenLinks -x checkLocalJavadocLinksSite
>
> the "-x" tasks are what I'll need some help with - I guess they do
> have cross-references to Lucene-generated stuff that needs to be
> replaced (or dropped).
>
> 4. There are three tests that need to be removed from the codebase,
> moved to Lucene or rewritten: TestICUCollationField,
> TestLuceneIndexBackCompat and TestXmlQParser. These tests require
> access to Lucene test sources and these won't be published as an
> artifact.
>
> An alternative to trying to solve the above is to just split the repo
> and let it burn/ crash, but I thought by fixing those issues on
> current master branch we can prepare the infrastructure while
> everything else just works.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Proposal for the Lucene Dependency after git repo split

[Houston Putman]

I don't think Jan's workflow blocks Solr releases on Lucene releases. It
just blocks this one feature branch merge on a Lucene release. Multiple
Solr releases can happen between step 6 and step 7.

I completely agree with that being the workflow going forward with separate
repos, Jan. It will unfortunately be a pain to integrate changes that
affect both Lucene and Solr, but I think that's just a consequence of
splitting the projects.

Neither option gives us everything we want, so here are the pros and cons
in my opinion.

Using a snapshot lucene version
- Easier to make changes to lucene and solr concurrently
- Solr releases are blocked until the snapshot version being depended on is
released.
- Builds may break at any time, and possibly for different sets of users
depending on dependency caches.

Using a released lucene version
- Harder to update lucene and solr concurrently
- Solr can make releases independent of Lucene's release schedule
- Builds are stable and consistent.

Personally I think stability and the ability to own our own release
schedule outweigh the benefits of being able to iterate on both projects
concurrently. But it's definitely something that we should decide on as a
community.

On Fri, Feb 26, 2021 at 12:43 PM Mike Drob  wrote:

> The part of this process that I really don't like is that Solr then still
> becomes beholden to Lucene's release schedule. We don't know how long step
> 7 takes, and will be effectively blocked from making our own releases until
> that happens.
>
> On Fri, Feb 26, 2021 at 8:51 AM Jan Høydahl  wrote:
>
>> The developer workflow for adding something to both Lucene and Solr would
>> be as any other dependency, right?
>> So say we are on Luene 9.0. This is the process in my head:
>>
>>1. Adapt Lucene as needed, and "mvn install" lucene-9.1-SNAPSHOT to
>>your local laptop (whatever command that is in gradle)
>>2. Make your Solr feature branch depend on lucene-9.1-SNAPSHOT
>>instead of lucene-9.0.0 -hopefully Gradle will pick the local version over
>>Apache Nexus version
>>3. Iterate 1-2 until happy
>>4. Make a Lucene PR and eventually commit the Lucene change
>>5. After next Jenkins build the feature is in Apache Nexus snapshot
>>as lucene-9.1-SNAPSHOT
>>6. Now the Solr Pull Request will compile and can be tested by others
>>7. Wait until Lucene 9.1 release
>>8. Upgrade Solr's lucene dependency on 'main'
>>9. Merge Solr PR
>>10. Backporting will be a similar process, i.e. first backport and
>>release in Lucene, then backport in Sol
>>
>> Hmm, as I wrote this list I can understand why so many features were
>> added only to Solr and not to Lucene in the early days :)
>>
>> Jan
>>
>> 26. feb. 2021 kl. 14:22 skrev Gus Heck :
>>
>> Except I just finished helping a contributor with a feature that touches
>> both and I know for a fact  that it was developed for his customer who was
>> using solr (payload inequalities)... and have another in the works (the
>> AQP) Not being able to enhance lucene to support a feature in solr is
>> an issue IMHO.
>>
>> On Thu, Feb 25, 2021 at 6:05 PM Mike Drob  wrote:
>>
>>> It is possible to publish snapshots into the Apache Nexus repository.
>>> That said, I think it is a bad idea for Solr to depend on Lucene snapshots
>>> because that constrains the ability to do releases. Either you have to wait
>>> for a Lucene release and then you can cut over, or you have to figure out
>>> what changes you need to roll back.
>>>
>>> Features today rarely touch both fronts anyway, they usually land in
>>> Lucene first and then percolate into Solr. For an easy example, we can see
>>> how WAND was developed recently.
>>>
>>> On Thu, Feb 25, 2021 at 5:02 PM Houston Putman 
>>> wrote:
>>>
>>>> Once the projects are on separate release cadences there wont be an
>>>> ability to “add on both fronts” anymore. You will have to add to lucene,
>>>> wait for a release, then add to Solr once Solr upgrades its lucene
>>>> dependency to that new version. I dont imagine that we are going to keep
>>>> Solr master/main, or even 8x, 9x, etc, depending on Lucene snaphsots in
>>>> perpetuity. After it becomes possible (when lucene 9.0 is released) we
>>>> should only be using released lucene versions as dependencies for every
>>>> version branch in Solr.
>>>>
>>>> On Thu, Feb 25, 2021 at 5:49 PM Gus Heck  wrote:
>>>>
>>>>> Until the first feature that wan

Re: Proposal for the Lucene Dependency after git repo split

[Houston Putman]

Once the projects are on separate release cadences there wont be an ability
to “add on both fronts” anymore. You will have to add to lucene, wait for a
release, then add to Solr once Solr upgrades its lucene dependency to that
new version. I dont imagine that we are going to keep Solr master/main, or
even 8x, 9x, etc, depending on Lucene snaphsots in perpetuity. After it
becomes possible (when lucene 9.0 is released) we should only be using
released lucene versions as dependencies for every version branch in Solr.

On Thu, Feb 25, 2021 at 5:49 PM Gus Heck  wrote:

> Until the first feature that wants to add something on both fronts... Is
> it possible for Lucene to publish nightly snapshots? I know there is some
> level of support for snapshots in central, though I don't know what
> their usage policies are. If that's too restricted is there an artifact
> repo controlled by the ASF that could be used? (An implementation of Apache
> Archiva?) This would have the added benefit of allowing solr to detect when
> Lucene breaks something before its released.
>
> On Thu, Feb 25, 2021 at 4:50 PM Houston Putman 
> wrote:
>
>> Hey everyone,
>>
>> Currently there is discussion going on, in SOLR-14762
>> <https://issues.apache.org/jira/browse/SOLR-14762>, regarding the split
>> of the lucene-solr repo into individual repos for Solr and Lucene. There
>> seems to be agreement that we shouldn't wait for a Lucene release to do the
>> split, and instead split now and release whenever that happens.
>>
>> The biggest issue that arises there is that Solr's master branch is
>> obviously based on Lucene's master branch, since they are currently the
>> same. So when the split happens, Solr master will have to depend on Lucene
>> 9.0-SNAPSHOT. We can have solr merely depend on the lucene snapshot, but
>> that will result in inconsistent builds, depending on whatever cached
>> dependencies each dev has locally. Personally, I think that will cause a
>> bunch of build errors and headaches for everyone trying to maintain Solr.
>>
>> There is another option though. We could instead do an *alpha* "release"
>> of lucene-solr 9.0 right before the repo is split. Therefore Solr can
>> reliably depend on a stable version of lucene until 9.0 is truly released.
>> (And lucene can use a stable version of Solr, if it sees a need for that).
>> There would be no guarantees for using this alpha release, and we don't
>> have to advertise it at all.
>>
>> It's not perfect, but I think it would be preferable to depending on an
>> ever-changing SNAPSHOT lucene.
>>
>> - Houston
>>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>

Proposal for the Lucene Dependency after git repo split

[Houston Putman]

Hey everyone,

Currently there is discussion going on, in SOLR-14762
, regarding the split of
the lucene-solr repo into individual repos for Solr and Lucene. There seems
to be agreement that we shouldn't wait for a Lucene release to do the
split, and instead split now and release whenever that happens.

The biggest issue that arises there is that Solr's master branch is
obviously based on Lucene's master branch, since they are currently the
same. So when the split happens, Solr master will have to depend on Lucene
9.0-SNAPSHOT. We can have solr merely depend on the lucene snapshot, but
that will result in inconsistent builds, depending on whatever cached
dependencies each dev has locally. Personally, I think that will cause a
bunch of build errors and headaches for everyone trying to maintain Solr.

There is another option though. We could instead do an *alpha* "release" of
lucene-solr 9.0 right before the repo is split. Therefore Solr can reliably
depend on a stable version of lucene until 9.0 is truly released. (And
lucene can use a stable version of Solr, if it sees a need for that). There
would be no guarantees for using this alpha release, and we don't have to
advertise it at all.

It's not perfect, but I think it would be preferable to depending on an
ever-changing SNAPSHOT lucene.

- Houston

Re: Solr Docker Dependencies Question

[Houston Putman]

dirmngr: We used to use gpg for validating the downloaded solr binaries.
That is gone in the new build (though will have to be added back in
depending on what we decide around the "official image"). It can be removed
for now and added back later if needed.

Netcat: I believe netcat is for easy testing of ZK connection? Could be
wrong around the reasoning for that.

Gosu/Setfacl: I'm not 100% sure, but I believe you are correct that
it's only used for tests.

tini:  For docker, yes it's not necessary. But there are plenty of
container use cases outside of Docker (such as Kubernetes). If my
understanding is correct, the default use of the solr image

will invoke tini, so it's not something we will want to remove. Otherwise,
things like the OOM script will stop working.

wget: We need some way of connecting to HTTP in my opinion. Maybe I'm alone
here, but I find it frustrating that the image does not have curl installed.

- Houston

On Thu, Feb 25, 2021 at 11:26 AM Mike Drob  wrote:

> In our Dockerfile I see the line:
>
> > apt-get -y install acl dirmngr lsof procps wget netcat gosu tini;
>
> I understand how we use some of these, but not all of them.
>
> acl package provides setfacl, and gosu provides gosu, which look to be
> only used in tests? How much would we miss them if they were gone?
>
> dirmngr is for network access by gpg, but I don't see where we use gpg in
> the docker image at all.
>
> Tini comes baked with docker engine since 1.25, so maybe we don't need it
> and can provide instructions to run with --init? This seems convenient for
> users though so maybe we can leave it in.
>
> Where do we use netcat?
>
> lsof is used in the startup scripts, wget is used at a minimum to download
> jattach, procps is probably used in the startup scripts somewhere too for
> top or ps or something similar to get a pid.
>
> Thanks,
> Mike
>

Re: Congratulations to the new Lucene PMC Chair, Michael Sokolov!

[Houston Putman]

Congrats Michael!

On Thu, Feb 18, 2021 at 11:52 AM Martin Gainty  wrote:

> поздравления!
>
>
> --
> *From:* Julie Tibshirani 
> *Sent:* Wednesday, February 17, 2021 9:13 PM
> *To:* Lucene Dev 
> *Subject:* Re: Congratulations to the new Lucene PMC Chair, Michael
> Sokolov!
>
> Congratulations Mike!!
>
> On Wed, Feb 17, 2021 at 3:12 PM Gus Heck  wrote:
>
> Congratulations :)
>
> On Wed, Feb 17, 2021 at 5:42 PM Tomás Fernández Löbbe <
> tomasflo...@gmail.com> wrote:
>
> Congratulations Mike!
>
> On Wed, Feb 17, 2021 at 2:42 PM Steve Rowe  wrote:
>
> Congrats Mike!
>
> --
> Steve
>
> > On Feb 17, 2021, at 4:31 PM, Anshum Gupta 
> wrote:
> >
> > Every year, the Lucene PMC rotates the Lucene PMC chair and Apache Vice
> President position.
> >
> > This year we nominated and elected Michael Sokolov as the Chair, a
> decision that the board approved in its February 2021 meeting.
> >
> > Congratulations, Mike!
> >
> > --
> > Anshum Gupta
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)
>
>

Re: Congratulations to the new Apache Solr PMC Chair, Jan Høydahl!

[Houston Putman]

Congrats Jan!!

On Thu, Feb 18, 2021 at 2:21 PM Tomás Fernández Löbbe 
wrote:

> Congratulations Jan!
>
> On Thu, Feb 18, 2021 at 10:56 AM Anshum Gupta 
> wrote:
>
>> Hi everyone,
>>
>> I’d like to inform everyone that the newly formed Apache Solr PMC
>> nominated and elected Jan Høydahl for the position of the Solr PMC Chair
>> and Vice President. This decision was approved by the board in its February
>> 2021 meeting.
>>
>> Congratulations Jan!
>>
>> --
>> Anshum Gupta
>>
>

Re: [VOTE] Release Lucene/Solr 8.8.1 RC2

[Houston Putman]

SUCCESS! [1:01:43.630010]

+1 (binding)

On Wed, Feb 17, 2021 at 3:05 PM Tomás Fernández Löbbe 
wrote:

> SUCCESS! [1:07:31.079810]
>
> Tested upgrading from 8.7 and saw no problems
>
> +1 (binding)
>
> On Wed, Feb 17, 2021 at 2:58 AM Noble Paul  wrote:
>
>> SUCCESS! [1:04:46.520370]
>>
>> +1 Binding
>>
>> On Wed, Feb 17, 2021 at 1:44 PM Timothy Potter 
>> wrote:
>> >
>> > And I continue to struggle with the python3 command:
>> >
>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
>> >
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>> >
>> > On Tue, Feb 16, 2021 at 7:41 PM Timothy Potter 
>> wrote:
>> > >
>> > > Please vote for release candidate 2 for Lucene/Solr 8.8.1
>> > >
>> > > The artifacts can be downloaded from:
>> > >
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>> > >
>> > > 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.8.1-RC2-rev64f3b496bfee762a9d2dbff40700f457f4464dfe
>> > >
>> > > The vote will be open for at least 72 hours i.e. until 2021-02-20
>> 03:00 UTC.
>> > >
>> > > [ ] +1  approve
>> > > [ ] +0  no opinion
>> > > [ ] -1  disapprove (and reason why)
>> > >
>> > > Here is my +1 SUCCESS! [0:50:07.947952]
>> > >
>> > > Also, as with RC1, in addition to the smoke test, I built a Docker
>> > > image from the RC locally and verified:
>> > >
>> > > a. A rolling upgrade of a 3-node 8.7.0 cluster to the 8.8.1 RC
>> > > completes successfully w/o any NPEs or weirdness with leader election
>> > > / recoveries.
>> > > b. The base_url property is stored in replica state after the upgrade
>> > > c. A basic client application built with SolrJ 8.7.0 can load cluster
>> > > state info directly from ZK and query the 8.8.1 RC2 servers.
>> > > d. Same client app built with SolrJ 8.8.0 works as well.
>> > >
>> > > As this bug-fix release is primarily needed to address a SolrJ
>> > > back-compat break (SOLR-15145) and unfortunately our smoke tester
>> > > framework does not test for backcompat of older SolrJ against the RC,
>> > > I ask others to please test rolling upgrades of servers (ideally
>> > > multi-node clusters) running pre-8.8.0 to this RC if possible. Also,
>> > > please try client applications that are using an older SolrJ, esp.
>> > > those that load cluster state directly from ZK.
>> > >
>> > > Best regards,
>> > > Tim
>> >
>> > -
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: package-tgz-src / package-src-tgz equivilent missing from gradle build on master?

[Houston Putman]

Thanks for getting the list of steps currently taken.

These are easy to keep in the gradle task:

   - excluding jdk javadoc package-list files (for licensing reasons
   evidently)
   - setting chmod bits on scripts


building Changes.html from CHANGES.txt
>
I'm not sure building Changes.html is a huge necessity for the source
package. It's already done in the artifacts release, so maybe it's better
to just leave it there?
No other documentation sites are provided, so I find it a bit odd that this
is. I might be missing context though.

including lucene/CHANGES.txt in solr as LUCENE_CHANGES.txt
>
 While useful when the projects are connected, we probably won't keep this
when the projects are split (though I could be wrong on this, it would be
good to discuss anyways).
If that happens before 9.0 is cut, then this is likely moot.

So we could always start with a task that does a clean checkout, and the
two easy steps mentioned above. Should be a good first pass, that we can
change later if needed.

- Houston

On Wed, Feb 3, 2021 at 11:51 AM Chris Hostetter 
wrote:

>
> : It wasn't as much of an oversight as lack of knowledge how to deal
> : with it. I personally think the source distribution should be
> : equivalent to a clean git checkout. If this works for you then things
> : are relatively simple and I can do it.
>
> I'm not an authority here, so what works for me doesn't really matter :)
>
> While i would generally agree with you, I think there are some aspects of
> how the current targets work that are worth bearing in mind since
> deliberate decisions were made to get to this point - deliberate
> decisions should probably made to "undo" these choices..
>
> * excluding jdk javadoc package-list files (for licensing reasons
> evidently)
> * building Changes.html from CHANGES.txt
> * including lucnee/CHANGES.txt in solr as LUCENE_CHANGES.txt
> * setting chmod bits on scripts
>
>
> : On Wed, Feb 3, 2021 at 1:30 AM Chris Hostetter 
> wrote:
> : >
> : >
> : > thinking about how we (want to) build solr docker containers moving
> : > forward (SOLR-15102) lead me to realize that on the mster branch, there
> : > doesn't seem to be any logic to build the "*-src.tgz" files.
> : >
> : > On branch_8x "ant package" in both the lucene & solr directories
> handles
> : > this by delegation to either package-tgz-src or package-src-tgz (for
> some
> : > reason they have diff names in each dir?) ... but there doesn't seem
> to be
> : > any equivilent of this logic in the gradle build.
> : >
> : > Was this an oversight, or is ther some other plan for where/how we deal
> : > with "src.tgz" release artifacts in 9.x ?
> : >
> : >
> : > -Hoss
> : > http://www.lucidworks.com/
> : >
> : > -
> : > 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
> :
> :
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Solr Docker discussion

[Houston Putman]

Thanks for your input Hoss and Martijn.

So I've taken a look at the Elastic docker images [1], and they are
structured much like official images, except for the use of multi-stage
builds. They have no ARGs, and the docker context is merely the directory
in which the Dockerfile sits. With this in mind, and wanting to still take
advantage of the Official Docker Image, we will likely need to do some sort
of templating, as Hoss suggested. This can be automated using gradle fairly
easily I would imagine, and we could ensure that the only changes it makes
is to the part of the image that downloads Solr. That way there is very
little room for differences to occur between local and release images.

I do think that the current PR can be merged, regardless of our intent for
the release build, because the current way of building isn't going to be
acceptable for an official docker image release. I have made a ticket to
determine a release process for Solr docker images (9.0+) [2], this way we
can continue on with other parts of the Solr docker improvements while
being able to work on that in parallel.

To respond to the point about different architectures or operating system
images, I agree with you Martijn. I think we should support one operating
system by default, which would hopefully work with multiple architectures.
Dockerhub seems to support this for official images [3]. However if users
would want different operating system images, we will have given them the
ability to specify a custom base image and the dockerfile instructions
should be clear enough to migrate to other operating systems. That way they
can easily build their own.

- Houston

[1] https://github.com/elastic/dockerfiles/tree/v7.10.1/elasticsearch
[2] https://issues.apache.org/jira/browse/SOLR-15102
[3] https://github.com/docker-library/official-images#multiple-architectures

On Wed, Jan 20, 2021 at 11:55 AM Chris Hostetter 
wrote:

>
> : I'd recommend building apache/solr:x.y.z as part of the normal solr
> : release, then import those images into the official images library so
> ...
> : I don't know exactly what it takes for this to happen on the
> : official-image library side, but it seems that Elastisearch does this
>
> Oh wow ... ok, yeah: I had no idea that was allowed by docker-library
> based on the things I'd read about "official" docker images.  (per the
> links in the comments, the Dockerfile for the ES base image even uses
> multi-stage builds which would help seriously simplify the our 'official'
> image build process)
>
> Yeah, if this is something docker-library will allow us to do as well --
> define _/solr images directly 'FROM' apache/solr images -- and that
> those are/can be reproducibly built from a (multistage) Dockerfile in our
> git source repo identified by our release tag -- then by all means that
> seems like the best way to go.
>
> (I suspect the one finicky bit may be ensuring that docker-library is
> ok with us using '--build-arg' to set the version when building our base
> apache/solr images so that by building docker images from source checkout
> defaults to building a snapshot)
>
>
> -Hoss
> http://www.lucidworks.com/
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: g...@apache.org and lucene-solr-operator

[Houston Putman]

There was an unfortunate period where the repo was migrated, but we weren't
able to make the necessary changes to the mailing lists.

They should have been fixed roughly a week ago though. The new GH Issue/PR
emails should be going to the "issues" list.

- Houston

On Thu, Jan 21, 2021 at 4:12 PM David Smiley  wrote:

> I've observed lots of dev list messages from g...@apache.org for the
> lucene-solr-operator project.  They should be directed to the "issues" list
> instead.  Anshum, is this for you to handle?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Houston Putman]

+1

SUCCESS! [1:01:28.552891]

On Tue, Jan 19, 2021 at 1:53 PM Cassandra Targett 
wrote:

> I’ve put up the DRAFT version of the Ref Guide for 8.8:
> https://lucene.apache.org/solr/guide/8_8/.
>
> I also created the Jenkins job for building the 8.8 guide which pushes to
> the Nightlies server in case we have edits between now and release (
> https://nightlies.apache.org/Lucene/Solr-reference-guide-8.8/).
>
> Note branch_8_8 does not (yet) include the new Math Expressions guide
> being worked on in SOLR-13105. Still hoping that will make it, but thought
> I’d get this out sooner rather than later just in case.
> On Jan 19, 2021, 10:51 AM -0600, Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>, wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.8.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>
> 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.8.0-RC1-rev737cb9c49b08f6e3964c1e8a80132da3c764e027
>
> The vote will be open for at least 72 hours i.e. until 2021-01-22 17:00
> UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> 
>
>

Re: Solr Docker discussion

[Houston Putman]

Jan, thanks for clarifying your point on the Dockerfile layers, that makes
a lot of sense.

David, for your point on using the same Solr binary, I think we could
possibly use the same Dockerfile. The difference would be the input Solr
tgz that dockerTar puts into the "releases" sub-directory. Instead of
pulling in from the solr/packaging module, as you would for a local build,
you could instead download the Solr tgz from official mirrors. The docker
context tgz would be different, but the actual solr binary would be exactly
the same between all "release" builds.

I do think the "official release" docker image can be targeted via a
separate PR. This one already has a pretty big scope as it is. (Not to say
that your changes are bad David, I think they are fine to be included.)

Also Jan, I think having the nightly "master" images will be wonderful for
nightly integration and load tests!

- Houston

On Sun, Jan 17, 2021 at 3:28 PM David Smiley  wrote:

> Periodically rebuilding old images seems challenging in this new setup
> compared to docker-solr.  I suppose it could be done with a script that
> loops over release branches to check them out to then execute the
> appropriate gradle task to build & push.  But the requirement to use an
> identical Solr binary (same input tgz as was originally produced) is the
> real challenge, because we can't use the same Dockerfile.  The input TGZ is
> gone.  Maybe we could grab /opt/solr/* from the previous image, which can
> be referenced in a FROM?
>
> BTW I updated the Dockerfile significantly in Houston's recent PR.  I
> think it's a step in this direction.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sat, Jan 16, 2021 at 7:36 AM Jan Høydahl  wrote:
>
>> Great summary Houston!
>>
>> Could also be that docker team is willing to provide a “link” from
>> official _/solr to apache/solr if we can convince them of solid quality.
>> Think they do this for elastic images already.
>>
>> Since Docker images contain Linux and Java, which we would not be allowed
>> to release as part of Solr, I have seen discussions in various ASF lists
>> stating that it can be argued that the only binaries we do “release” are
>> the layers built by out Dockerfile, i.e. what comes after the (runtime)
>> FROM line. So we should be careful with what extra software we add in
>> dockerfile. I did a check earlier and think we are in good shape.
>>
>> We currently re-build a bunch of older solr docked images every time we
>> release a new, but I don’t think there is any automatic refresh of images
>> outside a release. Great idea to kick off refresh of images from Jenkins.
>>
>> We can also publish nightly “master” images but since they are not
>> officially voted releases they must be clearly labelled as unofficial and
>> not advertised on the web page, only for dev purposes.
>>
>> Jan Høydahl
>>
>> 16. jan. 2021 kl. 00:36 skrev Timothy Potter :
>>
>> 
>> I'm curious about how tags will work when updating the base image for a
>> released image? The image for a tag should be immutable (IMHO), and I think
>> people would be surprised if 8.8.0 suddenly changed even if it was for a
>> good reason such as fixing a CVE in the base image. But based on what Kevin
>> said, perhaps there's already precedence for this with the official images?
>>
>> On Fri, Jan 15, 2021 at 1:51 PM Houston Putman 
>> wrote:
>>
>>> Thanks for bringing up this issue Kevin.
>>>
>>> Periodically re-building docker images is certainly a feature we could
>>> support, and probably should to automatically keep up with security fixes.
>>> We could even automate it pretty easily in Jenkins.
>>>
>>> We could also build in support in the gradle commands to instead of
>>> building a TGZ from source, download and verify the "official" TGZ, to
>>> build the image with. That way release images are always built with the
>>> same exact binaries. The Dockerfile wouldn't need to change at all between
>>> local and release, it still merely expects a TGZ to be passed in the
>>> context; gradle can determine if it needs to be built from scratch or
>>> downloaded.
>>>
>>> This still likely wouldn't be good enough to make the image an "official
>>> docker image" but it gets us to essentially the same end-state image. The
>>> only difference is the downloading and verification are happening in gradle
>>> instead of the Dockerfile.
>>>
>>> - Houston
>>

Re: Solr Docker discussion

[Houston Putman]

Thanks for bringing up this issue Kevin.

Periodically re-building docker images is certainly a feature we could
support, and probably should to automatically keep up with security fixes.
We could even automate it pretty easily in Jenkins.

We could also build in support in the gradle commands to instead of
building a TGZ from source, download and verify the "official" TGZ, to
build the image with. That way release images are always built with the
same exact binaries. The Dockerfile wouldn't need to change at all between
local and release, it still merely expects a TGZ to be passed in the
context; gradle can determine if it needs to be built from scratch or
downloaded.

This still likely wouldn't be good enough to make the image an "official
docker image" but it gets us to essentially the same end-state image. The
only difference is the downloading and verification are happening in gradle
instead of the Dockerfile.

- Houston

On Fri, Jan 15, 2021 at 2:05 PM Kevin Risden  wrote:

> Currently the solr-docker-image, and a majority of "Docker Official
>> Images", the officially released Solr binaries are downloaded from mirrors
>> and validated within the Dockerfiles. This makes it easy to ensure to users
>> that the 9.0 solr docker image contains the 9.0 solr release. This process
>> doesn't fit very well with local builds, because there is nowhere to
>> download local builds from, and validation isn't required.
>>
>> *The current opinion in the community is to abandon the "Docker Official
>> Images" style process of downloading and validating official binaries, and
>> instead having the release manager use the local-build image creation with
>> the final release source.* This should result in the same docker image
>> in the end, however there is no trust built into the docker image itself.
>> Instead we are likely going to document a way for users to verify the
>> docker-image contents themselves.
>>
>
> Before we abandon the official process of downloading/validating official
> binaries, I think there is a good reason to keep the ability to download an
> "official" Apache Solr release and use it in the "official" Solr
> convenience Docker image.
>
> Docker images are static point in time copies of an OS and all supporting
> packages (like Java) when built. Periodically Docker images should be
> rebuilt to pick up the latest security and bug enhancements in the base
> image. Just like any OS should run `apt upgrade` or `yum update`
> periodically to ensure it is up to date.
>
> My proposal is to periodically rebuild the "official" Solr convenience
> Docker image based on the "official" Solr release to ensure we keep the
> Docker images up to date. The idea being that we have a list of "supported"
> versions of Solr (ie: 8.5, 8.6, 8.7) and periodically (ie: daily, weekly)
> the Docker images are rebuilt. Once a new release is made (ie: 8.8) it gets
> added to this rebuilding matrix. This ensures that the "official" Solr
> convenience Docker image is reasonably up to date with regards to the base
> image security updates.
>
> My understanding (from a few years ago) is that the Docker official images
> are rebuilt when the base image is updated. This was automatic from what I
> understand. If we move away from the "Docker official image" way of doing
> things, we should still ensure that we can provide high quality secure
> Docker images to the community.
>
> We should not need a new Apache Solr release (ie: 8.7.1, 8.8) to update
> the Docker image to pick up the latest base image changes.
>
> It is important to be able to build and test locally with a Docker image
> that matches what an "official" Docker image is. This should still be a
> goal, but we should be able to rebuild the Solr docker image without
> rebuilding all of Solr.
>
> PS - I chatted a bit with Houston on Slack about this topic and hopefully
> captured all the context correctly.
>
> Kevin Risden
>
>
> On Fri, Jan 15, 2021 at 12:45 PM Houston Putman 
> wrote:
>
>> There's a few decisions that need to be ironed out around the Solr docker
>> image before 9.0 is released. This is because the community has decided
>> that Solr should start releasing it's own docker images starting with 9.0.
>>
>> Below is the current state of the ongoing discussions for the Solr Docker
>> image. Please feel free to correct me or fill in any information I may be
>> missing.
>>
>> Where does this image live?
>>
>> There are two options for this really.
>>
>>- _/solr - docker run solr:9.0 (Official Docker Image)
>> 

Solr Docker discussion

[Houston Putman]

There's a few decisions that need to be ironed out around the Solr docker
image before 9.0 is released. This is because the community has decided
that Solr should start releasing it's own docker images starting with 9.0.

Below is the current state of the ongoing discussions for the Solr Docker
image. Please feel free to correct me or fill in any information I may be
missing.

Where does this image live?

There are two options for this really.

   - _/solr - docker run solr:9.0 (Official Docker Image)
   - apache/solr - docker run apache/solr:9.0

The benefits of the first are 1) the nice usability of being able to
plainly specify "solr" and 2) the "Docker Official Images" badge on
DockerHub. The downsides are that there are very strict requirements with
creating Official Docker Images, which would complicate and require
separating the way that we build release docker images and local docker
images.

The benefits of using the apache namespace is that we can build the image
in any way that we want. We would be able to build release and local docker
images the exact same way. The downside is the loss of the "Docker Official
Images" badge.

*I think there is some consensus that choosing the "apache/solr" location
is fine, and worth the added flexibility we get in the build process.*

Legal Stuff

There are a few legal questions we need to keep in mind when creating this
process and doing a release for the first time.

   - Source release - The apache policy is: (from Michael Sokolov)

   “Every ASF release MUST contain one or more source packages, which MUST
>be sufficient for a user to build and test the release provided they have
>access to the appropriate platform and tools.”

   For the docker build this is fine as long as the solr/docker gradle
   module is included in the source release. As one can always rebuild the
   same image running gradlew docker using the source.

   -

   Jan Høydahl mentioned that the docker file layers should be limited, but
   I'm not exactly sure what this means or entails. Maybe he can expand on
   this.

Artifacts within the Image

As mentioned above in the "Image Location" section, the goal of including
the docker build process inside the Solr project is to make development
easier by providing an easy way to build the official-style docker image
with local source code. In order to achieve "official-style" images for
local builds, we want to make the build process for local images as close
as possible to the process for building official release images.

Currently the solr-docker-image, and a majority of "Docker Official
Images", the officially released Solr binaries are downloaded from mirrors
and validated within the Dockerfiles. This makes it easy to ensure to users
that the 9.0 solr docker image contains the 9.0 solr release. This process
doesn't fit very well with local builds, because there is nowhere to
download local builds from, and validation isn't required.

*The current opinion in the community is to abandon the "Docker Official
Images" style process of downloading and validating official binaries, and
instead having the release manager use the local-build image creation with
the final release source.* This should result in the same docker image in
the end, however there is no trust built into the docker image itself.
Instead we are likely going to document a way for users to verify the
docker-image contents themselves.

I am not sure what the user-side verification process would look like for
the image, but I definitely think it is something that we should look into.
Maybe Docker will allow us to use these as official images if we can script
out this verification and make it easy for them to do? Just a thought, I'm
not sure if that would actually work.

Re: Separate git repo(s) for Solr modules

[Houston Putman]

I think it is a good idea to have solr-extras and solr-sandbox. However, I
think it's fine if some projects in solr-extras need to be migrated into
their own repos at some point.

I don't necessarily agree with moving all contrib modules out of the main
repo however. I think it makes the most sense to leave the "first-party"
plugin contribs inside the repo, so that they are released at the same
cadence as Solr itself, and compatibility is guaranteed whenever changes
are made to Solr core. Anything not in the main repo or released in the
same cadence as Solr is guaranteed to become stale with time. And if we do
have "first-party" plugins, then it stands to reason that those are
supposed to be supported on day-1 of a Solr release.

Some contrib modules aren't plugins, such as the Prometheus Exporter, so
this would make sense to be moved to something like solr-extras.

- Houston

On Wed, Jan 13, 2021 at 10:30 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Hi Devs,
>
> As we discussed over the last few months, there seems a need to move
> non-core pieces away from the Solr core module. The contribs are presently
> a good place, but it makes sense to have a separate git repository hosting
> such modules. Some candidates that come to mind are the present day contrib
> modules, upcoming HDFS support module (separated away from solr-core),
> other first party packages. Along with that, there is also a need for a
> repository for hosting WIP modules/sub-projects.
>
> I propose that we apply for the creation of two new git repositories:
> 1. solr-extras (or lucene-solr-extras)
> 2. solr-sandbox (or lucene-solr-sandbox)
>
> Well tested, well supported modules/sub-projects can be released straight
> away from *solr-extras*. The first party packages can be built from this
> location and shipped with Solr (or be available for install using the
> package manager CLI).
>
> New, unproved, beta, unstable modules can be hosted on *solr-sandbox*
> (and graduate to solr-extras once stable).
>
> Please let me know if there are any questions/concerns with this approach.
>
> Thanks and regards,
> Ishan
>

Re: Failing gradle precommits

[Houston Putman]

Yeah, that should work Dawid. I'll create a PR that tests it out.

- Houston

On Fri, Jan 8, 2021 at 2:02 PM Dawid Weiss  wrote:

> Can those jobs just run a sequence of two commands -
>
> ./gradlew localSettings
> ./gradlew check -x test
>
> This would solve the problem as proper JVM settings (tuned for the
> machine/ image it's running on) would be written and used on
> subsequent run.
>
> Dawid
>
> On Fri, Jan 8, 2021 at 7:44 PM Uwe Schindler  wrote:
> >
> > The problembcomes from the fact that Gradle sets a Xmx for itself in the
> settings file. Jenkins installs a settings file before.
> >
> > As every GitHub run is a clean checkout in new working dir, the settings
> never persist.
> >
> > IMHO, we should change the command line and pass JVM options to set heap
> size as it is written to the settings file.
> >
> > Uwe
> >
> > Am January 8, 2021 6:13:01 PM UTC schrieb David Smiley <
> dsmi...@apache.org>:
> >>
> >> Perhaps the OOMs are because .github/workflows/gradle-precommit.yml
> yesterday switched from doing "gradlew check -x test" to "gradlew precomit"
> ?  CC Michael Sokolov
> >>
> >> ~ David Smiley
> >> Apache Lucene/Solr Search Developer
> >> http://www.linkedin.com/in/davidwsmiley
> >>
> >>
> >> On Fri, Jan 8, 2021 at 1:06 PM Timothy Potter 
> wrote:
> >>>
> >>> Same for my PR too ... OOMs about 14 minutes in ...
> >>>
> >>> On Fri, Jan 8, 2021 at 9:45 AM Houston Putman 
> wrote:
> >>>>
> >>>> Weirdly enough, Github PR precommit actions have started to OOM. Not
> sure if it's a github thing or something that changed on our end...
> >>>>
> >>>> On Fri, Jan 8, 2021 at 11:37 AM Joel Bernstein 
> wrote:
> >>>>>
> >>>>> It turned out to be this while I merged branches:
> >>>>>
> >>>>> warning: inexact rename detection was skipped due to too many files.
> >>>>>
> >>>>> warning: you may want to set your merge.renamelimit variable to at
> least 1639 and retry the command.
> >>>>>
> >>>>>
> >>>>> Joel Bernstein
> >>>>> http://joelsolr.blogspot.com/
> >>>>>
> >>>>>
> >>>>> On Fri, Jan 8, 2021 at 11:16 AM Joel Bernstein 
> wrote:
> >>>>>>
> >>>>>> Thanks Eric, I'll do a fresh clone, something must be out of wack
> with my local repo.
> >>>>>>
> >>>>>>
> >>>>>> Joel Bernstein
> >>>>>> http://joelsolr.blogspot.com/
> >>>>>>
> >>>>>>
> >>>>>> On Fri, Jan 8, 2021 at 10:55 AM Eric Pugh <
> ep...@opensourceconnections.com> wrote:
> >>>>>>>
> >>>>>>> It ran for me just fine.   I *think* you may not be up to date, as
> dataimporthandler/ is no longer in master!
> >>>>>>>
> >>>>>>>
> >>>>>>> On Jan 8, 2021, at 10:08 AM, Joel Bernstein 
> wrote:
> >>>>>>>
> >>>>>>> I'm getting failing gradle precommits in master:
> >>>>>>>
> >>>>>>> > Task :solr:contrib:validateSourcePatterns FAILED
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestDocBuilder.xml
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.xml
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestErrorHandling.xml
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestScriptTransformer.xml
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSqlEntityProcessor.xml
> >>>>>>> tabs instead spaces:
> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataim

Re: Failing gradle precommits

[Houston Putman]

Weirdly enough, Github PR precommit actions have started to OOM. Not sure
if it's a github thing or something that changed on our end...

On Fri, Jan 8, 2021 at 11:37 AM Joel Bernstein  wrote:

> It turned out to be this while I merged branches:
>
> warning: inexact rename detection was skipped due to too many files.
>
> warning: you may want to set your merge.renamelimit variable to at least
> 1639 and retry the command.
>
> Joel Bernstein
> http://joelsolr.blogspot.com/
>
>
> On Fri, Jan 8, 2021 at 11:16 AM Joel Bernstein  wrote:
>
>> Thanks Eric, I'll do a fresh clone, something must be out of wack with my
>> local repo.
>>
>>
>> Joel Bernstein
>> http://joelsolr.blogspot.com/
>>
>>
>> On Fri, Jan 8, 2021 at 10:55 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> It ran for me just fine.   I *think* you may not be up to date, as
>>> dataimporthandler/ is no longer in master!
>>>
>>>
>>> On Jan 8, 2021, at 10:08 AM, Joel Bernstein  wrote:
>>>
>>> I'm getting failing gradle precommits in master:
>>>
>>> *> Task :solr:contrib:validateSourcePatterns* FAILED
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestDocBuilder.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSolrEntityProcessorEndToEnd.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestErrorHandling.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestScriptTransformer.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestSqlEntityProcessor.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestDocBuilder2.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestZKPropertiesWriter.xml
>>> tabs instead spaces:
>>> /Users/joelbernstein/committer/lucene-solr/solr/contrib/dataimporthandler-extras/build/test-results/test/TEST-org.apache.solr.handler.dataimport.TestTikaEntityProcessor.xml
>>>
>>> FAILURE: Build failed with an exception.
>>>
>>> * Where:
>>> Script
>>> '/Users/joelbernstein/committer/lucene-solr/gradle/validation/validate-source-patterns.gradle'
>>> line: 324
>>>
>>> * What went wrong:
>>> Execution failed for task ':solr:contrib:validateSourcePatterns'.
>>> > Found 8 violations in source files (tabs instead spaces).
>>>
>>>
>>> Are others seeing this as well? I'm not seeing Jenkins emails about this.
>>>
>>>
>>> Joel Bernstein
>>> http://joelsolr.blogspot.com/
>>>
>>>
>>> ___
>>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>>> | http://www.opensourceconnections.com | My Free/Busy
>>> 
>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>>> 
>>> This e-mail and all contents, including attachments, is considered to be
>>> Company Confidential unless explicitly stated otherwise, regardless
>>> of whether attachments are marked as such.
>>>
>>>

Re: 2021-01 Lucene/Solr Committer meeting

[Houston Putman]

I agree with Mike, the ref-branch is a topic that will take much more than
an hour.
I don't think the idea is to limit discussion around the ref-branch, but
instead to separate it out so that other topics are given the time that
they need.

- Houston

On Thu, Jan 7, 2021 at 2:08 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> What good are these meetings if the most important issues concerning the
> community are off limits?
>
> On Thu, 7 Jan, 2021, 11:38 pm Anshum Gupta, 
> wrote:
>
>> +1 :)
>>
>> Also, just a reminder for folks to put up the topics they want to
>> discuss, preferably with the time needed on the confluence page linked
>> above.
>>
>> Nevermind, here it is again -
>> https://cwiki.apache.org/confluence/display/LUCENE/2021-01+Committer+Meeting
>>
>>
>> On Thu, Jan 7, 2021 at 9:23 AM Mike Drob  wrote:
>>
>>> I would like to explicitly propose that we do not attempt to bring up
>>> the Solr reference impl branch, since I'm reasonably sure that will take up
>>> a full hour by itself. I chatted with Mark about it this morning, and he
>>> said he's working on a wiki page and then we can take it from there (next
>>> meeting, next month?)
>>>
>>> On Tue, Jan 5, 2021 at 4:31 PM David Smiley  wrote:
>>>
 Thanks so much for organizing this Anshum!  We are much overdue.

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


 On Tue, Jan 5, 2021 at 4:17 PM Anshum Gupta 
 wrote:

> Hi committers,
>
> I'd like to organize a virtual Lucene/Solr committer meeting this
> month with an intention to discuss the plan for 9.0 release, and the
> subsequent creation of the Solr TLP. I've started a confluence page to
> organize the agenda for this -
> https://cwiki.apache.org/confluence/display/LUCENE/2021-01+Committer+Meeting
>
>
> I'll share a link to the "Doodle Poll" to figure out a time that suits
> most of us. You'll be able to find a link to the poll on #lucene-dev and
> #solr-dev channels on the ASF Slack. Please email me to ask for the link 
> if
> you are a committer who isn't on Slack and would like to participate.
>
> For this virtual committer meeting and future ones:
>
>- This is in the spirit of committer meetings co-located with
>conferences.  ASF policy says that no "decisions" can be made in such a
>venue.  We make decisions on this dev list and indirectly via JIRA out 
> in
>the open and with the opportunity for anyone to comment.
>- Who:  Committer-only
>- Video chat with option of audio dial-in.  This time I will use
>Google Hangout but open to using something else.
>- I wouldn't be recording this, but would provide detailed meeting
>notes that I can share with everyone who signs up.
>- Published notes:  I (or someone) will take written meeting notes
>that are ultimately published for anyone to see (not restricted to 
> those
>invited). They will be transmitted to the dev list.
>
>
> --
> Anshum Gupta
>

>>
>> --
>> Anshum Gupta
>>
>

Re: Guohua Wu's subscription to lucene dev list

[Houston Putman]

Hello,

You can find instructions here on how to subscribe to the lucene mailing
lists. (You send an email to dev-subscribe)

https://lucene.apache.org/core/discussion.html#developer-lists

- Houston

On Thu, Jan 7, 2021 at 10:02 AM guohuawu227  wrote:

> I am a software developer from China.My name is Guohua Wu. Rencently I am
> reading the source of lucene. I asked some questions about lucene to Mike
> McCandless and he told me to send this email to subscribe to Lucene's dev
> list and ask question again so his answer will be shared. Hope I can
> succeed.

Re: 8.8 Release

[Houston Putman]

Thanks for volunteering Ishan.

I think it might be a good idea to wait to cut and release 8.8 at least a
week into January. Many people are going to be away during the holiday
season, and particularly the last week of the year. Pushing into January
just gives more people a chance to look at the release and be involved.

- Houston

On Fri, Dec 11, 2020 at 3:26 PM Noble Paul  wrote:

> Thanks Ishan for volunteering
>
> On Fri, Dec 11, 2020 at 5:07 AM Christine Poerschke (BLOOMBERG/
> LONDON)  wrote:
> >
> > With a view towards including it in the release, I'd appreciate code
> review input on
> >
> > https://github.com/apache/lucene-solr/pull/1992 for
> >
> > https://issues.apache.org/jira/browse/SOLR-14939 (JSON facets: range
> faceting to support cache=false parameter)
> >
> > if anyone has some time next week perhaps?
> >
> > Thanks in advance!
> >
> > Christine
> >
> > From: dev@lucene.apache.org At: 12/10/20 18:01:58
> > To: dev@lucene.apache.org
> > Subject: Re: 8.8 Release
> >
> > +1
> >
> > Joel Bernstein
> > http://joelsolr.blogspot.com/
> >
> >
> > On Thu, Dec 10, 2020 at 11:23 AM David Smiley 
> wrote:
> >>
> >> Thanks for volunteering!
> >>
> >> On Thu, Dec 10, 2020 at 11:11 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>>
> >>> Hi Devs,
> >>> There are lots of changes accumulated and some underway. I wish to
> volunteer for a 8.8 release, if there are no objections. I'm planning to
> build the RC in three weeks, i.e. 31 December (and cut the branch about 3-4
> days before that). Please let me know if someone has any concerns.
> >>> Thanks and regards,
> >>> Ishan
> >>>
> >> --
> >> Sent from Gmail Mobile
> >
> >
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Welcome Houston Putman to the PMC

[Houston Putman]

Thanks everyone!

I'm very excited to continue growing and improving the community with y'all!

- Houston

On Thu, Dec 3, 2020 at 6:39 AM Michael Sokolov  wrote:

> Welcome, Houston!
>
> On Wed, Dec 2, 2020, 2:34 PM David Smiley  wrote:
>
>> Welcome Houston!
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Tue, Dec 1, 2020 at 4:20 PM Mike Drob  wrote:
>>
>>> I am pleased to announce that Houston Putman has accepted the PMC's
>>> invitation to join.
>>>
>>> Congratulations and welcome, Houston!
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>

Re: Solr: Separate CHANGES.txt for Docker, SolrJ, Contribs, ...

[Houston Putman]

+1

I think that having separate CHANGES.txt files for the different parts of
Solr would be great. If you are looking for certain changes you would
generally know which module to go to.

Some items that have a more sweeping impact would be listed in both


I am ambivalent on having a separate CHANGES.txt for SolrJ, as long as
major changes are included in the main CHANGES.txt. In general it's easy to
add an entry to every applicable CHANGES.txt, no matter which module the
change was made in.

- Houston

On Sat, Nov 21, 2020 at 1:34 AM David Smiley  wrote:

> What of Docker changes?  And beyond direct changes to Dockerfile +
> scripts, it could feature particular notable changes to the server that are
> particularly noteworthy... like hypothetical improvements to solr home /
> core root dir etc. configuration.
>
> Even if Contribs/Modules are not separated out of the repo *yet* (even if
> they hypothetically never leave), I think it's desirable to separate their
> CHANGES.txt in master now.
>
> RE SolrJ -- I know it's used heavily in the server side; this one is more
> debatable than the others and I don't have a strong opinion.  Some items
> that have a more sweeping impact (e.g. HTTP2) would be listed in both but
> the difference is that the SolrJ side would have a more user-facing
> purpose, mentioning SolrClient subclasses that are pertinent to draw
> attention to compatibility or new classes users should know about.  This
> kind of stuff is maybe too detailed to bother putting in
> solr-upgrade-notes.adoc but would not be to SolrJ's dedicated CHANGES.txt.
> On server CHANGES.txt, we tend to be vague.  If SolrJ is changed for
> something that has more to do with server-side (e.g. SOLR-14691 "Metrics
> Reporting Should Avoid Creating Objects" which changed some utils in
> SolrJ), then it ought not to be listed in SolrJ's proposed CHANGES.txt.
> Admittedly there may be more cumulative CHANGES.txt maintenance between the
> two.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Nov 20, 2020 at 9:17 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> I think whatever we don't ship in the main tarball today should stay
>> separate. Going forward, when we stop shoving the extra modules (contribs)
>> into the main distro, we can separate out their changelogs. However, I feel
>> SolrJ changes should stay with Solr changes since it is also used heavily
>> in the server side.
>>
>> On Sat, 21 Nov, 2020, 3:39 am David Smiley,  wrote:
>>
>>> I was about to merge a PR pertaining to Solr's new Docker module when it
>>> occurred to me that I ought to add a CHANGES.txt entry.  But, for Solr
>>> users (which includes me and everyone reading this), it's annoying to have
>>> to go to Solr's all-encompassing CHANGES.txt to find Docker upgrade
>>> notes, which is a distinct way of running Solr.  I think the same could be
>>> said for our contribs, and perhaps even SolrJ, which is another distinct
>>> consumable.  The idea of separated CHANGES.txt aligns well with contribs
>>> being further isolated (see both the discussion on separate git repos for
>>> them, and also the discussion of getting rid of "dist" (each contrib's jar
>>> goes in its own folder; keeps to itself)).
>>>
>>> Solr's root /CHANGES.txt could at the very top reference the other
>>> CHANGES.txt files.
>>>
>>> WDYT?
>>>
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>>
>>

Re: Welcome Julie Tibshirani as Lucene/Solr committer

[Houston Putman]

Congrats and welcome Julie!!

- Houston

On Wed, Nov 18, 2020 at 10:30 AM Eric Pugh 
wrote:

> I’ve seen all your contributions, really great stuff. Welcome!
>
>
> On Nov 18, 2020, at 10:22 AM, Uwe Schindler  wrote:
>
> Welcome Julie!
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> -Original Message-
> From: Michael Sokolov 
> Sent: Wednesday, November 18, 2020 4:07 PM
> To: dev@lucene.apache.org
> Subject: Welcome Julie Tibshirani as Lucene/Solr committer
>
> I'm pleased to announce that Julie Tibshirani has accepted the PMC's
> invitation to become a committer.
>
> Julie, the tradition is that new committers introduce themselves with
> a brief bio.
>
> I think we may still be sorting out the details of your Apache account
> (julie@ may have been taken?), but as soon as that has been sorted out
> and karma has been granted, you can use your new powers to add
> yourself to the committers section of the Who We Are page on the
> website: 
>
> Congratulations and welcome!
>
> Mike Sokolov
>
> -
> 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
>
>
> ___
> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
> | http://www.opensourceconnections.com | My Free/Busy
> 
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
> 
> This e-mail and all contents, including attachments, is considered to be
> Company Confidential unless explicitly stated otherwise, regardless
> of whether attachments are marked as such.
>
>

Re: [VOTE] Release Lucene/Solr 8.7.0 RC1

[Houston Putman]

+1 (non-binding)

SUCCESS! [1:02:05.573929]

On Fri, Oct 30, 2020 at 4:56 PM Tomás Fernández Löbbe 
wrote:

> +1
>
> SUCCESS! [1:03:01.296851]
>
> On Fri, Oct 30, 2020 at 12:05 PM Nhat Nguyen
>  wrote:
>
>> +1 (binding)
>> SUCCESS! [0:53:20.894728]
>>
>>
>> On Fri, Oct 30, 2020 at 1:50 PM Michael McCandless <
>> luc...@mikemccandless.com> wrote:
>>
>>> +1
>>>
>>>
>>> SUCCESS! [0:45:49.703726]
>>>
>>> Mike McCandless
>>>
>>> http://blog.mikemccandless.com
>>>
>>>
>>> On Fri, Oct 30, 2020 at 8:04 AM Ignacio Vera  wrote:
>>>
 +1 SUCCESS! [1:42:16.864208]

 On Fri, Oct 30, 2020 at 12:13 PM Adrien Grand 
 wrote:

> +1 SUCCESS! [2:11:05.149743]
>
> On Fri, Oct 30, 2020 at 5:54 AM Atri Sharma  wrote:
>
>> Please vote for release candidate 1 for Lucene/Solr 8.7.0
>>
>>
>> The artifacts can be downloaded from:
>>
>>
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
>>
>>
>> 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.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
>>
>>
>> The vote will be open for at least 72 hours i.e. until 2020-11-01
>> 20:00 UTC.
>>
>>
>> [ ] +1  approve
>>
>> [ ] +0  no opinion
>>
>> [ ] -1  disapprove (and reason why)
>>
>>
>> Here is my +1
>>
>> 
>>
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Adrien
>

Re: [DISCUSS] Solr Operator grant to Apache Lucene

[Houston Putman]

I can answer a few of those!

I assume this is a donation to Solr project, so it will be an
> apache/solr-operator project, similar to how it is currently
> lucene-solr?
>

Yes, the target would be apache/solr-operator. Similar to
apache/rocketmq-operator .

How does this interplay with Docker that IS in-project?
>

Currently the Dockerfile that is in-project (Solr 9+), is pretty much
identical to the one in docker-solr (Solr 8-).
There is no real difference between the two currently, therefore both are
supported by the Solr Operator.
If the solr/docker image begins to diverge, we will make sure that the
solr-operator supports it since that will be the official Solr docker image
starting in Solr 9.

Currently the Solr Operator does not have a minimum version of Solr that it
supports, as long as the Solr image is setup the same way as the official
image.
We can begin to start enforcing minimum supported Solr versions if there
are newer Solr features that we want to utilize within the operator. But
there are no current plans to do that .

- Houston

On Fri, Oct 23, 2020 at 9:38 AM Alexandre Rafalovitch 
wrote:

> What would this practically look like if it is adopted/accepted? Given
> the Lucene and Solr separating as an additional wrinkle.
>
> I assume this is a donation to Solr project, so it will be an
> apache/solr-operator project, similar to how it is currently
> lucene-solr? Would the committers be the same or is it kind of a new
> set? Or more like a first-party package?
>
> How does this interplay with Docker that IS in-project?
>
> I am neither plus nor minus on this, just putting the questions that I
> feel would benefit being clarified.
>
> Regards,
>Alex.
>
> On Fri, 23 Oct 2020 at 03:32, Anshum Gupta  wrote:
> >
> > Hi everyone,
> >
> > Recently, Bloomberg reached out to us to donate the Solr Operator[1]
> codebase to the Apache Lucene project.
> >
> > Built on the Kube Builder framework, Solr Operator would help in
> standardizing the way SolrCloud clusters are managed in Kubernetes. This
> will allow the community to converge and share best practices around
> managing SolrCloud in k8s world.
> >
> > The PMC has spent the last few weeks discussing the merits and concerns
> around the grant and intends to move forward with it unless there are
> concerns that the community has around it.
> >
> > Thanks to Tim, here’s a detailed document around the design of Solr
> Operator, this should answer most questions around the technicality of the
> project -
> https://docs.google.com/document/d/1uQiJcE7kW5c6iEl9zG1Ve9MTEUGY7OHnMHX8PuTqpY8/edit?usp=sharing
> >
> > I’d also like to summarize the PMC discussions to help reduce repeating
> walking down the same path.
> >
> > Q: Why is having an operator important for the project?
> > A: In todays’ world of cloud native technologies, Kubernetes is an
> essential part of most modern platforms. A Kubernetes Operator allows the
> users of Apache Solr to deploy SolrCloud clusters on k8s while allowing the
> people who understand the system, to codify our collective knowledge about
> how SolrCloud should be operated.
> >
> > Q: Do we want to maintain the Kubernetes operator as part of the Apache
> Lucene project?
> > A: Yes, the operator will become an essential part of Solr as K8s
> adoption grows. Instead of pointing users at third party documentation and
> supporting projects, it would be good to have something that is supported
> by the Solr community. Also, as a separate repository, with a release
> cadence that doesn’t restrict Lucene/Solr releases, the Kubernetes Operator
> will create a lot of value for users.
> >
> > Q: Have we reviewed the design of the operator before accepting the
> grant?
> > A: The project has a lot of commits from Houston, who’s an existing
> committer. Also, Tim (Timothy Potter) has gone through the code and has
> PRs. His document above also provides a lot of insight into the operator
> for the rest of us. Overall, the code seems good and the code is in
> reasonable shape to be accepted and improved.
> >
> > Q: Should we allow the Operator to be incubated as its own project
> instead? If not, why?
> > A: This was considered, but after discussing the pros and cons around
> having the operator come in via the incubator, it was decided otherwise.
> >
> > Q: This is written in a different language i.e. Go. How do we handle
> that? Can we not find something in Java instead ?
> > A: Go is the de-facto language for Kubernetes. We would not get the same
> amount of tooling and  support for Kubernetes in Java as Go. As this is the
> right language to move forward with the operator, all of us running
> SolrCloud in K8s will be learning and working with it anyways. We will also
> certainly get questions around it from users, and it makes sense for us to
> lead that instead of catch up. This way we will also attract more
> contributors who know Go and Kubernetes in the future.  Most importantly

Re: 8.7 Release

[Houston Putman]

d Smiley 
>> wrote:
>> >> >>>>>>>
>> >> >>>>>>> BTW on branch_8x, I see that "ant precommit" fails:
>> >> >>>>>>>
>> >> >>>>>>> -documentation-lint:
>> >> >>>>>>>[jtidy] Checking for broken html (such as invalid tags)...
>> >> >>>>>>>   [delete] Deleting directory
>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>> >> >>>>>>> [echo] Checking for broken links...
>> >> >>>>>>> [exec]
>> >> >>>>>>> [exec] Crawl/parse...
>> >> >>>>>>> [exec]
>> >> >>>>>>> [exec] Verify...
>> >> >>>>>>> [echo] Checking for malformed docs...
>> >> >>>>>>> [exec]
>> >> >>>>>>> [exec]
>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>> >> >>>>>>> [exec]   missing description:
>> org.apache.solr.util.circuitbreaker
>> >> >>>>>>> [exec]
>> >> >>>>>>> [exec] Missing javadocs were found!
>> >> >>>>>>>
>> >> >>>>>>> That package is missing a "package-info.java".  It's been this
>> way for a while... I wonder why it hasn't been noticed by others yet?
>> >> >>>>>>>
>> >> >>>>>>> ~ David Smiley
>> >> >>>>>>> Apache Lucene/Solr Search Developer
>> >> >>>>>>> http://www.linkedin.com/in/davidwsmiley
>> >> >>>>>>>
>> >> >>>>>>>
>> >> >>>>>>> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma 
>> wrote:
>> >> >>>>>>>>
>> >> >>>>>>>> I will start the first build candidate on upcoming Monday.
>> This is my
>> >> >>>>>>>> first release so fingers crossed :)
>> >> >>>>>>>>
>> >> >>>>>>>> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand <
>> jpou...@gmail.com> wrote:
>> >> >>>>>>>>>
>> >> >>>>>>>>> Thanks Atri. Do you know when you will start the first build
>> candidate as well? We had been doing some planning around Ishan's initial
>> suggestion of cutting the branch on September 20th, so as this is getting
>> delayed I'm trying to get a sense of whether the release would likely be
>> out in the next two weeks.
>> >> >>>>>>>>>
>> >> >>>>>>>>> On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma <
>> a...@apache.org> wrote:
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Adrien,
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Sorry for the delay in response.
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> I will cut the branch this Friday morning (IST).
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> Atri
>> >> >>>>>>>>>>
>> >> >>>>>>>>>> On Tue, 13 Oct 2020 at 05:43, Houston Putman <
>> houstonput...@gmail.com> wrote:
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> Adrien, I plan on merging SOLR-14907 to master and 8x
>> tomorrow. If you would mind waiting to cut 8.7 until then, I would
>> appreciate it.
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> - Houston
>> >> >>>>>>>>>>>
>> >> >>>>>>>>>>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand <
>> jpou...@gmail.com> wrote:
>> >> >>>>>>>>>

Re: JIRAs with user facing changes

[Houston Putman]

I think this is a really good idea. Formalizing the process would certainly
help with consistency throughout Solr. Thanks for bringing it up Noble!

Andrzej, we could possibly use a label for this in JIRA, or add a
"component" for it. Adding it as a part of the checklist is a good idea,
especially for new contributors.

- Houston

On Sun, Oct 18, 2020 at 10:25 AM David Smiley  wrote:

> +1, Good idea!  It's extra work but the peer-review is important and
> prevents confusion for years to come when a poor choice is made.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Oct 18, 2020 at 1:39 AM Noble Paul  wrote:
>
>> I don't think we have such an option in JIRA. However, we can add a
>> similar item to the checklist in github
>>
>> On Sat, Oct 17, 2020 at 6:43 PM Andrzej Białecki  wrote:
>> >
>> > +1, we should strive to be consistent in the user-facing APIs / configs
>> / UX.
>> >
>> > I’m wondering if there’s any support in Jira for conditional fields, so
>> that when you create a Jira issue if you tick off an option “Affects the
>> UX?” it opens a mandatory text field to describe the changes.
>> >
>> >
>> > > On 16 Oct 2020, at 20:19, Noble Paul  wrote:
>> > >
>> > > Hi,
>> > > I'm proposing a process for every ticket which has a user facing
>> > > change. The changes could be
>> > >
>> > > * A new command/end point
>> > > * A new request parameter
>> > > * A configuration (solr.xml, clusterprops.json, or any other file in
>> ZK)
>> > > * A new file (part of file) in ZK
>> > > * A new file in file system
>> > >
>> > > I may have missed some.
>> > >
>> > > Please ensure that the changes are described in the description of the
>> > > JIRA. This gives a heads up to other committers that a new user facing
>> > > change is being introduced.
>> > >
>> > > Solr's UX is inconsistent & hard and the reason is that we all make
>> > > user-facing changes without enough review. Of course we add ref guide
>> > > documentation. But, it is not done until it is too late. The intent to
>> > > make a change should be made clear well in advance so that we get
>> > > early feedback. Other committers often see the changes pretty late and
>> > > at this point it is too late to change because of backward
>> > > incompatibility.
>> > >
>> > >
>> > > --
>> > > -
>> > > Noble Paul
>> > >
>> > > -
>> > > 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
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: 8.7 Release

[Houston Putman]

Adrien, I plan on merging SOLR-14907
 to master and 8x
tomorrow. If you would mind waiting to cut 8.7 until then, I would
appreciate it.

- Houston

On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:

> Shall we move forward with 8.7 now that 8.6.3 is out?
>
> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>
>> I plan to cut the branch on 30th September.
>>
>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett 
>> wrote:
>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Atri,
>>>
>>>
>>>
>>>
>>>
>>> Just so I understand your plans, when you say you are planning to start
>>> the process at the end of this month, you mean you intend to create the
>>> branch around Oct 1? No pressure, I ask only because Ishan’s original mail
>>> mentioned cutting the branch this week and I just wanted to have a clearer
>>> sense of your timeline.
>>>
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Cassandra
>>>
>>>
>>>
>>>
>>> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>>>
>>>
>>>
>>>
>>> I was planning to start the process end of this month.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>>>
>>>
>>>

 Unless it somehow got lost in a spam filter somewhere, I don't think we
 have set a target date for the release yet? (roadmap says autumn 2020 which
 technically doesn't begin until the solstice on the 21st :) )




 Hoping that I might still get the Advanced Query parser in first, but
 that's a much bigger prospect than these two tickets.









 -Gus









 On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
 wrote:



>
> Unless there are objections, I'm gonna get
> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>
>
>
>
> Erik
>
>
>
>
>
>
>
>
>
>
> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
> cpoersc...@bloomberg.net> wrote:
>
>
>
>
>
>
>
>
>
> With a view towards including it in the release, I'd appreciate input
> on the
>
>
>
>
> https://issues.apache.org/jira/browse/SOLR-14828
>
>
>
>
>
> solrj logging tweak if anyone has a moment?
>
>
>
>
> Thanks,
>
>
> Christine
>
>
>
>
>
>
>
>
>
>
>
> From: dev@lucene.apache.org At: 08/20/20 22:48:39
>
>
> To: dev@lucene.apache.org
>
>
> Subject: Re: 8.7 Release
>
>
>
>
>
>
>
>
>
>
>
> Also, we should try to respect the stuff we have put on the roadmap
> (Which includes me getting a patch up for SIP-9 much sooner rather than
> even a little later!)
>
>
>
>
>
>
>
> On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand 
> wrote:
>
>
>
>>
>> Thanks for the explanation Ishan.
>>
>>
>>
>>
>>
>>
>>
>> On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>
>>
>>>
>>>
>>>
>>> Hi Adrien,
>>>
>>>
>>> I think I am mainly concerned about getting the configuration and
>>> modularity of this right before we release:
>>> https://issues.apache.org/jira/browse/SOLR-14588.
>>>
>>>
>>> If we aren't able to resolve it, we should revert that feature.
>>>
>>>
>>>
>>>
>>>
>>> There may be some other performance issues that may have been marked
>>> as blockers just to infuse a sense of urgency among those that need to 
>>> fix
>>> it. But, I wouldn't consider them something that actually holds up a
>>> release.
>>>
>>>
>>> Regards,
>>>
>>>
>>> Ishan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Aug 21, 2020 at 1:56 AM Adrien Grand 
>>> wrote:
>>>
>>>
>>>

 Noble, I'm curious what blockers you have in mind. I just checked
 JIRA, and while I see a number of 9.0 blockers, I'm not counting many 
 8.7
 blockers?







 On Thu, Aug 20, 2020 at 11:13 AM Noble Paul 
 wrote:


 There are a lot of blockers for 8.7. It's good to plan in advance
>
>
>
>
>
> On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattopadhyaya
>
>
>  wrote:
>
>
> >
>
>
> > Hi devs,
>
>
> > A lot of changes are now in 8.7 or in-flight. I'd like to
> volunteer for a 8.7 release in around a month from now (cutting the 
> release
> branch around 20 September) an

Re: 8.6.3 Release

[Houston Putman]

That is correct. 8.x docker builds have not been affected in any way.

On Tue, Oct 6, 2020 at 11:30 AM Cassandra Targett 
wrote:

> I wanted to ask now that the 8.6.3 vote is underway - for the docker-solr
> image, are the update instructions in the docker-solr repo still the same
> for 8.x even though the build process has been moved to the main project
> for 9.0? Meaning, to release the 8.6.3 image there’s no change from before,
> right?
>
> I’m asking specifically about these instructions:
>
> https://github.com/docker-solr/docker-solr/blob/master/update.md
> On Oct 1, 2020, 9:28 AM -0500, Jason Gerlowski ,
> wrote:
>
> I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> someone please sanity check the summaries there when they get a
> chance? Would appreciate the review.
>
> 8.6.3 is a bit interesting in that Lucene has no changes in this
> bugfix release. As a result I had to omit the standard phrase in the
> Solr release notes about there being additional changes at the Lucene
> level, and change some of the wording in the Lucene announcement to
> indicate the lack of changes. So that's something to pay particular
> attention to, if someone can check my wording there.
>
> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> [2]
> https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>
> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski 
> wrote:
>
>
> The only one that was previously mentioned as a blocker was
> SOLR-14835, but from the comments on the ticket it looks like it ended
> up being purely a cosmetic issue. Andrzej left a comment there
> suggesting that we "address" this with documentation for 8.6.3 but
> otherwise leave it as-is.
>
> So it looks like we're unblocked on starting the release process.
> Will begin the preliminary steps this afternoon.
>
> On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett 
> wrote:
>
>
> It looks to me like everything for 8.6.3 is resolved now (
> https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a
> Jetty upgrade less compelling to try.
>
> Are there any other issues not currently marked for 8.6.3 we’re waiting
> for before starting the RC?
> On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski ,
> wrote:
>
> That said, if someone can use 8.6.3, what’s stopping them from going to
> 8.7 when it’e released?
>
>
> The same things that always stop users from going directly to the
> latest-and-greatest: fear of instability from new minor-release
> features, reliance on behavior changed across minor versions, breaking
> changes on Lucene elements that don't guarantee backcompat (e.g.
> SOLR-14254), security issues in later versions (new libraries pulled
> in with vulns), etc. There's lots of reasons a given user might want
> to stick on 8.6.x rather than 8.7 (in the short/medium term).
>
> I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> the worst of the Jetty issue should be mitigated by work on our end -
> but I think there's a lot of reasons users might not upgrade as far as
> we'd expect/like.
>
>
> On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson 
> wrote:
>
>
> For me, there’s a sharp distinction between changing a dependency in a
> point release just because there’s a new version, and changing the
> dependency because there’s a bug in it. That said, if someone can use
> 8.6.3, what’s stopping them from going to 8.7 when it’e released? Would it
> make more sense to do the upgrades for 8.7 and get that out the door rather
> than backport?
>
> FWIW,
> Erick
>
> On Sep 28, 2020, at 1:45 PM, Jason Gerlowski 
> wrote:
>
> Hey all,
>
> I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> SOLR-14898. These tickets (while bad bugs in their own right) are
> especially necessary because they work around a Jetty buffer-reuse bug
> (see SOLR-14896) that causes sporadic request failures once triggered.
>
> So that brings the list of 8.6.3 blockers up to: SOLR-14850,
> SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
> work on SOLR-14768!)
>
> Additionally, should we also consider a Jetty upgrade for 8.6.3 in
> light of the issue mentioned above? I know it's atypical for bug-fix
> releases to change deps, but here the bug is serious and tied directly
> to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
> Jetty bug is likely still a problem for users making requests that
> match a specific (albeit rare) profile. Anyone have thoughts?
>
> Best,
>
> Jason
>
> On Fri, Sep 25, 20

Re: [VOTE] Release Lucene/Solr 8.6.3 RC1

[Houston Putman]

+1 (non-binding)

SUCCESS! [0:59:46.680873]

On Mon, Oct 5, 2020 at 11:04 AM Adrien Grand  wrote:

> +1 SUCCESS! [1:36:10.395992]
>
> On Mon, Oct 5, 2020 at 2:15 PM Michael McCandless <
> luc...@mikemccandless.com> wrote:
>
>> +1 (binding)
>>
>> SUCCESS! [0:44:16.898412]
>>
>>
>> Mike McCandless
>>
>> http://blog.mikemccandless.com
>>
>>
>> On Mon, Oct 5, 2020 at 3:28 AM Atri Sharma  wrote:
>>
>>> +1 (binding)
>>>
>>> SUCCESS! [1:04.32.39193]
>>>
>>> On Sun, Oct 4, 2020 at 7:24 AM Jason Gerlowski 
>>> wrote:
>>> >
>>> > Please vote for release candidate 1 for Lucene/Solr 8.6.3
>>> >
>>> >
>>> > The artifacts can be downloaded from:
>>> >
>>> >
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>>> >
>>> >
>>> > 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.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>>> >
>>> >
>>> > The vote will be open for at least 72 hours i.e. until 2020-10-07
>>> 02:00 UTC.
>>> >
>>> >
>>> > [ ] +1  approve
>>> >
>>> > [ ] +0  no opinion
>>> >
>>> > [ ] -1  disapprove (and reason why)
>>> >
>>> >
>>> > Here is my +1
>>>
>>> --
>>> Regards,
>>>
>>> Atri
>>> Apache Concerted
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>>
>
> --
> Adrien
>

Re: restlet dependencies

[Houston Putman]

+1 to Tomas' proposal. Created SOLR-14907
 to track the effort.

 - Houston

On Wed, Sep 30, 2020 at 12:26 PM Tomás Fernández Löbbe <
tomasflo...@gmail.com> wrote:

> > Let's support the single file upload feature
> +1, but let this behave exactly as a zip file with a single file in it
> (regarding trusted/untrusted). We just need to change the configset handler
> to be able to handle non-zip files, and have a way to "locate" that file
> inside the configset (in case it needs to go somewhere other than the root).
>
> On Wed, Sep 30, 2020 at 8:45 AM Eric Pugh 
> wrote:
>
>> I think that me in “violent agreement” with you.   Let’s understand the
>> Annotations approach that we have, or pick something that is commonly used
>> like JAX-RS / Jersey.
>>
>>
>>
>> On Sep 30, 2020, at 11:41 AM, Timothy Potter 
>> wrote:
>>
>> I'm sorry, I don't understand what you mean by "make it a single pattern
>> (the annotations?)" Eric?
>>
>> To me, the pattern is well established in the Java world: JAX-RS (with
>> Jersey as the underlying impl. which has nice integration with Jetty). But
>> when I suggested porting the code that uses restlet to JAX-RS / Jersey,
>> Ishan said that wasn't necessary and is already supported with some
>> Annotations ... I have no idea what that means and need more info about
>> what is already in place. Short of that, replacing restlet with JAX-RS /
>> Jersey looks like a trivial amount of work to me (and I'm happy to take it
>> on).
>>
>> Tim
>>
>> On Wed, Sep 30, 2020 at 9:36 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> The use case of “I want to update something via a API” is I think pretty
>>> common, and it would be nice to make it a single pattern (the annotations?)
>>> with lots of examples/developer docs for the next person.
>>>
>>>
>>>
>>> On Sep 30, 2020, at 11:04 AM, Timothy Potter 
>>> wrote:
>>>
>>> I started looking into removing Managed Resources in master and wanted
>>> to mention that the LTR contrib also relies on this framework
>>> (ManagedModelStore and ManagedFeatureStore, see:
>>> https://lucene.apache.org/solr/guide/8_6/learning-to-rank.html#uploading-a-model).
>>> I only mention this b/c it's been said several times in this thread that
>>> nobody uses this feature and it's only for editing config/schema like
>>> synonyms. Afaik, LTR is a broadly used feature of Solr so now I'm not so
>>> bullish on removing the ability to manage dynamic resources using a REST
>>> like API. I agree that changing resources like the synonym set could be
>>> replaced with configSet updates but I don't see how to replace the RESTful
>>> model / feature store API w/o something like Managed Resources?
>>>
>>> From where I sit, I think we should just remove the use of restlet in
>>> the implementation but keep the API for Solr 9 (master).
>>>
>>> @Ishan ~ you mentioned there is a way to get REST API like behavior w/o
>>> using JAX-RS / Jersey ... something about annotations? Can you point me to
>>> some example code of how that is done please?
>>>
>>> Cheers,
>>> Tim
>>>
>>> On Wed, Sep 30, 2020 at 8:29 AM David Smiley  wrote:
>>>
 These resources are fundamentally a part of the configSet and can (in
 general) affect query results and thus flushing caches (via a reload) is
 appropriate.

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


 On Wed, Sep 30, 2020 at 9:06 AM Noble Paul 
 wrote:

> Well, I believe we should have a mechanism to upload a single file to
> a configset.
>
> >  A single file configset upload would require the user to reload the
> collection, so it isn't better than managed resources.
>
> This is not true
>
> Only config/schema file changes result in core reload.
>
> On Wed, Sep 30, 2020 at 10:23 PM David Smiley 
> wrote:
> >
> > Definitely don't remove in 8.x!
> >
> > >  A single file configset upload would require the user to reload
> the collection, so it isn't better than managed resources.
> >
> > Do you view that as a substantial point in favor of
> managed-resources?  I view that as a trivial matter, and one I prefer to
> automagic and potentially premature reload if there are additional edits 
> to
> be done (e.g. query-elevation or other word lists).
> >
> > ~ David Smiley
> > Apache Lucene/Solr Search Developer
> > http://www.linkedin.com/in/davidwsmiley
> >
> >
> > On Wed, Sep 30, 2020 at 5:46 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>
> >> > * Nobody knows how it works. It's unsupported
> >> It is supported and documented:
> https://lucene.apache.org/solr/guide/8_6/managed-resources.html
> >>
> >> > * RESTlet dependency
> >> > * Cannot be secured using standard permissions
> >> > * It's extremely complex for the functionality i

Re: 8.6.3 Release

[Houston Putman]

If I recall correctly, thats a step in the release wizard.

After checking, I think this fits the bill:
https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435

- Houston

On Fri, Sep 25, 2020 at 12:06 AM David Smiley  wrote:

> When moving changes from 8.7 to 8.6.3, must we (the mover of an individual
> change) move the CHANGES.txt entry on all branches -- master, branch_8x,
> branch_8_6?  I expect the release branch but am unsure of the other two.
> In the past I have but it's annoying.  Does the RM sync CHANGES.txt on the
> other branches in one go?  If not, I think it'd make sense for that to
> happen.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma  wrote:
>
>> I will push the 8.7 release by a week to give Jason enough headroom to
>>
>>
>> do the 8.6.3 release.
>>
>>
>>
>>
>>
>> Jason, let me know if you need me to assist on the 8.6.3 release.
>>
>>
>>
>>
>>
>> On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski 
>> wrote:
>>
>>
>> >
>>
>>
>> > OK, in that case I'll try my best to keep the 8.6.3 process moving
>>
>>
>> > then, so Atri can stick as close to his proposed schedule as possible.
>>
>>
>> > My apologies - I didn't realize I'd be putting the brakes on 8.7 by
>>
>>
>> > proposing a bug-fix release.  But the reasons make sense given what
>>
>>
>> > others mentioned above.
>>
>>
>> >
>>
>>
>> > > As branch_8_6 should be pretty stable by now I wonder if we really
>> need to wait one week?
>>
>>
>> >
>>
>>
>> > There's no special reason on my end.  I suggested a week to give
>>
>>
>> > others time to backport anything they wanted included, but I'm happy
>>
>>
>> > to start the process as soon as all the expected changes land.
>>
>>
>> >
>>
>>
>> > Best,
>>
>>
>> >
>>
>>
>> > Jason
>>
>>
>> >
>>
>>
>> > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta 
>> wrote:
>>
>>
>> > >
>>
>>
>> > > Simultaneous releases are also confusing for users, in addition to
>> the back-compat tests as our website chronologically lists our releases and
>> it gets complicated for someone reading the 'News' page.
>>
>>
>> > >
>>
>>
>> > > As 8.7 isn't a release that needs to be rushed, waiting until 8.6.3
>> is released and back-compat indexes are pushed will make things easier for
>> the RMs and community.
>>
>>
>> > >
>>
>>
>> > > On Wed, Sep 23, 2020 at 1:43 PM David Smiley 
>> wrote:
>>
>>
>> > >>
>>
>>
>> > >> Jason: Thanks for volunteering to do an 8.6.3!  I recently fixed
>> SOLR-14768, multipart HTTP POST was broken in 8.6 (a regression I
>> introduced).  If you can't do the release or need help, I will take over.
>> It's the least I can offer in repentance for the regression.
>>
>>
>> > >>
>>
>>
>> > >> ~ David Smiley
>>
>>
>> > >> Apache Lucene/Solr Search Developer
>>
>>
>> > >> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> > >>
>>
>>
>> > >>
>>
>>
>> > >> On Wed, Sep 23, 2020 at 10:07 AM Jason Gerlowski <
>> gerlowsk...@gmail.com> wrote:
>>
>>
>> > >>>
>>
>>
>> > >>> Hi all,
>>
>>
>> > >>>
>>
>>
>> > >>> I ran into a query-parsing bug recently in SOLR-14859 that caused
>>
>>
>> > >>> problems for some of my usecases.  I wanted to volunteer as RM for
>> an
>>
>>
>> > >>> 8.6.3 to get a bugfix release out for users that aren't ready for
>> some
>>
>>
>> > >>> of the bigger changes in 8.7
>>
>>
>> > >>>
>>
>>
>> > >>> I was thinking of cutting the branch in a week's time to give
>> others a
>>
>>
>> > >>> chance to backport any bug-fixes they might want included, with an
>> RC
>>
>>
>> > >>> to follow shortly.  Does anyone have any concerns with that plan, or
>>
>>
>> > >>> have anything they'd like to fix or backport before an 8.6.3 goes
>> out?
>>
>>
>> > >>>
>>
>>
>> > >>> Best,
>>
>>
>> > >>>
>>
>>
>> > >>> Jason
>>
>>
>> > >>>
>>
>>
>> > >>>
>> -
>>
>>
>> > >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>>
>> > >>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> > >>>
>>
>>
>> > >
>>
>>
>> > >
>>
>>
>> > > --
>>
>>
>> > > Anshum Gupta
>>
>>
>> >
>>
>>
>> > -
>>
>>
>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>>
>> > For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> Regards,
>>
>>
>>
>>
>>
>> Atri
>>
>>
>> Apache Concerted
>>
>>
>>
>>
>>
>> -
>>
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>>
>>
>>
>
>