Community Over Code NA 2024 Search track, CFP closing soon

[Anshum Gupta]

Hi folks,

The CFP for *“Community Over Code 2024” *(previously known as ApacheCon) is
currently open until *15th Apr 2024* for folks who’re interested in
submitting talks. Like the previous years we have the *'Search' track *for
folks who want to talk about their Search stories.

Please submit your talks here -
https://communityovercode.org/call-for-presentations/

We hope to see many of you talk about Search in Denver!

-- 
Anshum Gupta

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

[Anshum Gupta]

+1

On Fri, Feb 23, 2024 at 3:24 AM 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
>
>

-- 
Anshum Gupta

Re: Announcing githubsearch!

[Anshum Gupta]

This is great! Like always, thank you Mike!

On Mon, Feb 19, 2024 at 8:40 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Hi Team,
>
> ~1.5 years ago (August 2022) we migrated our Lucene issue tracking from
> Jira to GitHub. Thank you Tomoko for all the hard work doing such a
> complex, multi-phased, high-fidelity migration!
>
> I finally finished also migrating jirasearch to GitHub:
> githubsearch.mikemccandless.com. It was tricky because GitHub issues/PRs
> are fundamentally more complex than Jira's data model, and the GitHub REST
> API is also quite rich / heavily normalized. All of the source code for
> githubsearch lives here
> <https://github.com/mikemccand/luceneserver/tree/master/examples/githubsearch>.
> The UI remains its barebones self ;)
>
> Githubsearch
> <https://github.com/mikemccand/luceneserver/tree/master/examples/githubsearch>
> is dog food for us: it showcases Lucene (currently 9.8.0), and many of its
> fun features like infix autosuggest, block join queries (each comment is a
> sub-document on the issue/PR), DrillSideways faceting, near-real-time
> indexing/searching, synonyms (try “oome
> <https://githubsearch.mikemccandless.com/search.py?text=oome=status%3AOpen>”),
> expressions, non-relevance and blended-relevance sort, etc.  (This old
> blog post
> <https://blog.mikemccandless.com/2016/10/jiraseseach-20-dog-food-using-lucene-to.html>
>  goes
> into detail.)  Plus, it’s meta-fun to use Lucene to search its own issues,
> to help us be more productive in improving Lucene!  Nicely recursive.
>
> In addition to good ol’ searching by text, githubsearch
> <https://githubsearch.mikemccandless.com/> has some new/fun features:
>
>- Drill down to just PRs or issues
>- Filter by “review requested” for a given user: poor Adrien has 8
>(open) now
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=requested_reviewers%3Ajpountz>
>(sorry)! Or see your mentions (Robert is mentioned in 27 open
>issues/PRs
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=mentioned_users%3Armuir>).
>Or PRs that you reviewed (Uwe has reviewed 9 still-open PRs
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=reviewed_users%3Auschindler>).
>Or issues and PRs where a user has had any involvement at all (Dawid
>has interacted on 197 issues/PRs
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=reviewed_users%3Adweiss>
>).
>- Find still-open PRs that were created by a New Contributor
>
> <https://githubsearch.mikemccandless.com/search.py?chg=dds==author_association=New+contributor=0=25792=recentlyUpdated=list=cjhfx60attlt=status%3AOpen=>
>(an author who has no changes merged into our repository) or
>Contributor
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=author_association%3AContributor>
>(non-committer who has had some changes merged into our repository) or
>Member
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=author_association%3AMember>
>- Here are the uber-stale (last touched more than a month ago) open
>PRs by outside contributors
>
> <https://githubsearch.mikemccandless.com/search.py?sort=recentlyUpdated=status%3AOpen=author_association%3ANew+contributor%2CContributor%2CNone=updated_ago%3A%3E+1+month+ago=issue_or_pr%3APR>.
>We should ideally keep this at 0, but it’s 83 now!
>- “Link to this search” to get a short-er, more permanent URL (it is
>NOT a URL shortener, though!)
>- Save named searches you frequently run (they just save to local
>cookie state on that one browser)
>
> I’m sure there are exciting bugs, feedback/patches welcome!  If you see
> problems, please reply to this email or file an issue here
> <https://github.com/mikemccand/luceneserver/issues>.
>
> Note that jirasearch <https://jirasearch.mikemccandless.com/search.py>
> remains running, to search Solr, Tika and Infra issues.
>
> Happy Searching,
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>


-- 
Anshum Gupta

Re: Welcome Zhang Chao as Lucene committer

[Anshum Gupta]

Congratulations and welcome, Chao!

On Tue, Feb 20, 2024 at 9:28 AM Adrien Grand  wrote:

> I'm pleased to announce that Zhang Chao has accepted the PMC's
> invitation to become a committer.
>
> Chao, the tradition is that new committers introduce themselves with a
> brief bio.
>
> Congratulations and welcome!
>
> --
> Adrien
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.11.3 RC1

[Anshum Gupta]

+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

Re: [VOTE] Release Lucene 9.9.2 RC1

[Anshum Gupta]

+1

SUCCESS! [1:02:53.424950]

On Thu, Jan 25, 2024 at 3:57 AM Chris Hegarty
 wrote:

> Please vote for release candidate 1 for Lucene 9.9.2
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.2-RC1-rev-a2939784c4ca60bc28bf488b5479c02fc2e5e22c
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.2-RC1-rev-a2939784c4ca60bc28bf488b5479c02fc2e5e22c
>
> The vote will be open for 96 hours ( allowing some additional time for
> weekend span) i.e. until 2024-01-29 12:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> Draft release notes can be found at
> https://cwiki.apache.org/confluence/display/LUCENE/ReleaseNote9_9_2
>
> -Chris.
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: Welcome Stefan Vodita as Lucene committter

[Anshum Gupta]

Congratulations and welcome, Stefan!

On Thu, Jan 18, 2024 at 7:55 AM Michael McCandless <
luc...@mikemccandless.com> wrote:

> Hi Team,
>
> I'm pleased to announce that Stefan Vodita has accepted the Lucene PMC's
> invitation to become a committer!
>
> Stefan, the tradition is that new committers introduce themselves with a
> brief bio.
>
> Congratulations, welcome, and thank you for all your improvements to
> Lucene and our community,
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>


-- 
Anshum Gupta

[REMINDER] CFP Open for Search Track at Community Over Code EU (Formerly ApacheCon)

[Anshum Gupta]

Hello everyone,

The CFP for *Community Over Code Europe* (Formerly ApacheCon) is open until
12 Jan 2024 and wanted to remind you that we have a *Search track*. Please
submit your talks and share your stories here:
https://sessionize.com/coceu-2024/

A bit about the Search track:

Search is at the core of almost all data driven systems. Apache Lucene and
Solr have been the leaders in defining this space for over a decade. Since
their incubation, they have grown to redefine 'search' from being just full
text search to also incorporating spatial search, analytics, and a lot more.


For this track we welcome all talks that are related to search, even those
not related to Lucene and Solr. Your submission may involve talking about
information retrieval, analytics, the Lucene and Solr community, Machine
Learning in search, deployment and management of large scale search
systems, etc.

Like always, what we are really interested in is your search story - what
worked, what didn't, and what you are trying to build.

The event will take place in *Bratislava, Slovakia* from* 3-5 Jun 2024.*

Please feel free to reach out if you have any questions or ideas! Hope to
see you all there.

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.9.0 RC2

[Anshum Gupta]

+1

Success! [0:33:02.122753]

On Thu, Nov 30, 2023 at 11:39 PM Chris Hegarty
 wrote:

> Please vote for release candidate 2 for Lucene 9.9.0
>
>
> The artifacts can be downloaded from:
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.0-RC2-rev-06070c0dceba07f0d33104192d9ac98ca16fc500
>
>
> You can run the smoke tester directly with this command:
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.9.0-RC2-rev-06070c0dceba07f0d33104192d9ac98ca16fc500
>
>
> The vote will be open for at least 72 hours, and given the weekend in
> between, let’s keep it open until 2023-12-04 12:00 UTC.
>
> [ ] +1  approve
>
> [ ] +0  no opinion
>
> [ ] -1  disapprove (and reason why)
>
>
> Here is my +1
>
>
> -Chris.
>
>

-- 
Anshum Gupta

Re: Welcome Patrick Zhai to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Patrick!

On Fri, Nov 10, 2023 at 12:05 PM Michael McCandless <
luc...@mikemccandless.com> wrote:

> I'm happy to announce that Patrick Zhai has accepted an invitation to join
> the Lucene Project Management Committee (PMC)!
>
> Congratulations Patrick, thank you for all your hard work improving
> Lucene's community and source code, and welcome aboard!
>
> Mike McCandless
>
> http://blog.mikemccandless.com
>


-- 
Anshum Gupta

Re: Welcome Guo Feng to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Feng!

On Tue, Oct 24, 2023 at 10:05 AM Adrien Grand  wrote:

> I'm pleased to announce that Guo Feng has accepted an invitation to join
> the Lucene PMC!
>
> Congratulations Feng, and welcome aboard!
>
> --
> Adrien
>


-- 
Anshum Gupta

Re: Welcome Luca Cavanna to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Luca!

On Thu, Oct 19, 2023 at 10:51 PM Adrien Grand  wrote:

> I'm pleased to announce that Luca Cavanna has accepted an invitation to
> join the Lucene PMC!
>
> Congratulations Luca, and welcome aboard!
>
> --
> Adrien
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.8.0 RC1

[Anshum Gupta]

+1

Smoke tester is happy!

SUCCESS! [0:46:49.090567]

On Thu, Sep 21, 2023 at 10:49 PM Patrick Zhai  wrote:

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


-- 
Anshum Gupta

Re: Welcome Chris Hegarty to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Chris!

On Mon, Jun 19, 2023 at 11:53 AM Adrien Grand  wrote:

> I'm pleased to announce that Chris Hegarty has accepted an invitation to
> join the Lucene PMC!
>
> Congratulations Chris, and welcome aboard!
>
>
> --
> Adrien
>
-- 
Anshum Gupta

[REMINDER] CFP Open for Search Track at Community Over Code (Formerly ApacheCon)

[Anshum Gupta]

Hello everyone,

The CFP for *Community Over Code *(Formerly ApacheCon) is open until Thu, *13
July 2023 *23:59:59 GMT and wanted to remind you that we have a *Search
track.* Please submit your talks and share your stories here:
https://communityovercode.org/call-for-presentations/

A bit about the Search track:

Search is at the core of almost all data driven systems. Apache Lucene and
Solr have been the leaders in defining this space for over a decade. Since
their incubation, they have grown to redefine 'search' from being just full
text search to also incorporating spatial search, analytics, and a lot
more.

For this track we welcome *all talks that are related to search*, even
those not related to Lucene and Solr. Your submission may involve talking
about information retrieval, analytics, the Lucene and Solr community,
Machine Learning in search, deployment and management of large scale search
systems, etc.

What we are really interested in is your search story - what worked, what
didn't, and what you are trying to build.

The event will take place in *Halifax, Nova Scotia, Canada from 7 - 10
October, 2023*.

Please feel free to reach out if you have any questions or ideas! Hope to
see you all there.

-- 
Anshum Gupta

Re: Lucene PMC Chair Greg Miller

[Anshum Gupta]

Thank you Bruno and Greg!

On Mon, Mar 6, 2023 at 9:15 AM 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
>


-- 
Anshum Gupta

Re: Welcome Ben Trent as Lucene committer

[Anshum Gupta]

Congratulations and welcome, Ben!

On Fri, Jan 27, 2023 at 7:18 AM Adrien Grand  wrote:

> I'm pleased to announce that Ben Trent has accepted the PMC's
> invitation to become a committer.
>
> Ben, 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
>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.4.0 RC3

[Anshum Gupta]

+1 (binding)

Smoketester is happy!
SUCCESS! [0:54:06.589484]

On Tue, Sep 27, 2022 at 6:15 AM Michael Sokolov  wrote:

> Please vote for release candidate 3 for Lucene 9.4.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.0-RC3-rev-d2e22e18c6c92b6a6ba0bbc26d78b5e82832f956
>
> 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.0-RC3-rev-d2e22e18c6c92b6a6ba0bbc26d78b5e82832f956
>
> The vote will be open for at least 72 hours i.e. until 2022-09-30 14: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 9.4.0 RC2

[Anshum Gupta]

Thanks Ignacio for noticing and reporting that. I agree with Uwe, it makes
sense to cancel this vote and get the fix in.

Thank you for being patient, Mike :)

On Tue, Sep 27, 2022 at 1:20 AM Uwe Schindler  wrote:

> Hi,
>
> that's too bad! As not many have ran smoke tester, I think it may be a
> good idea to now stop the release.
>
> If we respin, I will backport some small build system fixes like support
> for Eclipse and Smoketester bootup (regarding MR-JAR) also to the 9.4
> branch. But that's not urgent.
>
> Uwe
> Am 27.09.2022 um 10:01 schrieb Ignacio Vera:
>
> Hi,
>
> I just noticed an important regression on polygon queries using the
> LatLonPoint field, see https://github.com/apache/lucene/issues/11824.
>
> It feels like an important regression so it might be worth a respinning.
> Sorry about that.
>
>
> On Mon, Sep 26, 2022 at 10:30 PM Anshum Gupta 
> wrote:
>
>> +1 (binding)
>>
>> Smoke tests passed and I tried out basic indexing and search.
>> SUCCESS! [0:59:09.751008]
>>
>> Thanks for your effort Mike, and everyone else.
>>
>> On Mon, Sep 26, 2022 at 8:47 AM Michael Sokolov 
>> wrote:
>>
>>> Please vote for release candidate 2 for Lucene 9.4.0
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.0-RC2-rev-0384b4fcad7856ddc574c8b994c814a568ce6d0a
>>>
>>> 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.0-RC2-rev-0384b4fcad7856ddc574c8b994c814a568ce6d0a
>>>
>>> The vote will be open for at least 72 hours i.e. until 2022-09-29 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
>>>
>>>
>>
>> --
>> Anshum Gupta
>>
> --
> Uwe Schindler
> Achterdiek 19, D-28357 Bremenhttps://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.4.0 RC2

[Anshum Gupta]

+1 (binding)

Smoke tests passed and I tried out basic indexing and search.
SUCCESS! [0:59:09.751008]

Thanks for your effort Mike, and everyone else.

On Mon, Sep 26, 2022 at 8:47 AM Michael Sokolov  wrote:

> Please vote for release candidate 2 for Lucene 9.4.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.0-RC2-rev-0384b4fcad7856ddc574c8b994c814a568ce6d0a
>
> 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.0-RC2-rev-0384b4fcad7856ddc574c8b994c814a568ce6d0a
>
> The vote will be open for at least 72 hours i.e. until 2022-09-29 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
>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.4.0 RC1

[Anshum Gupta]

+1 (binding)

The smoke tests passed.
SUCCESS! [2:49:17.242508]

On Fri, Sep 23, 2022 at 12:22 PM Patrick Zhai  wrote:

> (non-binding) +1
>
> SUCCESS! [1:11:00.934249]
>
> On Fri, Sep 23, 2022 at 9:44 AM Vigya Sharma  wrote:
>
>> The smoke tests passed for me too..
>>
>>
>> (no vote)
>>
>> SUCCESS! [1:12:31.588303]
>>
>> On Thu, Sep 22, 2022 at 2:27 AM Ignacio Vera  wrote:
>>
>>> +1
>>>
>>>
>>> SUCCESS! [0:46:00.508949]
>>>
>>> On Thu, Sep 22, 2022 at 9:53 AM Adrien Grand  wrote:
>>>
>>>> +1 SUCCESS! [0:45:35.275017]
>>>>
>>>> On Wed, Sep 21, 2022 at 9:19 PM Michael McCandless <
>>>> luc...@mikemccandless.com> wrote:
>>>>
>>>>> +1
>>>>>
>>>>>
>>>>> SUCCESS! [0:27:16.514391]
>>>>>
>>>>>
>>>>> Mike McCandless
>>>>>
>>>>> http://blog.mikemccandless.com
>>>>>
>>>>>
>>>>> On Wed, Sep 21, 2022 at 2:32 PM Dawid Weiss 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>> +1.
>>>>>> SUCCESS! [0:53:33.891603]
>>>>>>
>>>>>>
>>>>>>> Ran the smoketester with both java 11 and 17:
>>>>>>>
>>>>>>> SUCCESS! [2:41:19.024193]
>>>>>>>
>>>>>>> On Tue, Sep 20, 2022 at 10:10 PM Michael Sokolov 
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > Please vote for release candidate 1 for Lucene 9.4.0
>>>>>>> >
>>>>>>> > The artifacts can be downloaded from:
>>>>>>> >
>>>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.4.0-RC1-rev-f5d0646daa5651f2192282ac85551bca667e34f9
>>>>>>> >
>>>>>>> > 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.0-RC1-rev-f5d0646daa5651f2192282ac85551bca667e34f9
>>>>>>> >
>>>>>>> > The vote will be open for at least 72 hours i.e. until 2022-09-24
>>>>>>> 02: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
>>>>>>>
>>>>>>>
>>>>
>>>> --
>>>> Adrien
>>>>
>>>
>>
>> --
>> - Vigya
>>
>

-- 
Anshum Gupta

Re: Welcome Vigya Sharma as Lucene committer

[Anshum Gupta]

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

Re: Deleting old RCs

[Anshum Gupta]

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

[Anshum Gupta]

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: Welcome Greg Miller to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Greg!

On Mon, Jun 6, 2022 at 11:37 PM Adrien Grand  wrote:

> I'm pleased to announce that Greg Miller has accepted an invitation to
> join the Lucene PMC!
>
> Congratulations Greg, and welcome aboard!
>
> --
> Adrien
>


-- 
Anshum Gupta

Re: Welcome Chris Hegarty as Lucene committer

[Anshum Gupta]

Welcome and congratulations, Chris!

On Wed, Jun 1, 2022 at 12:05 AM 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
>


-- 
Anshum Gupta

Re: Welcome Lu Xugang as Lucene committer

[Anshum Gupta]

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

Re: [VOTE] Release Lucene 9.2.0 RC1

[Anshum Gupta]

+1 SUCCESS! [0:59:19.002348]

On Wed, May 18, 2022 at 5:59 AM Alan Woodward  wrote:

> Please vote for release candidate 1 for Lucene 9.2.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.2.0-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0
>
> 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-RC1-rev-978eef5459c7683038ddcca4ec56e4baa63715d0
>
> Given that we have a weekend coming up, the vote will be open for at least
> 5 days i.e. until 2022-05-23 13: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: Bugfix release Lucene/Solr 8.11.2

[Anshum Gupta]

Yes please! I assumed that was already the case as both lists are copied :)

On Fri, May 13, 2022 at 12:47 AM Uwe Schindler  wrote:

> Should we maybe also ask on the Lucene side if any backports to 8.11 would
> be good?
>
>
>
> Uwe
>
>
>
> -
>
> Uwe Schindler
>
> Achterdiek 19, D-28357 Bremen
>
> https://www.thetaphi.de
>
> eMail: u...@thetaphi.de
>
>
>
> *From:* Anshum Gupta 
> *Sent:* Friday, May 13, 2022 1:23 AM
> *To:* d...@solr.apache.org
> *Cc:* Solr/Lucene Dev 
> *Subject:* Re: Bugfix release Lucene/Solr 8.11.2
>
>
>
> Thanks for volunteering, Mike!
>
>
>
> I think the commits I was tracking to be in 8x are already there, but I'll
> confirm this over the weekend and let you know in case I intend to backport
> anything more.
>
>
>
> On Thu, May 12, 2022 at 4:03 PM Mike Drob  wrote:
>
> To: dev@lucene, dev@solr
>
>
>
> NOTICE:
>
>
> I am planning on preparing a bugfix release from branch branch_8_11
> (likely mid next week)
>
> Please observe the normal rules for committing to this branch:
>
> * Before committing to the branch, reply to this thread and argue
>   why the fix needs backporting and how long it will take.
>
> ** If you're backporting stuff this week still or over the weekend, then
> skip
>
> the bit about how long it will take.
> * All issues accepted for backporting should be marked with 8.11.2
>   in JIRA, and issues that should delay the release must be marked as
> Blocker
> * All patches that are intended for the branch should first be committed
>   to the unstable branch, merged into the stable branch, and then into
>   the current release branch.
> * Only Jira issues with Fix version 8.11.2 and priority "Blocker" will
> delay
>   a release candidate build.
>
>
>
> Also, please observe that since 9.0 already exists, there cannot be any
> index format breaking changes. It really should only be bug fixes that have
> already been verified on the 9x branch.
>
>
>
> Thanks,
>
> Mike
>
>
>
>
> --
>
> Anshum Gupta
>


-- 
Anshum Gupta

Re: Bugfix release Lucene/Solr 8.11.2

[Anshum Gupta]

Thanks for volunteering, Mike!

I think the commits I was tracking to be in 8x are already there, but I'll
confirm this over the weekend and let you know in case I intend to backport
anything more.

On Thu, May 12, 2022 at 4:03 PM Mike Drob  wrote:

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


-- 
Anshum Gupta

Re: Release notes draft for Apache Solr 9.0

[Anshum Gupta]

Oops, the auto-complete got me to send this to the Lucene dev list instead
of the Solr one. Thanks for taking care of that, Jan.

+1 on the KNN and other Lucene features that Solr 9.0 brings to the users.
This list was curated more along the lines of 'operational features' so I'm
going through the changelog to add everything else that isn't already there.

-Anshum

On Mon, Mar 28, 2022 at 12:53 PM Adrien Grand  wrote:

> Maybe release notes could mention a few benefits that Solr gets
> automatically from Lucene 9 like the new analyzers and better space
> efficiency of postings thanks to PFOR?
>
> I also concur with Jason, I was expecting vector search to make the
> top line of the release notes?
>
> On Mon, Mar 28, 2022 at 10:57 AM Jan Høydahl 
> wrote:
> >
> > Thanks Anshum,
> >
> > I'm moving this mail thread from the Lucene dev-list to the Solr
> dev-list :)
> >
> > I think, as this is a major release, we should say explicitly in the
> release-notes something like:
> > "This is a major-version release with several features removed and other
> major, breaking changes. Please consult the Release Guide chapter "Solr
> Upgrade Notes" (link) when planning an upgrade".
> >
> > I'll add some other comments inline in Confluence..
> >
> > Jan
> >
> > 28. mar. 2022 kl. 04:15 skrev Anshum Gupta :
> >
> > Hi everyone,
> >
> > Please find the initial draft of the release notes for Solr 9.0 here:
> https://cwiki.apache.org/confluence/x/jL-kCw
> >
> > Please let me know if you need me to update/add something, or feel free
> to do so yourself.
> >
> > --
> > Anshum Gupta
> >
> >
>
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
>
>

-- 
Anshum Gupta

Release notes draft for Apache Solr 9.0

[Anshum Gupta]

Hi everyone,

Please find the initial draft of the release notes for Solr 9.0 here:
https://cwiki.apache.org/confluence/x/jL-kCw

Please let me know if you need me to update/add something, or feel free to
do so yourself.

-- 
Anshum Gupta

Re: Lucene PMC Chair Bruno Roustant

[Anshum Gupta]

Congratulations Bruno, and thank you Mike for all of your effort!

On Wed, Mar 23, 2022 at 6:02 AM Michael Sokolov  wrote:

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

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.1.0 RC2

[Anshum Gupta]

Hey Adrien,

I was just speaking to Julie about it on Slack.

I don't have the failure from the first run, but the subsequent runs seem
to have just stalled. At some point the system went to sleep, and caused
random failures that were unrelated to the actual run.
I'll re-run the tests a few more times and report back if I can reproduce
the test failures from the first run.

-Anshum

On Thu, Mar 17, 2022 at 12:28 PM Adrien Grand  wrote:

> Hi Anshum,
>
> Do you remember what the issues were on the first 4 attempts?
>
> Le jeu. 17 mars 2022, 19:50, Anshum Gupta  a
> écrit :
>
>> Hi Julie,
>>
>> Thanks for volunteering as the RM.
>>
>> After 4 attempts, I finally got the smoke-tester (jdk11) to pass on the
>> 5th attempt.
>>
>> Tested out using some other basic indexing/search sample app code that I
>> was playing around with.
>>
>> Here's my +1 to release Lucene 9.1.0 RC2.
>>
>> SUCCESS! [1:05:31.299375]
>>
>> On Wed, Mar 16, 2022 at 1:27 PM Julie Tibshirani 
>> wrote:
>>
>>> Please vote for release candidate 2 for Lucene 9.1.0
>>>
>>> The artifacts can be downloaded from:
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC2-rev-5b522487ba8e0f1002b50a136817ca037aec9686
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC2-rev-5b522487ba8e0f1002b50a136817ca037aec9686
>>>
>>> The vote will be open for at least 72 hours i.e. until 2022-03-19 21:00
>>> UTC.
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> Here is my +1.
>>>
>>> Julie
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.1.0 RC2

[Anshum Gupta]

Hi Julie,

Thanks for volunteering as the RM.

After 4 attempts, I finally got the smoke-tester (jdk11) to pass on the 5th
attempt.

Tested out using some other basic indexing/search sample app code that I
was playing around with.

Here's my +1 to release Lucene 9.1.0 RC2.

SUCCESS! [1:05:31.299375]

On Wed, Mar 16, 2022 at 1:27 PM Julie Tibshirani 
wrote:

> Please vote for release candidate 2 for Lucene 9.1.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC2-rev-5b522487ba8e0f1002b50a136817ca037aec9686
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.1.0-RC2-rev-5b522487ba8e0f1002b50a136817ca037aec9686
>
> The vote will be open for at least 72 hours i.e. until 2022-03-19 21:00
> UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1.
>
> Julie
>


-- 
Anshum Gupta

Re: Welcome Guo Feng as Lucene committer

[Anshum Gupta]

Congratulations and welcome, Feng!

On Tue, Jan 25, 2022 at 1:09 AM 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
>
>

-- 
Anshum Gupta

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

[Anshum Gupta]

I think mirroring the tags is a good idea and can only be useful.

On Tue, Jan 4, 2022 at 8:56 AM Houston Putman  wrote:

> Hello all,
>
> As mentioned in SOLR-15874
> <https://issues.apache.org/jira/browse/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
>


-- 
Anshum Gupta

Re: Welcome Haoyu (Patrick) Zhai as Lucene Committer

[Anshum Gupta]

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

[Anshum Gupta]

Fast-track please :)

On Wed, Dec 15, 2021 at 4:19 PM Jan Høydahl  wrote:

> Given the votes so far (11 binding +1) I'm also positive to publish
> tomorrow, and not wait for Friday.
> The release voting rules are three or more +1 votes and more +1 votes than
> -1 votes, so for the vote to fail we'd need more than 11 -1's from now :)
>
> If I see at least 3 more of you in favor (reply with "FAST-TRACK PLEASE")
> and no justified vetoes, then I can make it happen on Thursday afternoon
> UTC!
>
> Jan
>
> 15. des. 2021 kl. 22:57 skrev Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com>:
>
> I think we should publish, release and announce asap, not waiting for 72h
> or the MVN propogation.
>
> On Thu, 16 Dec, 2021, 2:40 am Anshum Gupta, 
> wrote:
>
>> +1 (binding)
>>
>> Smoke tester is happy.
>>
>> SUCCESS! [1:03:13.162577]
>>
>> Also tested out a sample search/indexing app.
>>
>> On Tue, Dec 14, 2021 at 6:36 AM Jan Høydahl 
>> 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
>>>
>>>
>>
>> --
>> Anshum Gupta
>>
>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Anshum Gupta]

+1 (binding)

Smoke tester is happy.

SUCCESS! [1:03:13.162577]

Also tested out a sample search/indexing app.

On Tue, Dec 14, 2021 at 6:36 AM Jan Høydahl  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
>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene 9.0.0 RC4

[Anshum Gupta]

+1

Smoke tester is happy. Tried sample indexing/searching, looks good!

SUCCESS! [0:20:22.007002]

Thanks for your effort and patience, Adrien!

On Wed, Dec 1, 2021 at 8:56 AM Adrien Grand  wrote:

> Please vote for release candidate 4 for Lucene 9.0.0
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC4-rev-0b18b3b965cedaf5eb129aa41243a44c83ca826d
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC4-rev-0b18b3b965cedaf5eb129aa41243a44c83ca826d
>
> The vote will be open until 2021-12-06 08:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: Welcome Julie Tibshirani to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Julie!

On Tue, Nov 30, 2021 at 1:49 PM 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
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

[Anshum Gupta]

+1 (binding)

SUCCESS! [1:05:18.562320]

Also tested a sample app for basic Lucene and Solr indexing and search.

Thanks for your effort, Adrien!

On Tue, Nov 9, 2021 at 12:50 PM Adrien Grand  wrote:

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


-- 
Anshum Gupta

Re: Lucene 9.0 release

[Anshum Gupta]

This looks like a great plan. Thanks for taking this forward :)

On Fri, Oct 15, 2021 at 12:30 AM Adrien Grand  wrote:

> For visibility, I recently opened a new issue about a case of index
> corruption <https://issues.apache.org/jira/browse/LUCENE-10159> which is
> a blocker for 9.0. Nhat is looking into it.
>
> We've been discussing releasing 9.0 for a long time now and I think that
> everybody agrees with moving forward, there's even some good momentum
> around making the build and release tooling ready. So I'd like to propose
> the following timeline for the 9.0 release to get some feedback:
>
> 2021-11-01: Feature freeze:
>  - branch_9x gets created from main
>  - branch_8_11 gets created from branch_8x
> This gives us ~2 weeks to do some last-minute work. The reasoning for
> doing 8.11 as well is that we have some enhancements merged to branch_8x
> that I suspect some users would like to see released in 8.x. Important
> note: 8.11 will be the last minor release of major version 8. There might
> be new patch releases in the future such as 8.11.1 or 8.11.2, but there
> won't be a 8.12 or a 8.13.
>
> 2021-11-04: First RC for 8.11
> Since we had 8.10 not long ago, hopefully the release process will go
> smoothly.
>
> ~2021-11-10: First RC for 9.0
> The date is indicative, the plan would be to move forward with the first
> 9.0 RC as soon as the following conditions are met:
>  - 8.11 is out
>  - all 9.0 blockers have been addressed
>
> Mike, your previous email suggests that you would like someone else to
> step up. If that's correct I'm happy to be the release manager for both
> 8.11 and 9.0.
>
>
> On Sat, Oct 2, 2021 at 11:54 PM Michael Sokolov 
> wrote:
>
>> Yes! I'm curious to give it a go, but getting pulled in many different
>> directions. If nobody else steps up, I will be free to shepherd the
>> release along in a  couple of weeks, assuming the current firestorm
>> subsides...
>>
>> On Thu, Sep 30, 2021 at 9:54 AM Jan Høydahl 
>> wrote:
>> >
>> > +1
>> >
>> > Blockers seem to be done with. So I guess we just need an RM to get the
>> ball rolling? :)
>> >
>> > I know that the Release Wizard in new Lucene repo needs some updates
>> https://issues.apache.org/jira/browse/LUCENE-9809 - I may help some with
>> that...
>> >
>> > Cross-ref other 9.0 release mail-threads:
>> > - "Now that 8.10 is out ... let's get rolling on 9!"
>> https://lists.apache.org/thread.html/r868028d42a19ae02d5bbe2e3329da26869045002b9bb4760b8056c56%40%3Cdev.lucene.apache.org%3E
>> > - "9.0 release":
>> https://lists.apache.org/thread.html/r7bef0af668860fdbfedb4b58261efd01d9fb26dc280915284c121065%40%3Cdev.lucene.apache.org%3E
>> >
>> > Jan
>> >
>> > 17. aug. 2021 kl. 11:13 skrev Adrien Grand :
>> >
>> > +1 to your suggestions
>> >
>> > I just commented on LUCENE-9959 to suggest reverting since the changes
>> are currently half baked and I don't think that they should block 9.0.
>> There are no other blockers left to my knowledge.
>> >
>> > On Sat, Aug 14, 2021 at 6:24 PM Michael Sokolov 
>> wrote:
>> >>
>> >> It's been two years since our last release, we had lots of +1 when we
>> >> raised this last December, and IMO we are close to baked at this
>> >> point.
>> >>
>> >> I checked JIRA and found two remaining Blockers
>> >>
>> >> 1. https://issues.apache.org/jira/browse/LUCENE-10016
>> >> VectorReader.search needs rethought, o.a.l.search integration?
>> >> 2. https://issues.apache.org/jira/browse/LUCENE-8638 Remove deprecated
>> >> code in main
>> >>
>> >> The first one is very close to resolved;
>> >>
>> >> On the deprecations, the issue has lingered for 1-1/2 years now, and
>> >> some progress has been made, but more work remains. Some new
>> >> deprecations have been added since it was opened too. Maybe we make a
>> >> concerted effort to clean out as much as we can, and then decide if
>> >> it's enough? Anyway this seems to be the only outstanding issue, so
>> >> let's see if we can make progress there
>> >>
>> >> Q: any other blockers?
>> >>
>> >> -
>> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>> >>
>> >
>> >
>> > --
>> > Adrien
>> >
>> >
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Adrien
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.10.1 RC1

[Anshum Gupta]

+1 (binding)

Smoke tester passed w/ JDK 8.

SUCCESS! [1:18:04.585401]

Also tried a basic app w/ indexing and search and everything I tested
worked as expected.

Thanks for doing this, Mayya!

On Tue, Oct 12, 2021 at 5: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]
> 
>


-- 
Anshum Gupta

Re: Welcome Michael Gibney as Lucene committer

[Anshum Gupta]

Congratulations and welcome, Michael!

On Wed, Oct 6, 2021 at 6:33 AM Dawid Weiss  wrote:

> Hello everyone!
>
> Please welcome Michael Gibney as the latest Lucene committer. Michael
> - it's a tradition for you to introduce yourself, even if we've been
> seeing you for quite a while! :)
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Search Track at ApacheCon 2021, Sep 21-23

[Anshum Gupta]

Hi Everyone,

ApacheCon 2021 is scheduled to begin next week. Like last year, the event
is *100% virtual and free* to register. Also, just like last year, we have
a dedicated Search track that has a lot of interesting talks and panel
discussion about Apache Lucene and Solr.

With 2 full days of sessions covering various Lucene, Solr, and Search, I
hope you are able to find some time to attend the sessions, learn something
new, and meet other people from the community.

There are various other tracks that span the 3 days of the conference and
you can find all the details here:
ApacheCon website - https://www.apachecon.com/acah2021/index.html
Registration - https://hopin.com/events/apachecon-2021-home
Slack - http://s.apache.org/apachecon-slack
Search Track - https://www.apachecon.com/acah2021/tracks/search.html

See you all at ApacheCon 2021!

-Anshum

Re: Welcome Mayya Sharipova to the Lucene PMC

[Anshum Gupta]

Congratulations and welcome, Mayya!

On Mon, Jun 28, 2021 at 6:16 AM Robert Muir  wrote:

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

-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Anshum Gupta]

dVerify(java, 'solr',
> tmpDir,
> > > >>> > > >> > 'solr-%s-src.tgz' % version,
> > > >>> > > >> >   File "/home/rmuir/workspace/lucene-solr/dev-
> > > tools/scripts/smokeTestRelease.py",
> > > >>> > > >> > line 566, in unpackAndVerify
> > > >>> > > >> > verifyUnpacked(java, project, artifact, unpackPath,
> gitRevision,
> > > >>> > > >> > version, testArgs, tmpDir, baseURL)
> > > >>> > > >> >   File "/home/rmuir/workspace/lucene-solr/dev-
> > > tools/scripts/smokeTestRelease.py",
> > > >>> > > >> > line 687, in verifyUnpacked
> > > >>> > > >> > java.run_java8('ant clean test -Dtests.slow=false %s'
> %
> > testArgs,
> > > >>> > > >> > '%s/test.log' % unpackPath)
> > > >>> > > >> >   File "/home/rmuir/workspace/lucene-solr/dev-
> > > tools/scripts/smokeTestRelease.py",
> > > >>> > > >> > line 1212, in run_java
> > > >>> > > >> > run('%s; %s' % (cmd_prefix, cmd), logfile)
> > > >>> > > >> >   File "/home/rmuir/workspace/lucene-solr/dev-
> > > tools/scripts/smokeTestRelease.py",
> > > >>> > > >> > line 500, in run
> > > >>> > > >> > raise RuntimeError('command "%s" failed; see log file
> %s' %
> > > >>> > > >> > (command, logPath))
> > > >>> > > >> > RuntimeError: command "export
> > > >>> > > >> > JAVA_HOME="/home/rmuir/Downloads/jdk8u282-b08"
> > > >>> > > >> > PATH="/home/rmuir/Downloads/jdk8u282-b08/bin:$PATH"
> > > >>> > > >> > JAVACMD="/home/rmuir/Downloads/jdk8u282-b08/bin/java";
> > ant
> > > clean test
> > > >>> > > >> > -Dtests.slow=false -Dtests.badapples=false " failed; see
> log file
> > > >>> > > >> >
> > >
> > /tmp/smoke_lucene_8.9.0_05c8a6f0163fe4c330e93775e8e91f3ab66a3f80/un
> > > pack/solr-8.9.0/test.log
> > > >>> > > >> >
> > > >>> > > >> > On Fri, Jun 11, 2021 at 9:47 AM Robert Muir
> > 
> > > wrote:
> > > >>> > > >> > >
> > > >>> > > >> > > I nuked all my settings and am rerunning with all
> defaults. I'll
> > > >>> > > >> > > report back what happens/upload log when/if it finishes
> or
> > fails.
> > > >>> > > >> > >
> > > >>> > > >> > > On Fri, Jun 11, 2021 at 9:45 AM Michael Sokolov
> > >  wrote:
> > > >>> > > >> > > >
> > > >>> > > >> > > > I tried to comment on the JIRA, but it seems to be
> timing out.
> > > Now
> > > >>> > > >> > > > when I go back, SOLR issues are marked as "You can't
> view
> > this
> > > issue
> > > >>> > > >> > > > It may have been deleted or you don't have permission
> to
> > view
> > > it."
> > > >>> > > >> > > > Waat?
> > > >>> > > >> > > >
> > > >>> > > >> > > > Anyway, Robert you suggested there that maybe the
> problem
> > is
> > > being
> > > >>> > > >> > > > surfaced by using a different working directory for
> the tests.
> > Do
> > > you
> > > >>> > > >> > > > think that the tests need to be fixed so that they
> work with
> > this
> > > >>> > > >> > > > tmp.workDir parameter? What if you were to cd to the
> place
> > > you want to
> > > >>> > > >> > > > use as the working dir and call the smokeTester from
> there?
> > > >>> > > >> > > >
> > > >>> > > >> > > >
> > > >>> > > >> > > > On Fri, Jun 11, 2021 at 9:29 AM Mayya Sharipova
> > > >>> > > >> > > >  wrote:
> > > >>> > > >> > > > >
> > > >>> > > >> > > > > Thanks very much Robert for detailed
> investigations, and
> > > thanks Jan for your tests.
> > > >>> > > >> > > > >
> > > >>> > > >> > > > > I will sort out the problem with my GPG key, but I
> am not
> > > sure what to do with this SOLR-15473. I've run the smoker test again,
> and it
> > > passed on my Mac again: SUCCESS! [1:00:03.751500]
> > > >>> > > >> > > > > Would appreciate more guidance, if we need to
> resolve
> > SOLR-
> > > 15473 before 8.9 release.
> > > >>> > > >> > > > >
> > > >>> > > >> > > > >
> > > >>> > > >> > > > > On Fri, Jun 11, 2021 at 8:09 AM Robert Muir
> > >  wrote:
> > > >>> > > >> > > > >>
> > > >>> > > >> > > > >> Dude, if you can vote +1 when the smoketester
> passes,
> > then
> > > I can vote
> > > >>> > > >> > > > >> -1 when it fails. This is my vote, not your vote.
> You don't
> > get
> > > to
> > > >>> > > >> > > > >> decide about it, or change it in any way.
> > > >>> > > >> > > > >>
> > > >>> > > >> > > > >> On Fri, Jun 11, 2021 at 8:04 AM Jan Høydahl
> > >  wrote:
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >> > Does it reproduce for you? Are you suspecting a
> bug in
> > Solr
> > > that we cannot ship, or only a bug in the smoketester py itself? The
> -1 should
> > > be about the released bits, not about other tooling?
> > > >>> > > >> > > > >> > My JVM is OpenJDK 64-Bit Server VM
> > > (AdoptOpenJDK)(build 25.292-b10, mixed mode)
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >> > Jan
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >> > > 11. jun. 2021 kl. 13:48 skrev Robert Muir
> > > :
> > > >>> > > >> > > > >> > >
> > > >>> > > >> > > > >> > > Jan, I'm using the same automated smoketester
> as
> > > everyone else. It
> > > >>> > > >> > > > >> > > fails, so my vote is -1.
> > > >>> > > >> > > > >> > >
> > > >>> > > >> > > > >> > > On Fri, Jun 11, 2021 at 7:22 AM Jan Høydahl
> > >  wrote:
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> Tested on MacOS (Intel), No other
> verification than
> > > smoketester done
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> SUCCESS! [1:08:19.953492]
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> +1
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> Robert - not sure if one test-run failure
> should cancel
> > > the build. Our smoketester and tests are sometimes a bit picky, and
> does not
> > > mean that the artifacts are faulty.
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> Jan
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> 11. jun. 2021 kl. 04:14 skrev Mayya Sharipova
> > > :
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> Please vote for release candidate 1 for
> Lucene/Solr
> > > 8.9.0
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> The artifacts can be downloaded from:
> > > >>> > > >> > > > >> > >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-
> > > solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> You can run the smoke tester directly with
> this
> > > command:
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> python3 -u
> dev-tools/scripts/smokeTestRelease.py \
> > > >>> > > >> > > > >> > >>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-
> > > solr-8.9.0-RC1-rev05c8a6f0163fe4c330e93775e8e91f3ab66a3f80
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> The vote will be open for at least 72 hours
> i.e. until
> > > 2021-06-16 02:00 UTC.
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> [ ] +1  approve
> > > >>> > > >> > > > >> > >> [ ] +0  no opinion
> > > >>> > > >> > > > >> > >> [ ] -1  disapprove (and reason why)
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >> Here is my +1
> > > >>> > > >> > > > >> > >> SUCCESS! [0:01:43.815224]
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >>
> > > >>> > > >> > > > >> > >
> > > >>> > > >> > > > >> > >
> -
> > > >>> > > >> > > > >> > > To unsubscribe, e-mail: dev-
> > > unsubscr...@lucene.apache.org
> > > >>> > > >> > > > >> > > For additional commands, e-mail: dev-
> > > h...@lucene.apache.org
> > > >>> > > >> > > > >> > >
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >> >
> -
> > > >>> > > >> > > > >> > To unsubscribe, e-mail: dev-
> > > unsubscr...@lucene.apache.org
> > > >>> > > >> > > > >> > For additional commands, e-mail: dev-
> > > h...@lucene.apache.org
> > > >>> > > >> > > > >> >
> > > >>> > > >> > > > >>
> > > >>> > > >> > > > >>
> -
> > > >>> > > >> > > > >> 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
> > > >>>
> > > >
> > > >
> > > > --
> > > > Adrien
> > >
> > > --
> > > Regards,
> > >
> > > Atri
> > > Apache Concerted
> > >
> > > -
> > > 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
>
>

-- 
Anshum Gupta

Re: Welcome Greg Miller as Lucene committer

[Anshum Gupta]

Congratulations and welcome, Greg!

On Sat, May 29, 2021 at 12: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
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.2 RC1

[Anshum Gupta]

+1 (binding)

Ran a sample indexing/search app and browsed through the admin UI.

Smoketester is happy!

SUCCESS! [1:05:05.761354]


On Tue, Apr 6, 2021 at 3:45 PM Mike Drob  wrote:

> Please vote for release candidate 1 for Lucene/Solr 8.8.2
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.2-RC1-reva92a05e195b775b30ca410bc0a26e8e79e7b3bfb
>
> 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.2-RC1-reva92a05e195b775b30ca410bc0a26e8e79e7b3bfb
>
> The vote will be open until 2021-04-12 00:00 UTC. I will tally votes on
> Monday morning.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>


-- 
Anshum Gupta

Re: Welcome Peter Gromov as Lucene committer

[Anshum Gupta]

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: SOLR-15056 circuit breaker bugfix?

[Anshum Gupta]

Hi Walter,

Can you please create a PR, as Ab mentioned in the JIRA. That would make it
much easier to review considering the size of the patch. It will also be
easier to comment and iterate that way.

-Anshum

On Tue, Mar 23, 2021 at 2:24 PM Walter Underwood 
wrote:

> The patch for SOLR-15056 was submitted over two months ago. It fixes a
> bug, adds a new kind of circuit breaker, improves the documentation, and
> has unit tests.
>
> I’ll make it into a PR if that is required, bit it is discouraging to put
> a bunch of work into a fix and have it ignored. This is a much better
> submission than the bar in Yonik’s Law of Patches.
>
> https://issues.apache.org/jira/browse/SOLR-15056
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>

-- 
Anshum Gupta

Re: [ANNOUNCE] Apache Solr TLP - Mailing lists created

[Anshum Gupta]

As a lot of you reached out to me about wanting to unsubscribe and I'm
unable to manually process this for each of you,

I recommend folks who want to unsubscribe from a mailing list to do so by
just sending an email to -unsubscr...@lucene.apache.org or
-unsubscr...@solr.apache.org, based on what the address for
the mailing list is e.g. If you want to unsubscribe from general@l.a.o, you
can do so by sending an email to general-unsubscribe@l.a.o.



On Fri, Mar 5, 2021 at 3:33 PM Anshum Gupta  wrote:

>
> Hi everyone,
>
>
> I'd like to inform you that new mailing lists have been created as part of
> the bootstrapping of the newly created Apache Solr TLP. Below are all the
> lists and their corresponding subscription request addresses that will be
> used for Solr going forward:
>
>
> 1. *Solr Dev* - d...@solr.apache.org [dev-subscr...@solr.apache.org]
>
> 2. *Builds* - bui...@solr.apache.org [builds-subscr...@solr.apache.org]
>
> 3. *Commits* - comm...@solr.apache.org [commits-subscr...@solr.apache.org]
>
> 4. *Issues* - iss...@solr.apache.org [issues-subscr...@solr.apache.org]
>
>
> The *Solr user mailing list has been migrated* from
> solr-u...@lucene.apache.org to *us...@solr.apache.org
> *. As part of this migration, all people who were
> subscribed to the old list continue to be subscribed to the new one. Any
> email sent to the old list going forward will automatically be redirected
> to the new address with an updated reply-to address i.e. emails for
> existing threads will be gracefully migrated. Please fix any mail filters
> you may have for this list.
>
>
> For more information please see -
> https://solr.apache.org/community.html#mailing-lists-chat
>
>
> Feel free to reach out to the Solr PMC in case of any questions or issues.
>
>
> -Anshum
>
> On behalf of the Apache Solr PMC
>
>

-- 
Anshum Gupta

[ANNOUNCE] Apache Solr TLP - Mailing lists created

[Anshum Gupta]

Hi everyone,


I'd like to inform you that new mailing lists have been created as part of
the bootstrapping of the newly created Apache Solr TLP. Below are all the
lists and their corresponding subscription request addresses that will be
used for Solr going forward:


1. *Solr Dev* - d...@solr.apache.org [dev-subscr...@solr.apache.org]

2. *Builds* - bui...@solr.apache.org [builds-subscr...@solr.apache.org]

3. *Commits* - comm...@solr.apache.org [commits-subscr...@solr.apache.org]

4. *Issues* - iss...@solr.apache.org [issues-subscr...@solr.apache.org]


The *Solr user mailing list has been migrated* from
solr-u...@lucene.apache.org to *us...@solr.apache.org
*. As part of this migration, all people who were
subscribed to the old list continue to be subscribed to the new one. Any
email sent to the old list going forward will automatically be redirected
to the new address with an updated reply-to address i.e. emails for
existing threads will be gracefully migrated. Please fix any mail filters
you may have for this list.


For more information please see -
https://solr.apache.org/community.html#mailing-lists-chat


Feel free to reach out to the Solr PMC in case of any questions or issues.


-Anshum

On behalf of the Apache Solr PMC

Re: Review request - New Solr website

[Anshum Gupta]

 solr.apache.org is at
> https://lucene-solrtlp.staged.apache.org/
> >>> The staging site which shows the lucene site without Solr is at
> https://lucene-new.staged.apache.org/
> >>>
> >>> Any feedback is welcome, here or in the JIRA issue. I intend to
> publish the new sites in a couple of days.
> >>>
> >>> Jan
> >>
> >>
> >> -
> >> 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
>
>

-- 
Anshum Gupta

Re: Lucene/Solr Code of Conduct and etiquette

[Anshum Gupta]

Thanks for adding this, Jan.

I'll take a look at the pages tomorrow.

On Tue, Mar 2, 2021 at 1:30 AM Jan Høydahl  wrote:

> Hi community!
>
> The Apache Software Foundation has a foundation-wide Code of Conduct
> written up (https://www.apache.org/foundation/policies/conduct), and I
> believe the Lucene and Solr communities would benefit from explicitly
> adopting it for our projects. This is an example of how HBase has done so:
> https://hbase.apache.org/coc.html
>
> When it comes to email communication in particular, I find this etiquette
> from ComDev helpful: https://community.apache.org/contributors/etiquette.
> Let's link to it as well.
>
> Finally, it could be helpful to also call out http://theapacheway.com/ or
> a similar resource about The Apache Way.
>
> Please see my early attempt at including CoC in the new Solr webpage
> draft:
> https://lucene-solrtlp.staged.apache.org/community.html#code-of-conduct
> I plan to add a similar section or page to the Lucene site.
>
> Appreciate your feedback on this. Our discussions sometimes heat up, which
> is not uncommon from time to time. But perhaps reminding ourselves about
> The Apache Way, CoC and Etiquette will help each of us adopting healthier
> practices in writing emails, choosing our words wisely etc. I know it helps
> for me.
>
> Jan
> -
> 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.8.1 RC2

[Anshum Gupta]

+1 (binding)
SUCCESS! [1:04:04.738835]

Tested with a sample app, basic indexing, search, and went through the UI.
Looks good.

Thanks for the effort, Tim!



On Tue, Feb 16, 2021 at 6:42 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
>
>

-- 
Anshum Gupta

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

[Anshum Gupta]

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

[ANNOUNCE] Apache Solr TLP Created

[Anshum Gupta]

Hi everyone,

On behalf of the Apache Lucene PMC, and the newly formed Apache Solr PMC,
I’d like to inform folks that the ASF board has approved the resolution to
create the Solr TLP (Top Level Project).

We are currently working on the next steps but would like to assure the
community that they can continue to expect critical bug fixes for releases
previously made under the Apache Lucene project.

We will send another update as the mailing lists and website are set up for
the Solr project.

-Anshum
On behalf of the Apache Lucene and Solr PMC

Congratulations to the new Lucene PMC Chair, Michael Sokolov!

[Anshum Gupta]

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

Apache Solr TLP Update

[Anshum Gupta]

Hello everyone,

Last year the Apache Lucene committers voted to propose the spinning off
and creation of Solr as an Apache TLP (Top Level Project)[1]

The PMC has submitted an ASF board resolution, to be reviewed during the
upcoming board meeting on Wednesday, Feb 17 2021.

The Lucene PMC also decided to bootstrap the new project with the Lucene
PMC members, and intends to add the existing Lucene committers in the same
role for Apache Solr, once the proposal for its creation is accepted by the
board.

The process to add the non-PMC member committers will be completed shortly
after the project creation is announced, so all committers should look for
their notification email.

The Apache Lucene PMC is currently working on the next steps and will share
them with the community once we have more details. You can expect the
updates to be sent to the Lucene developers list until the migration is
complete.

Please feel free to reach out to the Lucene PMC with any questions.

- Anshum Gupta
on behalf of the Apache Lucene PMC

[1] https://s.apache.org/solr-tlp-vote-result

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Anshum Gupta]

om
>>>> >>
>>>> >>
>>>> >> On Sun, Feb 14, 2021 at 11:26 AM Timothy Potter <
>>>> thelabd...@apache.org> wrote:
>>>> >>>
>>>> >>> Please vote for release candidate 1 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-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>>> >>>
>>>> >>>
>>>> >>> 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-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>>> >>>
>>>> >>>
>>>> >>> The vote will be open for at least 72 hours i.e. until 2021-02-17
>>>> 17:00 UTC.
>>>> >>>
>>>> >>>
>>>> >>> Here is my +1 ~ SUCCESS! [0:50:06.728441]
>>>> >>>
>>>> >>>
>>>> >>> In addition to the smoke test, I built a Docker image from
>>>> solr-8.8.1.tgz 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 RC1 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
>>>>
>>>>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Anshum Gupta]

Interesting.

I didn't use the flag, but just changed the code to comment out the
randomization from SolrCloudTestCase.java.

I think Tim did the same, so I'm not sure if that's the difference or if
there's a difference of environment.

On Mon, Feb 15, 2021 at 9:48 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I did another round of beast, this time setting that flag to true (as
> suggested to me by Noble).
>
> ant -Duse.perreplica=true -Dtests.dups=1 -Dtests.iters=5 -Dbeast.iters=5
> -Dtestcase=SolrCloudReportersTest beast
>
> -beast:
>   [beaster] Beast round 1 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>   [beaster] Beast round 2 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/2
>   [beaster] Beast round 3 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/3
>   [beaster] Beast round 4 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/4
>   [beaster] Beast round 5 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/5
>   [beaster] Beasting finished Successfully.
>
>
> I'm not sure what's going on :-(
>
> On Tue, Feb 16, 2021 at 11:13 AM Anshum Gupta 
> wrote:
>
>> Ishan/Noble, thanks for taking a look at this.
>>
>> I only just started to look at the cause, so I'm sure you have better
>> context on why this is failing and if it makes sense to still release with
>> this issue.
>>
>> FYI, I was able to get a successful smoke test run finally, but the fact
>> that it took me over 7 runs.
>>
>> Also, can you confirm how did you run the test? you might be getting
>> lucky with the randomization here. Both me and Tim just commented out the
>> randomization for USE_PER_REPLICA_STATE and hardcoding this value to true
>> consistently got the test to fail. The default (false) did get the test to
>> pass 100% of the times.
>>
>> If you think we can have this fix before the release, it might make more
>> sense to have a single release for users as it wouldn't involve tracking
>> the complexity of what's broken in a released version. I still would like
>> to spend some more time tomorrow before voting on this one, but at least
>> the smoke test is out of the way. I'll try and debug this tomorrow.
>>
>>
>> On Mon, Feb 15, 2021 at 8:40 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> I tried light beasting the test on branch_8_8:
>>> ant -Dtests.dups=1 -Dtests.iters=5 -Dbeast.iters=5
>>> -Dtestcase=SolrCloudReportersTest beast
>>>
>>> No failures.
>>>
>>>   [beaster] Beast round 1 results:
>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>>>   [beaster] Beast round 2 results:
>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/2
>>>   [beaster] Beast round 3 results:
>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/3
>>>   [beaster] Beast round 4 results:
>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/4
>>>   [beaster] Beast round 5 results:
>>> /home/ishan/code/lucene-solr/solr/build/solr-core/test/5
>>>   [beaster] Beasting finished Successfully.
>>>
>>> On Tue, Feb 16, 2021 at 10:07 AM Noble Paul 
>>> wrote:
>>>
>>>> @Anshum Gupta
>>>>
>>>> I think we should not hold up the release of RC1 because of that
>>>> failure.
>>>>
>>>> This is a new feature and new features take time to get hardened.
>>>>
>>>> However, We can investigate and fix this anyway.
>>>>
>>>> If required, we can do a 8.8.3
>>>>
>>>> On Tue, Feb 16, 2021 at 3:10 PM Ishan Chattopadhyaya
>>>>  wrote:
>>>> >
>>>> > Here's my +1 for the RC1.
>>>> >
>>>> > SUCCESS! [0:42:38.936787]
>>>> >
>>>> > On Tue, Feb 16, 2021 at 9:02 AM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>> >>
>>>> >> Per Replica States is a new feature introduced in 8.8.0. It will
>>>> require a critical bugfix (SOLR-15138) immediately after 8.8.1 (in a 8.8.2
>>>> release). If this issue is confirmed to be PRS related, then I think we
>>>> should continue with this release and fix PRS in 8.8.2.
>>>> >>
>>>> >> However, if you still want us to investigate and fix this issue now,
>>>> we can take a look. If you have a failing seed handy, please let me know.
>>>> >>
>>>> >

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Anshum Gupta]

Ishan/Noble, thanks for taking a look at this.

I only just started to look at the cause, so I'm sure you have better
context on why this is failing and if it makes sense to still release with
this issue.

FYI, I was able to get a successful smoke test run finally, but the fact
that it took me over 7 runs.

Also, can you confirm how did you run the test? you might be getting lucky
with the randomization here. Both me and Tim just commented out the
randomization for USE_PER_REPLICA_STATE and hardcoding this value to true
consistently got the test to fail. The default (false) did get the test to
pass 100% of the times.

If you think we can have this fix before the release, it might make more
sense to have a single release for users as it wouldn't involve tracking
the complexity of what's broken in a released version. I still would like
to spend some more time tomorrow before voting on this one, but at least
the smoke test is out of the way. I'll try and debug this tomorrow.


On Mon, Feb 15, 2021 at 8:40 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> I tried light beasting the test on branch_8_8:
> ant -Dtests.dups=1 -Dtests.iters=5 -Dbeast.iters=5
> -Dtestcase=SolrCloudReportersTest beast
>
> No failures.
>
>   [beaster] Beast round 1 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/1
>   [beaster] Beast round 2 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/2
>   [beaster] Beast round 3 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/3
>   [beaster] Beast round 4 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/4
>   [beaster] Beast round 5 results:
> /home/ishan/code/lucene-solr/solr/build/solr-core/test/5
>   [beaster] Beasting finished Successfully.
>
> On Tue, Feb 16, 2021 at 10:07 AM Noble Paul  wrote:
>
>> @Anshum Gupta
>>
>> I think we should not hold up the release of RC1 because of that failure.
>>
>> This is a new feature and new features take time to get hardened.
>>
>> However, We can investigate and fix this anyway.
>>
>> If required, we can do a 8.8.3
>>
>> On Tue, Feb 16, 2021 at 3:10 PM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > Here's my +1 for the RC1.
>> >
>> > SUCCESS! [0:42:38.936787]
>> >
>> > On Tue, Feb 16, 2021 at 9:02 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>
>> >> Per Replica States is a new feature introduced in 8.8.0. It will
>> require a critical bugfix (SOLR-15138) immediately after 8.8.1 (in a 8.8.2
>> release). If this issue is confirmed to be PRS related, then I think we
>> should continue with this release and fix PRS in 8.8.2.
>> >>
>> >> However, if you still want us to investigate and fix this issue now,
>> we can take a look. If you have a failing seed handy, please let me know.
>> >>
>> >> On Tue, Feb 16, 2021 at 8:33 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>> >>>
>> >>> Surprising. I'll take a look.
>> >>>
>> >>> On Tue, 16 Feb, 2021, 7:29 am Anshum Gupta, 
>> wrote:
>> >>>>
>> >>>> I've unsuccessfully tried getting the smoketester to pass and have
>> had 6 fails so far.
>> >>>>
>> >>>> At this point it seems like SolrCloudReporterTest and
>> AutoscalingHistoryTest tests are failing pretty consistently for me.
>> >>>>
>> >>>> The former is a new failure, and seems to be caused by the
>> USE_PER_REPLICA_STATE randomization.
>> >>>>
>> >>>> Both Tim and me tried running the tests without the randomization
>> and defaulting that property to false gets the tests to pass, however it
>> seems to be failing every time the value for USE_PER_REPLICA_STATE is set
>> to true.
>> >>>>
>> >>>> I'm not voting -1 yet, as I'm not sure how much this affects the
>> build vs the test, but once we have a clearer picture, we might need a fix
>> and have to respin this.
>> >>>>
>> >>>> -Anshum
>> >>>>
>> >>>> On Sun, Feb 14, 2021 at 8:31 AM Timothy Potter 
>> wrote:
>> >>>>>
>> >>>>> Looks like an extra space got added on the end of the python3
>> command, try this one:
>> >>>>>
>> >>>>> python3 -u dev-tools/scripts/smokeTestRelease.py
>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>> >>>>>
>> 

Re: [VOTE] Release Lucene/Solr 8.8.1 RC1

[Anshum Gupta]

I've unsuccessfully tried getting the smoketester to pass and have had 6
fails so far.

At this point it seems like SolrCloudReporterTest and
AutoscalingHistoryTest tests are failing pretty consistently for me.

The former is a new failure, and seems to be caused by the
USE_PER_REPLICA_STATE randomization.

Both Tim and me tried running the tests without the randomization and
defaulting that property to false gets the tests to pass, however it seems
to be failing every time the value for USE_PER_REPLICA_STATE is set to true.

I'm not voting -1 yet, as I'm not sure how much this affects the build vs
the test, but once we have a clearer picture, we might need a fix and have
to respin this.

-Anshum

On Sun, Feb 14, 2021 at 8:31 AM Timothy Potter  wrote:

> Looks like an extra space got added on the end of the python3 command, try
> this one:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.1-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>
>
>
>
> On Sun, Feb 14, 2021 at 9:26 AM Timothy Potter 
> wrote:
>
>> Please vote for release candidate 1 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-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>
>>
>> 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-RC1-rev6a50a0315ac7e4979abb0b530857c7795bb3b928
>>
>>
>> The vote will be open for at least 72 hours i.e. until 2021-02-17 17:00
>> UTC.
>>
>>
>> Here is my +1 ~ SUCCESS! [0:50:06.728441]
>>
>>
>> In addition to the smoke test, I built a Docker image from
>> solr-8.8.1.tgz 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 RC1 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
>>
>>
>>
>>
>>

-- 
Anshum Gupta

Re: Help needed with fixing lucene-site GitHub repo

[Anshum Gupta]

This has been resolved.

Thanks to everyone who helped :)

On Wed, Feb 10, 2021 at 12:36 PM Anshum Gupta 
wrote:

> Can you elaborate more around this? I was also trying to see if I could
> just create  a PR to merge production -> master, but that would just mess
> up the history. It will bring the code in sync but I'm also not sure if
> that would fix the larger problem.
>
> On Wed, Feb 10, 2021 at 12:01 PM Michael Sokolov 
> wrote:
>
>> Have you considered using a merge commit for this? That won't require
>> force pushing
>>
>> On Wed, Feb 10, 2021 at 2:51 PM Anshum Gupta 
>> wrote:
>> >
>> > Hi All,
>> >
>> > Seems like during the last release, we directly committed the website
>> changes to the production branch, bypassing the master. This is now causing
>> issues with merging updates from master into prod using the simple 'create
>> PR' -> 'merge master to prod' workflow.
>> >
>> > I was working with Cassandra to clean this up but we'd need help from
>> someone who's more confident and experienced with such GitHub issues.
>> >
>> > I tried rebasing production to master in hopes that we'll get the
>> missing commits correctly into master, but that seems to warn of the
>> diverging branches and requires a force push, something I wasn't
>> comfortable doing without another set of eyes :)
>> >
>> > If you have suggestions or know what to do here, please help with
>> fixing the branch.
>> >
>> > --
>> > Anshum Gupta
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>


-- 
Anshum Gupta

Re: Help needed with fixing lucene-site GitHub repo

[Anshum Gupta]

Can you elaborate more around this? I was also trying to see if I could
just create  a PR to merge production -> master, but that would just mess
up the history. It will bring the code in sync but I'm also not sure if
that would fix the larger problem.

On Wed, Feb 10, 2021 at 12:01 PM Michael Sokolov  wrote:

> Have you considered using a merge commit for this? That won't require
> force pushing
>
> On Wed, Feb 10, 2021 at 2:51 PM Anshum Gupta 
> wrote:
> >
> > Hi All,
> >
> > Seems like during the last release, we directly committed the website
> changes to the production branch, bypassing the master. This is now causing
> issues with merging updates from master into prod using the simple 'create
> PR' -> 'merge master to prod' workflow.
> >
> > I was working with Cassandra to clean this up but we'd need help from
> someone who's more confident and experienced with such GitHub issues.
> >
> > I tried rebasing production to master in hopes that we'll get the
> missing commits correctly into master, but that seems to warn of the
> diverging branches and requires a force push, something I wasn't
> comfortable doing without another set of eyes :)
> >
> > If you have suggestions or know what to do here, please help with fixing
> the branch.
> >
> > --
> > Anshum Gupta
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Help needed with fixing lucene-site GitHub repo

[Anshum Gupta]

Hi All,

Seems like during the last release, we directly committed the website
changes to the production branch, bypassing the master. This is now causing
issues with merging updates from master into prod using the simple 'create
PR' -> 'merge master to prod' workflow.

I was working with Cassandra to clean this up but we'd need help from
someone who's more confident and experienced with such GitHub issues.

I tried rebasing production to master in hopes that we'll get the missing
commits correctly into master, but that seems to warn of the diverging
branches and requires a force push, something I wasn't comfortable doing
without another set of eyes :)

If you have suggestions or know what to do here, please help with fixing
the branch.

-- 
Anshum Gupta

Re: 8.8.1 release soon

[Anshum Gupta]

Thanks for taking care of this, Tim.

I've added a note to the 'downloads' page so folks who head there know
about this issue and that a release with the fix is in the works. (thanks
for reviewing that too :) )

-Anshum

On Wed, Feb 10, 2021 at 7:37 AM Timothy Potter  wrote:

> I was a tad bit ambitious with backporting SOLR-12182 to 8.8.0 and it
> seems we have no automated SolrJ back-compat tests in our RC vetting
> process, so unfortunately older SolrJ clients don't work with Solr 8.8
> server, see SOLR-15145.
>
> I'd like to release 8.8.1 ASAP to address this problem and will be the RM.
>
> Let me know if you have any other issues you think need to go into 8.8.1,
> otherwise I'd like to build an RC tomorrow AM US time. It looks like there
> are already a number of updates going in for 8.9 so let's keep the updates
> for 8.8.1 to a minimum please.
>
> Cheers,
> Tim
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Anshum Gupta]

Thanks for handing the release, Noble!

+1 (binding)

SUCCESS! [0:56:12.016387]

Ran the smoke tester, a demo app, and checked the change log. All of that
looks good.

On Mon, Jan 25, 2021 at 2:22 AM Noble Paul  wrote:

> Please vote for release candidate 2 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-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.8.0-RC2-revb10659f0fc18b58b90929cfdadde94544d202c4a/
>
>
>
> The vote will be open for at least 72 hours
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
> --
> -
> Noble Paul
>
> -
> 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.8.0 RC1

[Anshum Gupta]

-1 for RC1.

The fix has been merged into 8x and 8.8 branches so we should be able to
respin and start another vote.

Thanks for the fix, Tim!

On Thu, Jan 21, 2021 at 2:42 PM Mike Drob  wrote:

> -1
>
> I have been able to reproduce the regression that Anshum found, and would
> like to change my vote accordingly.
>
> On Thu, Jan 21, 2021 at 4:31 PM Anshum Gupta 
> wrote:
>
>> https://issues.apache.org/jira/browse/SOLR-15097
>>
>>
>>
>> On Thu, Jan 21, 2021 at 2:28 PM Anshum Gupta 
>> wrote:
>>
>>> While testing the artifacts some more, I realized that the cluster graph
>>> doesn't show up on the admin UI any more.
>>>
>>> I started the cluster with -e cloud -noprompt, and the getting started
>>> collection was created successfully. The clusterstate, as well as the admin
>>> UI confirm that.
>>>
>>> I also tried creating a collection using the admin API, which was
>>> successful, but the graph didn't reflect that either.
>>>
>>> I've tested this using both Safari and Firefox, and it's clearly not a
>>> browser issue.
>>>
>>> Considering that the users rely on the graph, I think we might need to
>>> fix and respin this.
>>>
>>>
>>> On Tue, Jan 19, 2021 at 8:51 AM 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
>>>> 
>>>>
>>>
>>>
>>> --
>>> Anshum Gupta
>>>
>>
>>
>> --
>> Anshum Gupta
>>
>

-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Anshum Gupta]

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



On Thu, Jan 21, 2021 at 2:28 PM Anshum Gupta  wrote:

> While testing the artifacts some more, I realized that the cluster graph
> doesn't show up on the admin UI any more.
>
> I started the cluster with -e cloud -noprompt, and the getting started
> collection was created successfully. The clusterstate, as well as the admin
> UI confirm that.
>
> I also tried creating a collection using the admin API, which was
> successful, but the graph didn't reflect that either.
>
> I've tested this using both Safari and Firefox, and it's clearly not a
> browser issue.
>
> Considering that the users rely on the graph, I think we might need to fix
> and respin this.
>
>
> On Tue, Jan 19, 2021 at 8:51 AM 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
>> 
>>
>
>
> --
> Anshum Gupta
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Anshum Gupta]

While testing the artifacts some more, I realized that the cluster graph
doesn't show up on the admin UI any more.

I started the cluster with -e cloud -noprompt, and the getting started
collection was created successfully. The clusterstate, as well as the admin
UI confirm that.

I also tried creating a collection using the admin API, which was
successful, but the graph didn't reflect that either.

I've tested this using both Safari and Firefox, and it's clearly not a
browser issue.

Considering that the users rely on the graph, I think we might need to fix
and respin this.


On Tue, Jan 19, 2021 at 8:51 AM 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
> 
>


-- 
Anshum Gupta

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Anshum Gupta]

+1
SUCCESS! [0:59:24.721238]

Smoke tester passed, tried running a sample app with tons of collections
created, random data indexed, and some querying and all looked fine w/
SolrJ.

The changelog looks good too.


On Tue, Jan 19, 2021 at 8:51 AM 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
> 
>


-- 
Anshum Gupta

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

Based on the discussion on the committer meeting, I'll put in a request to
create a solr sandbox repo.

Thank you everyone.

On Tue, Jan 12, 2021 at 8:13 PM Noble Paul  wrote:

> I'm +1 for a  top level sandbox repo. Anyone should be able create a
> project in that.
>
> Once the project graduates out of the sandbox we should create a top level
>
> On Wed, Jan 13, 2021, 11:30 AM Anshum Gupta 
> wrote:
>
>> Building this as a branch is an option, but building it outside in a
>> personal repo is exactly what's not the Apache Way.
>>
>> Code should be designed and built in the Apache world, else it'd be a
>> grant/donation and not really a PR. Also, you can't create a PR against a
>> repo that doesn't exist upstream.
>>
>> Do you have an objection against a mono-repo i.e. solr-sandbox too? That
>> would open the door for us to use this for similar purposes in the future,
>> until the code is ready to be released.
>>
>> Also, just to reiterate, creating a repo doesn't cost anything and we
>> aren't releasing anything. This is a placeholder to put the code in. If it
>> works out well, we can release it or iterate on the code/implementation. In
>> any case, it would have zero impact on the project itself.
>>
>> -Anshum
>>
>> On Tue, Jan 12, 2021 at 3:37 PM Noble Paul  wrote:
>>
>>> I feel this is placing the cart before the horse.
>>>
>>> We can always build this as a branch or a repo under your own account.
>>> Once we reach a point where the project is reasonably mature, you can
>>> create a repo and contribute it upstream.
>>>
>>>
>>> On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta 
>>> wrote:
>>> >
>>> > I understand what you are saying, which is also my reason to not have
>>> a mono-repo. This way it's easier to manage and drop a repository when it's
>>> not needed. It doesn't cause clutter and lives in isolation.
>>> >
>>> > I think we are on the same page in terms of the intention.
>>> >
>>> >
>>> > On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> >>
>>> >> Look at the branches that are cluttering up our main repository, many
>>> symbolic of unfinished work. If we start one repo each for everything we
>>> hope to finish, we'll make Solr annoying in a new way.
>>> >>
>>> >> There is no reason multiple artifacts can't be released independently
>>> from the same repo. Why are you opposed to that idea, Anshum?
>>> >>
>>> >> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, 
>>> wrote:
>>> >>>
>>> >>> Thank you everyone!
>>> >>>
>>> >>> I'll move forward with the cross-dc repo creation then as mentioned
>>> in the original email :)
>>> >>>
>>> >>> If we want to change the approach on the repo, we can always change
>>> that before we release anything in the future.
>>> >>>
>>> >>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob  wrote:
>>> >>>>
>>> >>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer
>>> multiple many repos for future plugins or integrations. In this specific
>>> case, I think the relevant deciding points are 1) we don't have multiple
>>> things yet, so deciding between a "mono-repo" and a "multi-repo" is not
>>> very consequential 2) we can always rename things later 3) in the absence
>>> of a strong reason otherwise i'll defer to the people doing the work (in
>>> this case, Anshum). We considered sandbox and can always create one in the
>>> future. If Anshum feels that solr-cross-dc is better for now than I'm fine
>>> with that too.
>>> >>>>
>>> >>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley 
>>> wrote:
>>> >>>>>
>>> >>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>> >>>>>
>>> >>>>> A repo which holds multiple independent modules that can work with
>>> Solr need not release them all at once.
>>> >>>>>
>>> >>>>> ~ David Smiley
>>> >>>>> Apache Lucene/Solr Search Developer
>>> >>>>> http://www.linkedin.com/in/davidwsmiley
>>> >>>>>
>>> >>>>>
>>> >>

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

Building this as a branch is an option, but building it outside in a
personal repo is exactly what's not the Apache Way.

Code should be designed and built in the Apache world, else it'd be a
grant/donation and not really a PR. Also, you can't create a PR against a
repo that doesn't exist upstream.

Do you have an objection against a mono-repo i.e. solr-sandbox too? That
would open the door for us to use this for similar purposes in the future,
until the code is ready to be released.

Also, just to reiterate, creating a repo doesn't cost anything and we
aren't releasing anything. This is a placeholder to put the code in. If it
works out well, we can release it or iterate on the code/implementation. In
any case, it would have zero impact on the project itself.

-Anshum

On Tue, Jan 12, 2021 at 3:37 PM Noble Paul  wrote:

> I feel this is placing the cart before the horse.
>
> We can always build this as a branch or a repo under your own account.
> Once we reach a point where the project is reasonably mature, you can
> create a repo and contribute it upstream.
>
>
> On Wed, Jan 13, 2021 at 6:27 AM Anshum Gupta 
> wrote:
> >
> > I understand what you are saying, which is also my reason to not have a
> mono-repo. This way it's easier to manage and drop a repository when it's
> not needed. It doesn't cause clutter and lives in isolation.
> >
> > I think we are on the same page in terms of the intention.
> >
> >
> > On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >>
> >> Look at the branches that are cluttering up our main repository, many
> symbolic of unfinished work. If we start one repo each for everything we
> hope to finish, we'll make Solr annoying in a new way.
> >>
> >> There is no reason multiple artifacts can't be released independently
> from the same repo. Why are you opposed to that idea, Anshum?
> >>
> >> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, 
> wrote:
> >>>
> >>> Thank you everyone!
> >>>
> >>> I'll move forward with the cross-dc repo creation then as mentioned in
> the original email :)
> >>>
> >>> If we want to change the approach on the repo, we can always change
> that before we release anything in the future.
> >>>
> >>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob  wrote:
> >>>>
> >>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer
> multiple many repos for future plugins or integrations. In this specific
> case, I think the relevant deciding points are 1) we don't have multiple
> things yet, so deciding between a "mono-repo" and a "multi-repo" is not
> very consequential 2) we can always rename things later 3) in the absence
> of a strong reason otherwise i'll defer to the people doing the work (in
> this case, Anshum). We considered sandbox and can always create one in the
> future. If Anshum feels that solr-cross-dc is better for now than I'm fine
> with that too.
> >>>>
> >>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley 
> wrote:
> >>>>>
> >>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
> >>>>>
> >>>>> A repo which holds multiple independent modules that can work with
> Solr need not release them all at once.
> >>>>>
> >>>>> ~ David Smiley
> >>>>> Apache Lucene/Solr Search Developer
> >>>>> http://www.linkedin.com/in/davidwsmiley
> >>>>>
> >>>>>
> >>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta 
> wrote:
> >>>>>>
> >>>>>> David, this is about the Cross DC work that was supposed to be done
> :-)
> >>>>>>
> >>>>>> The independent release cadence is primarily the reason why a new
> repo makes sense to me in this case.
> >>>>>>
> >>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley 
> wrote:
> >>>>>>>
> >>>>>>> While I like the idea of a single (Apache!) repo for multiple
> packages/plugins, that does not apply to the Solr Operator, which isn't
> even in Java.  It's too unique.  So I agree with Anshum & others about
> creating an Apache repo for the Solr Operator.
> >>>>>>>
> >>>>>>> I think the ship has sailed on the Solr Operator being an Apache
> project instead of some committer's pet project.
> >>>>>>>
> >>>>>>> ~ David Smiley
> >>>>

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

I understand what you are saying, which is also my reason to not have a
mono-repo. This way it's easier to manage and drop a repository when it's
not needed. It doesn't cause clutter and lives in isolation.

I think we are on the same page in terms of the intention.


On Tue, Jan 12, 2021 at 10:51 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Look at the branches that are cluttering up our main repository, many
> symbolic of unfinished work. If we start one repo each for everything we
> hope to finish, we'll make Solr annoying in a new way.
>
> There is no reason multiple artifacts can't be released independently from
> the same repo. Why are you opposed to that idea, Anshum?
>
> On Tue, 12 Jan, 2021, 11:53 pm Anshum Gupta, 
> wrote:
>
>> Thank you everyone!
>>
>> I'll move forward with the cross-dc repo creation then as mentioned in
>> the original email :)
>>
>> If we want to change the approach on the repo, we can always change that
>> before we release anything in the future.
>>
>> On Mon, Jan 11, 2021 at 10:32 AM Mike Drob  wrote:
>>
>>> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer
>>> multiple many repos for future plugins or integrations. In this specific
>>> case, I think the relevant deciding points are 1) we don't have multiple
>>> things yet, so deciding between a "mono-repo" and a "multi-repo" is not
>>> very consequential 2) we can always rename things later 3) in the absence
>>> of a strong reason otherwise i'll defer to the people doing the work (in
>>> this case, Anshum). We considered sandbox and can always create one in the
>>> future. If Anshum feels that solr-cross-dc is better for now than I'm fine
>>> with that too.
>>>
>>> On Sun, Jan 10, 2021 at 5:07 PM David Smiley  wrote:
>>>
>>>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>>>
>>>> A repo which holds multiple independent modules that can work with Solr
>>>> need not release them all at once.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta 
>>>> wrote:
>>>>
>>>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>>>
>>>>> The independent release cadence is primarily the reason why a new repo
>>>>> makes sense to me in this case.
>>>>>
>>>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley 
>>>>> wrote:
>>>>>
>>>>>> While I like the idea of a single (Apache!) repo for multiple
>>>>>> packages/plugins, that does not apply to the Solr Operator, which isn't
>>>>>> even in Java.  It's too unique.  So I agree with Anshum & others about
>>>>>> creating an Apache repo for the Solr Operator.
>>>>>>
>>>>>> I think the ship has sailed on the Solr Operator being an Apache
>>>>>> project instead of some committer's pet project.
>>>>>>
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>
>>>>>>
>>>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>
>>>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using
>>>>>>> external repositories (forks) and raise pull requests against Apache 
>>>>>>> owned
>>>>>>> repositories. There's no SGA needed on such occasions.
>>>>>>>
>>>>>>> I see two paths forward from here.
>>>>>>>
>>>>>>> a) Lets setup a single repository for all packages/plugins, say
>>>>>>> lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., 
>>>>>>> and
>>>>>>> develop it there.
>>>>>>> b) All development for this effort happens in an external repository
>>>>>>> (https://github.com/apple/solr-dc or
>>>>>>> https://github.com/anshumg/solr-dc) and we raise a PR against
>>>>>>> Apache owned repository (which can be created if needed once we are all
>>>>>>> o

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

Thank you everyone!

I'll move forward with the cross-dc repo creation then as mentioned in the
original email :)

If we want to change the approach on the repo, we can always change that
before we release anything in the future.

On Mon, Jan 11, 2021 at 10:32 AM Mike Drob  wrote:

> I'm seeing valid reasons to prefer one solr sandbox repo, or prefer
> multiple many repos for future plugins or integrations. In this specific
> case, I think the relevant deciding points are 1) we don't have multiple
> things yet, so deciding between a "mono-repo" and a "multi-repo" is not
> very consequential 2) we can always rename things later 3) in the absence
> of a strong reason otherwise i'll defer to the people doing the work (in
> this case, Anshum). We considered sandbox and can always create one in the
> future. If Anshum feels that solr-cross-dc is better for now than I'm fine
> with that too.
>
> On Sun, Jan 10, 2021 at 5:07 PM David Smiley  wrote:
>
>> (palm-to-face) -- LOL okay sorry.  I'm getting my threads crossed.
>>
>> A repo which holds multiple independent modules that can work with Solr
>> need not release them all at once.
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sat, Jan 9, 2021 at 4:48 PM Anshum Gupta 
>> wrote:
>>
>>> David, this is about the Cross DC work that was supposed to be done :-)
>>>
>>> The independent release cadence is primarily the reason why a new repo
>>> makes sense to me in this case.
>>>
>>> On Sat, Jan 9, 2021 at 1:24 PM David Smiley  wrote:
>>>
>>>> While I like the idea of a single (Apache!) repo for multiple
>>>> packages/plugins, that does not apply to the Solr Operator, which isn't
>>>> even in Java.  It's too unique.  So I agree with Anshum & others about
>>>> creating an Apache repo for the Solr Operator.
>>>>
>>>> I think the ship has sailed on the Solr Operator being an Apache
>>>> project instead of some committer's pet project.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>>
>>>>> Not necessarily. Most people contribute to Apache Lucene/Solr using
>>>>> external repositories (forks) and raise pull requests against Apache owned
>>>>> repositories. There's no SGA needed on such occasions.
>>>>>
>>>>> I see two paths forward from here.
>>>>>
>>>>> a) Lets setup a single repository for all packages/plugins, say
>>>>> lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., 
>>>>> and
>>>>> develop it there.
>>>>> b) All development for this effort happens in an external repository (
>>>>> https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc)
>>>>> and we raise a PR against Apache owned repository (which can be created if
>>>>> needed once we are all onboard).
>>>>>
>>>>> What does everyone else think?
>>>>>
>>>>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob  wrote:
>>>>>
>>>>>> An external repository probably ends up requiring a software grant? I
>>>>>> know there is a material difference between code originating externally 
>>>>>> and
>>>>>> code originating within the umbrella of the ASF in terms of IP, 
>>>>>> copyright,
>>>>>> or other legal status.
>>>>>>
>>>>>>
>>>>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>
>>>>>>> If all we need now is a place to commit a PoC for now (and something
>>>>>>> like sandbox repo or contribs won't suffice), why can't we have a 
>>>>>>> separate
>>>>>>> repository in GitHub outside Apache and merge into an Apache repository
>>>>>>> only once the code takes reasonable shape?
>>>>>>>
>>>>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Thanks for the feedback, Mike.
>>>>>>>&g

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

David, this is about the Cross DC work that was supposed to be done :-)

The independent release cadence is primarily the reason why a new repo
makes sense to me in this case.

On Sat, Jan 9, 2021 at 1:24 PM David Smiley  wrote:

> While I like the idea of a single (Apache!) repo for multiple
> packages/plugins, that does not apply to the Solr Operator, which isn't
> even in Java.  It's too unique.  So I agree with Anshum & others about
> creating an Apache repo for the Solr Operator.
>
> I think the ship has sailed on the Solr Operator being an Apache project
> instead of some committer's pet project.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Fri, Jan 8, 2021 at 4:47 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Not necessarily. Most people contribute to Apache Lucene/Solr using
>> external repositories (forks) and raise pull requests against Apache owned
>> repositories. There's no SGA needed on such occasions.
>>
>> I see two paths forward from here.
>>
>> a) Lets setup a single repository for all packages/plugins, say
>> lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and
>> develop it there.
>> b) All development for this effort happens in an external repository (
>> https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc)
>> and we raise a PR against Apache owned repository (which can be created if
>> needed once we are all onboard).
>>
>> What does everyone else think?
>>
>> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob  wrote:
>>
>>> An external repository probably ends up requiring a software grant? I
>>> know there is a material difference between code originating externally and
>>> code originating within the umbrella of the ASF in terms of IP, copyright,
>>> or other legal status.
>>>
>>>
>>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
>>>> If all we need now is a place to commit a PoC for now (and something
>>>> like sandbox repo or contribs won't suffice), why can't we have a separate
>>>> repository in GitHub outside Apache and merge into an Apache repository
>>>> only once the code takes reasonable shape?
>>>>
>>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, 
>>>> wrote:
>>>>
>>>>> Thanks for the feedback, Mike.
>>>>>
>>>>> I like the idea of the sandbox, but that might be restricting when we
>>>>> want to work on more than one repos.
>>>>>
>>>>> I'm not sure if that would happen in the near future, but as we can
>>>>> always discard the repo and it doesn't really come at a cost, I don't see 
>>>>> a
>>>>> problem with having a repo created for this specific reason.
>>>>>
>>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob  wrote:
>>>>>
>>>>>> I'm not sure where I sit on this, going to start typing things and
>>>>>> then hopefully I'll reach a conclusion by the end.
>>>>>>
>>>>>> This definitely needs to be outside of the core solr repo so that it
>>>>>> can be versioned and released independently. And I disagree with Ishan
>>>>>> about the consequence of abandoning the repository - if we realize that
>>>>>> it's a bad direction then we can pivot, but we shouldn't let a fear of 
>>>>>> the
>>>>>> unknown stop us from doing it in the first place.
>>>>>>
>>>>>> However, if all we need right now is a place to commit code that is
>>>>>> WIP, then what we really want is a sandbox to play with, and not
>>>>>> necessarily a strongly directed repo. Lucene has a sandbox in the main
>>>>>> code. We could similarly start this under Solr contrib and move it out
>>>>>> before an actual release of 9x happens. Or maybe we start with a
>>>>>> [lucene-]solr-sandbox repository that we can throw all sorts of stuff 
>>>>>> into
>>>>>> and then when components are mature enough they get to graduate into 
>>>>>> their
>>>>>> own repo?
>>>>>>
>>>>>> Mike
>>>>>>
>>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta 
>>>>>> wrote:
>>>>>>
>>>>>>> I und

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

The problem with a single repository is that it will/may conflict at times.
Also, I still don't see the problem with having the extra repo as long as
we aren't releasing anything.

The problem with (b) is that you can't create a PR from a random repository
to a repo it isn't a fork of. I also don't think people should own code and
build outside of the ASF umbrella until things are ready to be released,
it's completely against the Apache Way. Having the code in the ASF umbrella
comes at no cost to the project. If at any point it needs to be dropped,
it's easier and cleaner as it wouldn't touch anything else.

Does this make sense?


On Fri, Jan 8, 2021 at 1:46 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> Not necessarily. Most people contribute to Apache Lucene/Solr using
> external repositories (forks) and raise pull requests against Apache owned
> repositories. There's no SGA needed on such occasions.
>
> I see two paths forward from here.
>
> a) Lets setup a single repository for all packages/plugins, say
> lucene-solr-extras or lucene-solr-contribs or lucene-solr-sandbox etc., and
> develop it there.
> b) All development for this effort happens in an external repository (
> https://github.com/apple/solr-dc or https://github.com/anshumg/solr-dc)
> and we raise a PR against Apache owned repository (which can be created if
> needed once we are all onboard).
>
> What does everyone else think?
>
> On Fri, Jan 8, 2021 at 10:23 AM Mike Drob  wrote:
>
>> An external repository probably ends up requiring a software grant? I
>> know there is a material difference between code originating externally and
>> code originating within the umbrella of the ASF in terms of IP, copyright,
>> or other legal status.
>>
>>
>> On Thu, Jan 7, 2021 at 8:11 PM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> If all we need now is a place to commit a PoC for now (and something
>>> like sandbox repo or contribs won't suffice), why can't we have a separate
>>> repository in GitHub outside Apache and merge into an Apache repository
>>> only once the code takes reasonable shape?
>>>
>>> On Fri, 8 Jan, 2021, 2:31 am Anshum Gupta, 
>>> wrote:
>>>
>>>> Thanks for the feedback, Mike.
>>>>
>>>> I like the idea of the sandbox, but that might be restricting when we
>>>> want to work on more than one repos.
>>>>
>>>> I'm not sure if that would happen in the near future, but as we can
>>>> always discard the repo and it doesn't really come at a cost, I don't see a
>>>> problem with having a repo created for this specific reason.
>>>>
>>>> On Thu, Jan 7, 2021 at 12:45 PM Mike Drob  wrote:
>>>>
>>>>> I'm not sure where I sit on this, going to start typing things and
>>>>> then hopefully I'll reach a conclusion by the end.
>>>>>
>>>>> This definitely needs to be outside of the core solr repo so that it
>>>>> can be versioned and released independently. And I disagree with Ishan
>>>>> about the consequence of abandoning the repository - if we realize that
>>>>> it's a bad direction then we can pivot, but we shouldn't let a fear of the
>>>>> unknown stop us from doing it in the first place.
>>>>>
>>>>> However, if all we need right now is a place to commit code that is
>>>>> WIP, then what we really want is a sandbox to play with, and not
>>>>> necessarily a strongly directed repo. Lucene has a sandbox in the main
>>>>> code. We could similarly start this under Solr contrib and move it out
>>>>> before an actual release of 9x happens. Or maybe we start with a
>>>>> [lucene-]solr-sandbox repository that we can throw all sorts of stuff into
>>>>> and then when components are mature enough they get to graduate into their
>>>>> own repo?
>>>>>
>>>>> Mike
>>>>>
>>>>> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta 
>>>>> wrote:
>>>>>
>>>>>> I understand your concern, but this is the placeholder for where the
>>>>>> code would be, not what the code would look like.
>>>>>>
>>>>>> Considering we agreed to do this in a repository outside of the core,
>>>>>> I believe this is a good place to start. The idea that the release 
>>>>>> cadence
>>>>>> for the cross-dc effort should be different from that of core is an
>>>>>> argumen

Re: 2021-01 Lucene/Solr Committer meeting

[Anshum Gupta]

Agree. That is what all of us intend to do, just that clubbing the
ref_branch discussion with this meeting will not leave us with the
bandwidth to discuss much else.

As Mike suggested, let's schedule another meeting to discuss specifically
the ref_branch and the intention around that.

On Thu, Jan 7, 2021 at 2:55 PM David Smiley  wrote:

> Can we plan a long overdue meeting to talk about nothing else but the
> so-called reference branch?  The topic isn't forbidden, but it'd take all
> the oxygen out of the room to try to talk about that and anything else in
> the same meeting.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Jan 7, 2021 at 2:15 PM Houston Putman 
> wrote:
>
>> 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
>>>>
>>>

-- 
Anshum Gupta

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

Thanks for the feedback, Mike.

I like the idea of the sandbox, but that might be restricting when we want
to work on more than one repos.

I'm not sure if that would happen in the near future, but as we can always
discard the repo and it doesn't really come at a cost, I don't see a
problem with having a repo created for this specific reason.

On Thu, Jan 7, 2021 at 12:45 PM Mike Drob  wrote:

> I'm not sure where I sit on this, going to start typing things and then
> hopefully I'll reach a conclusion by the end.
>
> This definitely needs to be outside of the core solr repo so that it can
> be versioned and released independently. And I disagree with Ishan about
> the consequence of abandoning the repository - if we realize that it's a
> bad direction then we can pivot, but we shouldn't let a fear of the unknown
> stop us from doing it in the first place.
>
> However, if all we need right now is a place to commit code that is WIP,
> then what we really want is a sandbox to play with, and not necessarily a
> strongly directed repo. Lucene has a sandbox in the main code. We could
> similarly start this under Solr contrib and move it out before an actual
> release of 9x happens. Or maybe we start with a [lucene-]solr-sandbox
> repository that we can throw all sorts of stuff into and then when
> components are mature enough they get to graduate into their own repo?
>
> Mike
>
> On Thu, Jan 7, 2021 at 2:32 PM Anshum Gupta 
> wrote:
>
>> I understand your concern, but this is the placeholder for where the code
>> would be, not what the code would look like.
>>
>> Considering we agreed to do this in a repository outside of the core, I
>> believe this is a good place to start. The idea that the release cadence
>> for the cross-dc effort should be different from that of core is an
>> argument in favor of this approach, but I'm happy to talk more about it.
>> I just thought that based on the original email, folks were on-board with
>> the idea of this being outside of core Solr artifact/release.
>>
>> On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <
>> ichattopadhy...@gmail.com> wrote:
>>
>>> -1 on this. Without finalizing on the shape of how the solution will
>>> look like, I don't think we should start a repository: it would be bad if
>>> we have to abandon the repository of our approach changes (say we want to
>>> keep it tightly integrated inside Solr).
>>>
>>> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, 
>>> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Inline with my earlier email, I'll be requesting a new repository to
>>>> host the cross-dc work. Please let me know if you have any questions or
>>>> concerns.
>>>>
>>>> *Repository name: *solr-crossdc
>>>> *Generated name:* lucene-solr-crossdc.git (that's auto-generated, so
>>>> can't remove the TLP prefix)
>>>> *Commit notification list:* commits-cros...@lucene.apache.org (I think
>>>> it makes sense for these commit notifications to go to a new list, but I'm
>>>> open to reusing the old one)
>>>> *GitHub notification list:* dev@lucene.apache.org
>>>>
>>>> I'll be submitting a request for the same later in the day today if
>>>> there are no concerns.
>>>>
>>>> --
>>>> Anshum Gupta
>>>>
>>>
>>
>> --
>> Anshum Gupta
>>
>

-- 
Anshum Gupta

Re: Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

I understand your concern, but this is the placeholder for where the code
would be, not what the code would look like.

Considering we agreed to do this in a repository outside of the core, I
believe this is a good place to start. The idea that the release cadence
for the cross-dc effort should be different from that of core is an
argument in favor of this approach, but I'm happy to talk more about it.
I just thought that based on the original email, folks were on-board with
the idea of this being outside of core Solr artifact/release.

On Thu, Jan 7, 2021 at 11:06 AM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> -1 on this. Without finalizing on the shape of how the solution will look
> like, I don't think we should start a repository: it would be bad if we
> have to abandon the repository of our approach changes (say we want to keep
> it tightly integrated inside Solr).
>
> On Thu, 7 Jan, 2021, 11:45 pm Anshum Gupta, 
> wrote:
>
>> Hi everyone,
>>
>> Inline with my earlier email, I'll be requesting a new repository to host
>> the cross-dc work. Please let me know if you have any questions or concerns.
>>
>> *Repository name: *solr-crossdc
>> *Generated name:* lucene-solr-crossdc.git (that's auto-generated, so
>> can't remove the TLP prefix)
>> *Commit notification list:* commits-cros...@lucene.apache.org (I think
>> it makes sense for these commit notifications to go to a new list, but I'm
>> open to reusing the old one)
>> *GitHub notification list:* dev@lucene.apache.org
>>
>> I'll be submitting a request for the same later in the day today if there
>> are no concerns.
>>
>> --
>> Anshum Gupta
>>
>

-- 
Anshum Gupta

Requesting a new GH repository for CrossDC modules

[Anshum Gupta]

Hi everyone,

Inline with my earlier email, I'll be requesting a new repository to host
the cross-dc work. Please let me know if you have any questions or concerns.

*Repository name: *solr-crossdc
*Generated name:* lucene-solr-crossdc.git (that's auto-generated, so can't
remove the TLP prefix)
*Commit notification list:* commits-cros...@lucene.apache.org (I think it
makes sense for these commit notifications to go to a new list, but I'm
open to reusing the old one)
*GitHub notification list:* dev@lucene.apache.org

I'll be submitting a request for the same later in the day today if there
are no concerns.

-- 
Anshum Gupta

Re: 2021-01 Lucene/Solr Committer meeting

[Anshum Gupta]

+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

2021-01 Lucene/Solr Committer meeting

[Anshum Gupta]

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

Re: Old programmers do fade away

[Anshum Gupta]

Hey Erick!

I'm really happy to hear that you have found something that interests you
even more than programming and open source. It's been great pleasure
working with you all this while.

Thank you for all your contributions and good luck with the welding
machine. I'm looking forward to seeing what you build and hope to see you
when things are safe and we are in the same city :)



On Wed, Dec 30, 2020 at 6:09 AM Erick Erickson 
wrote:

> 40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it
> really been that long? Programming's been fun, I've gotten to solve puzzles
> every day. The art and science of programming has changed over that time.
> Let me tell you about the joys of debugging with a Z80 stack emulator that
> required that you to look on the stack for variables and trace function
> calls by knowing how to follow frame pointers. Oh the tedium! Oh the (lack
> of) speed! Not to mention that 64K of memory was all you had to work with.
> I had a co-worker who could predict the number of bytes by which the
> program would shrink based on extracting common code to functions. The
> "good old days"...weren't...
>
> I'd been thinking that I'd treat Lucene/Solr as a hobby, doing occasional
> work on it when I was bored over long winter nights. I've discovered,
> though, that I've been increasingly reluctant to crack open the code. I
> guess that after this much time, I'm ready to hang up my spurs. One major
> factor is the realization that there's so much going on with Lucene/Solr
> that simply being aware of the changes, much less trying to really
> understand them, isn't something I can do casually.
>
> I bought a welder and find myself more interested in playing with that
> than programming. Wait until you see the squirrel-proof garden enclosure
> I'm building with it. If my initial plan doesn't work, next up is an
> electric fence along the top. The laser-sighted automatic machine gun
> emplacement will take more planning...Ahhh, probably won't be able to get a
> permit from the township for that though. Do you think the police would
> notice? Perhaps I should add that the local police station is two blocks
> away and in the line of fire. But an infrared laser powerful enough to
> "pre-cook" them wouldn't be as obvious would it?
>
> Why am I so fixated on squirrels? One of the joys of gardening is fresh
> tomatoes rather than those red things they sell in the store. The squirrels
> ATE EVERY ONE OF MY TOMATOES WHILE THEY WERE STILL GREEN LAST YEAR! And the
> melons. In the words of B. Bunny: "Of course you realize this means war" (
> https://www.youtube.com/watch?v=4XNr-BQgpd0)...
>
> Then there's working in the garden and landscaping, the desk I want to
> build for my wife, travel as soon as I can, maybe seeing if some sailboats
> need crew...you get the idea.
>
> It's been a privilege to work with this group, you're some of the best and
> brightest. Many thanks to all who've generously given me their time and
> guidance. It's been a constant source of amazement to me how willing people
> are to take time out of their own life and work to help me when I've had
> questions. I owe a lot of people beers ;)
>
> I'll be stopping my list subscriptions, Slack channels (dm me if you need
> something), un-assigning any JIRAs and that kind of thing over the next
> while. If anyone's interested in taking over the BadApple report, let me
> know and I can put the code up somewhere. It takes about 10 minutes to do
> each week. I won't disappear entirely, things like the code-reformatting
> effort are nicely self-contained for instance and something I can to
> casually.
>
> My e-mail address if you need to get in touch with me is: "
> erick.erick...@gmail.com". There's a correlation between gmail addresses
> that are just a name with no numbers and a person's age... A co-worker came
> over to my desk in pre-historical times and said "there's this new mail
> service you might want to sign up for"... Like I said, 40 years is enough.
>
> Best to all,
> Erick
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: [DISCUSS] Cross Data-Center Replication in Apache Solr

[Anshum Gupta]

Sorry, forgot to send this email. Here's a draft of the SIP. There are
still open questions that we shall handle as we go along and based on the
usage patterns that emerge from the community.

An important thing to note here is that we could provide users the option
to not have Solr forward the requests and instead just always just consume
from the queue. This would be useful for folks who can manage versioning
themselves, and don't need an actual hot-hot setup.

https://cwiki.apache.org/confluence/display/SOLR/SIP-13%3A+Cross+Data+Center+Replication


On Sun, Dec 6, 2020 at 9:18 PM Anshum Gupta  wrote:

> Thank you everyone for showing interest and sharing your thoughts.
>
> The overall approach I've been thinking about involves:
> 1. A consumer app that reads from a (local) message queue and writes to a
> local Solr instance.
> 2. Update Request Processor in Solr to forward the updates to an outgoing
> local queue.
>
> The messaging system in the middle will be responsible to handle the
> replication from the local source queue to remote destination queues that
> are local to the remote clusters. This will allow the individual clusters
> to be agnostic of the remote cluster location. I'll need a few more days
> before I share the document, but just wanted to give an idea about the data
> flow we've been using for a few years.
>
> As expected, there are a few caveats and restrictions with this approach
> which I'll include with the document :)
>
> -Anshum
>
> On Sun, Dec 6, 2020 at 1:53 PM Bram Van Dam  wrote:
>
>> We've had some experience with this. As per usual, customers tend to
>> want the holy grail: no data loss when one data centre blows up, but no
>> increased latency when updating data. This then somehow, magically, has
>> to work over a slow uplink between two data centres without saturating
>> the link.
>>
>> Currently we use NRT replicas across data centres. Which does add some
>> latency, but consistency is a bit more important for us. Overall, this
>> works pretty well.
>>
>> The biggest problems we've experienced have all been related to
>> recovering replicas across a slow data centre uplink. A saturated link
>> can cause multiple replicas to lag behind, and when this gets too bad,
>> they too will go into recovery, and then shit really hits the fan.
>>
>> I'm not sure whether there are any easy ways of improving that
>> behaviour. Limiting max bandwidth per solr instance during recovery?
>> Slow recovery is better than destructive recovery.
>>
>> External tools like Kafka add a lot of operational overhead. One of the
>> great things about SolrCloud is how simple the whole replication setup is.
>>
>>
>>
>> On 06/12/2020 14:46, Erick Erickson wrote:
>> >> I can see at least two different approaches here, your mention of
>> SolrJ seems to hint at the first one:
>> >> 1. Get the data as it comes from the client and fork it to local and
>> remote data centers,
>> >> 2. Create (an asynchronous) stream replicating local data center data
>> to remote.
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Anshum Gupta
>


-- 
Anshum Gupta

Re: [DISCUSS] Cross Data-Center Replication in Apache Solr

[Anshum Gupta]

Thank you everyone for showing interest and sharing your thoughts.

The overall approach I've been thinking about involves:
1. A consumer app that reads from a (local) message queue and writes to a
local Solr instance.
2. Update Request Processor in Solr to forward the updates to an outgoing
local queue.

The messaging system in the middle will be responsible to handle the
replication from the local source queue to remote destination queues that
are local to the remote clusters. This will allow the individual clusters
to be agnostic of the remote cluster location. I'll need a few more days
before I share the document, but just wanted to give an idea about the data
flow we've been using for a few years.

As expected, there are a few caveats and restrictions with this approach
which I'll include with the document :)

-Anshum

On Sun, Dec 6, 2020 at 1:53 PM Bram Van Dam  wrote:

> We've had some experience with this. As per usual, customers tend to
> want the holy grail: no data loss when one data centre blows up, but no
> increased latency when updating data. This then somehow, magically, has
> to work over a slow uplink between two data centres without saturating
> the link.
>
> Currently we use NRT replicas across data centres. Which does add some
> latency, but consistency is a bit more important for us. Overall, this
> works pretty well.
>
> The biggest problems we've experienced have all been related to
> recovering replicas across a slow data centre uplink. A saturated link
> can cause multiple replicas to lag behind, and when this gets too bad,
> they too will go into recovery, and then shit really hits the fan.
>
> I'm not sure whether there are any easy ways of improving that
> behaviour. Limiting max bandwidth per solr instance during recovery?
> Slow recovery is better than destructive recovery.
>
> External tools like Kafka add a lot of operational overhead. One of the
> great things about SolrCloud is how simple the whole replication setup is.
>
>
>
> On 06/12/2020 14:46, Erick Erickson wrote:
> >> I can see at least two different approaches here, your mention of SolrJ
> seems to hint at the first one:
> >> 1. Get the data as it comes from the client and fork it to local and
> remote data centers,
> >> 2. Create (an asynchronous) stream replicating local data center data
> to remote.
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: [Apache Solr] Twitter Account

[Anshum Gupta]

Yes, I agree that it should be more active, but that's not really an
official 'Apache' Solr account :)

I know at some point Shalin tried to find someone who would be up for it
and manage it, but considering we are all volunteering, it's tough to keep
up and he didn't get any volunteers.

As of now it's just a dormant account w.r.t. activity.

On Sat, Dec 5, 2020 at 2:40 AM Alessandro Benedetti 
wrote:

> Hi,
> I noticed the Apache Solr twitter account not to be that active anymore.
> There are not even a tweet - > release 1 to 1 matching.
> Not to mention the countless interesting blog posts Solr related, that
> could benefit the community if better shared.
>
> In my opinion, that's a shame, given the good number of followers the
> account has.
> Who's managing it?
>
> I understand that the management of that page must be unbiased, sharing
> interesting posts, without direct commercial purpose, given the fact many
> companies (including mine) make a living out of Apache Solr (but also give
> back to the community in form of blogs and contributions).
>
>
>
> Regards
>


-- 
Anshum Gupta

[DISCUSS] Cross Data-Center Replication in Apache Solr

[Anshum Gupta]

Hi everyone,


Large scale Solr installations often require cross data-center replication
in order to achieve data replication for both, access latency reasons as
well as disaster recovery. In the past users have either designed their own
solutions to deal with this or have tried to rely on the now-deprecated
CDCR.


It would be really good to have support for cross data-center replication
within Solr, that is offered and supported by the community. This would
allow the effort around this shared problem to converge.


I’d like to propose a new solution based on my experiences at my day job.
The key points about this approach:

   1. Uses an external, configurable, messaging system in the middle for
   actual replication/mirroring.
   2. We offer an abstraction and some default implementations based on
   what we can support and what users really want. An example here would be
   Kafka.
   3. This would be a separate repository allowing it to have its own
   release cadence. We shouldn’t have to release this with every Solr release
   as the overlap is just limited to SolrJ interactions.


I’ll share a more detailed and evolving document soon with the design for
everyone else to contribute to but wanted to share this as I’m starting to
work on this and wanted to avoid parallel efforts towards the same end-goal.

-- 
Anshum Gupta

Re: Welcome Houston Putman to the PMC

[Anshum Gupta]

Congratulations and welcome, Houston!

On Tue, Dec 1, 2020 at 1:19 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
>
>

-- 
Anshum Gupta

Re: Welcome Julie Tibshirani as Lucene/Solr committer

[Anshum Gupta]

Congratulations and welcome, Julie! :)

On Wed, Nov 18, 2020 at 7:07 AM Michael Sokolov  wrote:

> 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: <http://lucene.apache.org/whoweare.html>
>
> Congratulations and welcome!
>
> Mike Sokolov
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

-- 
Anshum Gupta

Re: [DISCUSS][SOLR] Multiple Repos For Contributions

[Anshum Gupta]

Thanks for sending this email, Mike and thanks for the follow up, David.

The idea of having multiple repos under the project seems like the
reasonable way to go for our project. This allows us to support more
features/tooling/etc. without having to link them to Solr or Lucene
releases.

An important thing here is to understand that if it comes from under the
same umbrella, it should be treated with the same care and respect - at
least we should attempt to.

Q: Is it "okay" to release new Solr versions that break any of these
> external contribs?  Knowingly or unknowingly -- does it matter?

I think it's really important to understand that breaking compat here
should be a well thought off thing, especially as that's the
differentiating factor for code that resides under the project vs. external
repos. It doesn't mean that compat breaks can't happen, it's just that
there would be more responsibility to providing a smooth upgrade path for
users in case of compat breaks.

>From my perspective, the code in the external repos here would be just like
the code in the core repo, just with a different release cadence.

Q: Would contribs be treated as first class citizens in the Solr Reference
> Guide (they are still in the ASF after all), or would they be banished like
> the DIH was?

The repos are supposed to grow, and with that, adding more to the current
ref guide would be just bad user experience. In addition, the different
release cadence would make it difficult to support documentation for the
code in these repos via the ref guide that would be released with the core.
We should certainly aim for the same quality of documentation, but not make
it to be a part of the ref guide.



On Sat, Nov 14, 2020 at 8:54 PM David Smiley  wrote:

> Thanks for shining a spotlight on this Mike.
> I have some questions to consider.  I'll call these additional repos,
> "external contribs", or just contribs for short here; perhaps our internal
> contribs would migrate.
>
> Q: Would each contrib be released at its own cadence unrelated to Solr?  I
> suppose so.
> Q: Would each contrib have it's own release vote?  I suppose so, as it has
> its own artifact.  I think the ASF requires this.
> Q: Is it "okay" to release new Solr versions that break any of these
> external contribs?  Knowingly or unknowingly -- does it matter?
> Q: What technical work is needed to extricate an internal contrib to an
> external?
> * source control history.  (note: i've done this git history in a single
> folder extraction before, with a popular Stackoverflow answer)
> * mandatory ASF files, e.g. license, notice
> * more files that we may want: CHANGES.txt
> * More build files; copying the rules/setup/standards of the Solr
> mothership and will become divergent over time no doubt.  Or just KISS
> principle; no sharing; simple Maven projects.
> Q: Could & should many contribs live in one repo (no more internal
> contribs), yet each still have its own release cycle?  This could make
> sharing build infrastructure easier, and detecting Solr compatibility with
> them easier.  Although it would mean sharing GitHub project area, thus
> sharing issues/PRs.
> Q: Should we create a separate JIRA for these contribs... or ditch JIRA
> entirely for them, relying on GitHub alone?
> Q: Would contribs be treated as first class citizens in the Solr Reference
> Guide (they are still in the ASF after all), or would they be banished like
> the DIH was?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Nov 12, 2020 at 6:40 PM Mike Drob  wrote:
>
>> Solr Devs,
>>
>> We've slowly been moving into a multi-repository model, and I wanted to
>> bring some more attention to it and have a more focused discussion. We've
>> recently embarked upon the acceptance of solr-operator as a distinct
>> repo[1] under the care of the Lucene (soon to be Solr) PMC. I expect that
>> there will be more cases of this as we transition additional contribs out
>> of core, or as more plugins, packages, and integrations mature. Some will
>> make sense as externally maintained code bases, but I believe other
>> contributions may benefit our community more as part of the Apache
>> Foundation.
>>
>> I think there was a very insightful comment[2] made by GP regarding
>> adopting a similar model to Apache Commons governance, bringing attention
>> to it here because I fear it may have gotten lost deep in the thread. Based
>> on observations of Commons and a few other Apache projects with multi-repo
>> setups, there thankfully does not appear to be a limit on how many
>> repositories a PMC can maintain. The size and scope of each individual
>> repository can vary greatly. I see potential ideas for anything that could
>> be standalone and not tied to a release cycle (Admin UI, DIH, etc...), or
>> anything that bridges integrations between Solr and other systems (k8s,
>> HDFS, etc...).
>>
>> The risks that new repos face are similar to the risks 

Re: [VOTE] Release Lucene/Solr 8.7.0 RC1

[Anshum Gupta]

Late to the party but

+1 (binding)

SUCCESS! [1:04:05.374710]

Tried basic indexing and search and everything seems to be working as
expected.

-Anshum



On Thu, Oct 29, 2020 at 9:54 PM 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
>
>

-- 
Anshum Gupta

Re: [DISCUSS] Solr Operator grant to Apache Lucene

[Anshum Gupta]

Thank you everyone for participating.

Seems like there are no objections to this moving forward. I'll move
forward with this donation.

On Fri, Oct 23, 2020 at 8:36 AM Houston Putman 
wrote:

> 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 <https://github.com/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.
>> &g

Re: [DISCUSS] Solr Operator grant to Apache Lucene

[Anshum Gupta]

This would be a new repo under apache/ in git. It would share the
committers and PMC members i.e. until the split of the project is complete,
it would belong to the current project and once the split is done, we would
move this over into the Solr project.
As I already mentioned in the earlier email, the release cadence of this
project would be different than core Solr, so as not to block the core
releases. This isn't a package but a standalone repo that has nothing to do
with a running Solr process.

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

The dependency is Solr <-- Solr-Docker <-- Solr-Operator. Once e.g. Solr
9.0 is out, the solr-operator may only support Solr8.x for some time.
Releasing a solr-operator version that supports solr 9.0, possibly with
support for migrating an existing cluster, or not depending on the goals of
the sub project would happen independently.

The operator will depend mostly on the Docker images produced by Solr. The
primary integration points are bin/solr and all its options / env vars and
the API. So unless Solr’s test base and release process allows someone to
break back compat when they’re doing a release, breaking the operator isn’t
that much of a concern. This is another reason we don’t want to rebuild the
Collection API in the operator.

On Fri, Oct 23, 2020 at 6: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 th

[DISCUSS] Solr Operator grant to Apache Lucene

[Anshum Gupta]

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, a
separate repository will allow us to keep things easy to manage.

Q: What about the operator release cadence?
A: The operator and Lucene/Solr would have independent release cadence.

We would like to give the community a week i.e. until 30th of October, 2020
to discuss this so the PMC can make an informed decision.

Looking forward to a healthy discussion.

[1] https://github.com/bloomberg/solr-operator

-- 
Anshum Gupta

Re: Communicating the future of DIH?

[Anshum Gupta]

I think that the fact that this code is no longer under the Apache umbrella
will lead to such issues and moving this into a different GitHub org
wouldn't really help with the problem that's been highlighted. Also, the
maintainers of a plugin should be people who understand and monitor the
project and if those rights are opened up, it'd be hard to maintain
reliability of the plugin.

Thanks for updating the Ref Guide, Cassandra :) In line with my suggestion
above, I think we need to be clear with the messaging of the fact that the
code no longer is owned and maintained by the Apache Lucene/Solr community
and any vulnerability or bug reported in the 3rd party packages wouldn't be
the responsibility of the Apache Lucene community.


On Thu, Oct 15, 2020 at 2:16 PM Cassandra Targett 
wrote:

> I updated the Ref Guide for 8.7 to include a link to the plugin repo (for
> all plugins which have an established repo, not just DIH), hoping that
> would help answer user questions and spur adoption. That’s just a
> super-minor thing, but it’s something.
>
> If Rohit doesn’t have time to be a maintainer now and no one else wants to
> be, would a separate GitHub org help that? I understand the motivation for
> sharing the burden…I guess you’re thinking that single org would allow
> people to be maintainers on multiple plugins?
>
> Draft for 8.7 Guide is here if interested to see what I did:
> https://nightlies.apache.org/Lucene/Solr-reference-guide-8.x/uploading-structured-data-store-data-with-the-data-import-handler.html
> On Oct 15, 2020, 3:52 PM -0500, Jan Høydahl ,
> wrote:
>
> Some of those issues are opened by me, not beause I plan to be a DIH
> maintainer myself, but I was hoping that Rohit had some real interest in
> forming a comunity.
> Turns out that the plugin is as good as dead on arrival, which is really
> disappointing.
>
> We as the donator could perhaps help by sending an email, with a reminder
> that DIH is being deprecated and that the new plugin really needs more
> maintainers.
> That’s why I filed
> https://github.com/rohitbemax/dataimporthandler/issues/12, else people
> arriving to the page would not even know how to contribute or become a
> committer.
> I could whip up a PR for the README inviting contributors, but I’m
> honestly not so sure that newcomers would feel welcome, as their
> contributions would likely attract no attention :(
>
> So I wonder if instead someone (Ishan?) should setup a new GitHub
> organization, migrate the project there, and add Rohit and others as
> maintainers. That lifts the burden off one man's shoulders.
>
> Jan
>
> a15. okt. 2020 kl. 21:40 skrev Marcus Eagan :
>
> There’s always issues opened in every product that aren’t being closed.
> Everyone who knows it or cares about it should be pitching in.
>
> Marcus
>
> On Thu, Oct 15, 2020 at 12:21 Eric Pugh 
> wrote:
>
>> I noticed that we’re getting tickets like SOLR-14938 opened that are all
>> about the future of DIH.  I know some of my own clients are asking about it
>> as well.   I suspect we will get more and more of these!
>>
>> I wonder if there are any ideas/suggestions on how to better communicate
>> that DIH isn’t going away, and indeed, it’s moving to a better place (I
>> hope!).   Do we want to add to the UI a message about “join the new
>> community at https://github.com/rohitbemax/dataimporthandler”?
>>
>> Having said that, I see issues opening at
>> https://github.com/rohitbemax/dataimporthandler and not being closed, so
>> I do have some concerns that a supportive community may not actually be
>> forming.
>>
>>
>> Eric
>>
>> ___
>> *Eric Pugh **| *Founder & CEO | OpenSource Connections, LLC | 434.466.1467
>> | http://www.opensourceconnections.com | My Free/Busy
>> <http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> 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.
>>
>> --
> Marcus Eagan
>
>
>

-- 
Anshum Gupta