Re: [HELP] Link your Apache Lucene Jira and GitHub account ids before Thursday August 4 midnight (in your local time)

[Atri Sharma]

Mine is atris for github, atri for JIRA

On Mon, Aug 1, 2022 at 4:03 PM Tomoko Uchida
 wrote:
>
> Hi Mike, Marcus, and Praveen:
>
> I verified the added two mappings - these Jira users have activity on
> Lucene Jira, also corresponding GitHub accounts are valid.
> - marcussorealheis
> - pru30
>
> Tomoko
>
>
> 2022年8月1日(月) 18:40 Michael McCandless :
>
> > Thanks Praveen,
> >
> > I added your mapping here:
> > https://github.com/apache/lucene-jira-archive/commit/765fec2a19063e97c3d3de0a3528c16ba602b0bf
> >
> > Please verify!
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Mon, Aug 1, 2022 at 4:48 AM Praveen Nishchal 
> > wrote:
> >
> >> Hi Mike,
> >>
> >> Please find details
> >>
> >> JiraName,GitHubAccount,JiraDispName
> >> pru30,https://github.com/praveennish,Praveen Nishchal
> >>
> >>
> >> On Sun, Jul 31, 2022 at 3:38 PM Michael McCandless <
> >> luc...@mikemccandless.com> wrote:
> >>
> >>> Hello Lucene users, contributors and developers,
> >>>
> >>> If you have used Lucene's Jira and you have a GitHub account as well,
> >>> please check whether your user id mapping is in this file:
> >>> https://github.com/apache/lucene-jira-archive/blob/main/migration/mappings-data/account-map.csv.20220722.verified
> >>>
> >>> If not, please reply to this email and we will try to add you.
> >>>
> >>> Please forward this email to anyone you know might be impacted and who
> >>> might not be tracking the Lucene lists.
> >>>
> >>>
> >>> Full details:
> >>>
> >>> The Lucene project will soon migrate from Jira to GitHub for issue
> >>> tracking.
> >>>
> >>> There have been discussions, votes, a migration tool created / iterated
> >>> (thanks to Tomoko Uchida's incredibly hard work), all iterating on 
> >>> Lucene's
> >>> dev list.
> >>>
> >>> When we run the migration, we would like to map Jira users to the right
> >>> GitHub users to properly @-mention the right person and make it easier for
> >>> you to find issues you have engaged with.
> >>>
> >>> Mike McCandless
> >>>
> >>> http://blog.mikemccandless.com
> >>>
> >>

-- 
Regards,

Atri
Apache Concerted

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

Re: exposing per-field storage usage

[Atri Sharma]

+1

Will really help with visibility.

On Tue, 14 Jun 2022, 00:56 Nhat Nguyen, 
wrote:

> Hi Michael,
>
> We developed a similar functionality in Elasticsearch. The DiskUsage API
>  estimates the
> storage of each field by iterating its structures (i.e., inverted index,
> doc-values, stored fields, etc.) and tracking the number of read-bytes. The
> result is pretty fast and accurate.
>
> I am +1 to the proposal.
>
> Thanks,
> Nhat
>
> On Mon, Jun 13, 2022 at 1:22 PM Michael Sokolov 
> wrote:
>
>> At Amazon, we have a need to produce regular metrics on how much disk
>> storage is consumed by each field. We manage an index with data
>> contributed by many teams and business units and we are often asked to
>> produce reports attributing index storage usage to these customers.
>> The best tool we have for this today is based on a custom Codec that
>> separates storage by field; to get the statistics we read an existing
>> index and write it out using AddIndexes and force-merging, using the
>> custom codec. This is time-consuming and inefficient and tends not to
>> get done.
>>
>> I wonder if it would make sense to add methods to *some* API that
>> would expose a per-field disk space metric? If we don't want to add to
>> IndexReader, which would imply lots of intermediate methods and API
>> additions, maybe we could make it be computed by CheckIndex?
>>
>> (implementation note: For the current formats, the information for
>> each field is always segregated by field, I think. I suppose that in
>> theory we might want to have some shared data structure across fields
>> some day, but it seems like an edge case that we could handle in some
>> exceptional way.)
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

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

[Atri Sharma]

+1(pmc)

On Tue, 7 Jun 2022, 18:04 Michael McCandless, 
wrote:

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

Re: [VOTE] Release Lucene/Solr 8.11.1 RC1

[Atri Sharma]

+1

SUCCESS! [1:07:35.83944]

On Thu, Dec 16, 2021 at 1:28 PM Jan Høydahl  wrote:
>
> Thanks all, I'll close the vote now and start publishing the release...
>
> If you're a PMC member who planned to vote, but have not yet done so, there 
> is still value in expressing your vote in this thread, further validating the 
> release. I'll tally the final count tomorrow as well, for the record.
>
> Jan
>
> 16. des. 2021 kl. 01:39 skrev Mike Drob :
>
> Fast track please
>
> On Wed, Dec 15, 2021 at 6:34 PM Gus Heck  wrote:
>>
>> fast track please :)
>>
>> On Wed, Dec 15, 2021 at 7:23 PM Anshum Gupta  wrote:
>>>
>>> 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 
 :

 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
>>
>>
>>
>> --
>> http://www.needhamsoftware.com (work)
>> http://www.the111shift.com (play)
>
>


-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene 9.0.0 RC4

[Atri Sharma]

+1


SUCCESS! [0:17:34.54939]

On Wed, Dec 1, 2021 at 10:27 PM 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
>


-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene 9.0.0 RC3

[Atri Sharma]

+1 SUCCESS! [0:22:43.58483]

On Sat, Nov 27, 2021 at 8:30 PM Robert Muir  wrote:
>
> +1
>
> (with --test-java17)
> SUCCESS! [0:26:01.193203]
>
> On Sat, Nov 27, 2021 at 8:40 AM Michael McCandless
>  wrote:
> >
> > +1
> >
> > SUCCESS! [0:06:46.020662]
> >
> > What a crazy speedup to smoke tester!!
> >
> >
> >
> > Mike McCandless
> >
> > http://blog.mikemccandless.com
> >
> >
> > On Sat, Nov 27, 2021 at 3:42 AM Ignacio Vera  wrote:
> >>
> >> +1
> >>
> >> SUCCESS! [0:17:28.435474]
> >>
> >>
> >> On Sat, Nov 27, 2021 at 1:27 AM Jan Høydahl  wrote:
> >>>
> >>> +1 SUCCESS! [0:23:41.775448]
> >>>
> >>> Only ran smoketester this time.
> >>>
> >>> Jan
> >>>
> >>> > 26. nov. 2021 kl. 15:31 skrev Adrien Grand :
> >>> >
> >>> > Please vote for release candidate 3 for Lucene 9.0.0.
> >>> >
> >>> > The artifacts can be downloaded from:
> >>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >>> >
> >>> > You can run the smoke tester directly with this command:
> >>> >
> >>> > python3 -u dev-tools/scripts/smokeTestRelease.py \
> >>> > https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC3-rev-1ddce848cf3d5067efcafc6569d5f8203e56af0b
> >>> >
> >>> > The vote will be open until 2021-11-30 9:00 UTC.
> >>> >
> >>> > [ ] +1  approve
> >>> > [ ] +0  no opinion
> >>> > [ ] -1  disapprove (and reason why)
> >>> >
> >>> > Here is my +1.
> >>> >
> >>> > --
> >>> > Adrien
> >>> >
> >>> > -
> >>> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >>> >
> >>>
> >>>
> >>> -
> >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >>> For additional commands, e-mail: dev-h...@lucene.apache.org
> >>>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene 9.0.0 RC2

[Atri Sharma]

+1

SUCCESS! [0:21:35.63292]

On Tue, Nov 23, 2021 at 2:10 PM Adrien Grand  wrote:
>
> Please vote for release candidate 2 for Lucene 9.0.0
>
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC2-rev-95072f3b71e67e308d71a6149323bf7dd04c8f75
>
> You can run the smoke tester directly with this command:
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/lucene/lucene-9.0.0-RC2-rev-95072f3b71e67e308d71a6149323bf7dd04c8f75
>
> The vote will be open until 2021-11-26 09:00 UTC.
>
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
>
> Here is my +1
>
> --
> Adrien
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Regards,

Atri
Apache Concerted

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

Re: What should we do of branch_8x?

[Atri Sharma]

+1, agree with Uwe.

On Mon, Nov 22, 2021 at 12:39 PM Ishan Chattopadhyaya
 wrote:
>
> +1 to Uwe's suggestion
>
> On Mon, 22 Nov, 2021, 11:13 am Gus Heck,  wrote:
>>
>> +1 to uwe's suggestion
>>
>> On Sun, Nov 21, 2021 at 10:42 PM Noble Paul  wrote:
>>>
>>> I think this is a reasonable suggestion Uwe.
>>>
>>> - We don't need to bring Gradle to 8.x
>>> - We can release 8.12 from a fork of 8.11.
>>> - we don't need to keep the Lucene source files in that branch. We can nuke 
>>> it and just keep the Lucene binaries
>>>
>>> On Mon, Nov 22, 2021, 8:49 AM Uwe Schindler  wrote:

 Hi,

 If this is really needed, I'd propose the following:

 - fork the branch_8_11 to solr's repo
 - delete all subdirectories below lucene, keep common-build and other 
 stuff.
 - add a single ivy.xml there that refers to all lucene jars of 8.11.x 
 (latest)
 - adapt solr's "copy-lucene-jars" ant task to copy the ivy output dir
 - delete the lucene stuff from release wizard.

 This is quick and easy. Adapting Gradle for a minor release is too hard.

 Am 21. November 2021 21:34:40 UTC schrieb Noble Paul 
 :
>
> All Solr users using 8x and they will need some time to get comfortable 
> with 9x . So, there is a good chance we may need to release an 8.12 based 
> on Lucene 8.11
>
> On Mon, Nov 22, 2021, 8:22 AM Adrien Grand  wrote:
>>
>> +1 to making branch_8x read-only as Uwe suggested
>>
>> I think Uwe's other point is also important: if we ever wanted to do a 
>> Solr 8.12, it'd probably be a better option to fork the 8.11 branch than 
>> to try to reuse branch_8x. So we don't need to tie the decision about 
>> what we want to do with branch_8x with future plans around an 8.12 
>> release?
>>
>> On Sun, Nov 21, 2021 at 7:48 PM Uwe Schindler  wrote:
>>>
>>> This is of course all possible, but: WHY the heck do this?
>>>
>>>
>>>
>>> Lucene 9.0 will come out likely very soon. After that just update the 
>>> gradle file of Solr main and remove the temporary repository (better 
>>> comment it out). After that adapt some changes and release Solr 9.0.
>>>
>>>
>>>
>>> From that point on both projects have a clear split point and everybody 
>>> can make sure that the backwards compatibility is handled according to 
>>> project’s needs.
>>>
>>>
>>>
>>> If the Solr 9.0 release is a intermediary point (not all deprecations 
>>> removed), release Solr 10.0 four months later, who cares? Solr 9.0 will 
>>> be the release with many new features and Java 11 as minimum 
>>> requirement.
>>>
>>>
>>>
>>> I would really, really not start and fuck up the release process for 
>>> 8.x! Why not release 8.11.1 soon, if you have any changes in Solr to 
>>> do? Why do this release needs to be called 8.12? It is just a version 
>>> number, so why the heck this big issues? I won’t think that Solr will 
>>> add any major features before Solr 9. So what is your exact problem?
>>>
>>>
>>>
>>> Sorry, but this discussion is complete nonsense. Its just version 
>>> numbers and some hick-hack between two parties that disagree. Keep calm 
>>> and don’t try to make it overcomplicated!
>>>
>>>
>>>
>>> I never said that we should kill or delete branch_8x. It can stay there 
>>> forever. I just suggested to make it read-only and add a note. Unless 
>>> there’s really a need to do some 8.12 release (in which case, I’d fork 
>>> 8.11 branch and move Lucene) I see no reason to act and fuck up the 
>>> repositories of both projects which have now a very clear state.
>>>
>>>
>>>
>>> Uwe
>>>
>>>
>>>
>>> -
>>>
>>> Uwe Schindler
>>>
>>> Achterdiek 19, D-28357 Bremen
>>>
>>> https://www.thetaphi.de
>>>
>>> eMail: u...@thetaphi.de
>>>
>>>
>>>
>>> From: Gus Heck 
>>> Sent: Sunday, November 21, 2021 5:05 PM
>>> To: dev 
>>> Subject: Re: What should we do of branch_8x?
>>>
>>>
>>>
>>> Release of Solr 8.12 It should require the current lucene-solr 8.x 
>>> branch to remove the lucene bits and declare a dependency on lucene 
>>> 8.11 lucene, that bit shouldn't be too hard if done soon... and the 
>>> release process for 8.x would not publish a lucene artifact which is 
>>> likely the harder bit. I think the option should be open assuming 
>>> someone is willing to do that work.What should not be an option is any 
>>> further lucene releases on 8.x  and I'd be very leery of any attempt to 
>>> consume lucene 9.0 on Solr 8.x
>>>
>>>
>>>
>>> The Lucene guarantees are irrelevant unless someone contemplates 
>>> releasing an 8.12 lucene, and I really think that would require a 
>>> positive vote from the Lucene PMC (which sounds very 

Re: What should we do of branch_8x?

[Atri Sharma]

+1, let's leave the option of the possibility

On Sun, 21 Nov 2021, 00:18 David Smiley,  wrote:

> +1 to “leave the door open” despite it seeming an awkward endeavor.
>
>
>
> On Sat, Nov 20, 2021 at 1:15 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> Since there is no concrete design available for that as of today, that's
>> why I mentioned about "keeping the door open" for 8.12. I'm not proposing a
>> 8.12 today, nor am I saying 8.12 is needed. But, in case we need one, we
>> should have the ability to release it. Anyway, this discussion should
>> rather happen on the Solr list.
>>
>> On Sat, 20 Nov, 2021, 10:10 pm Timothy Potter, 
>> wrote:
>>
>>> A Solr 8.12 with Lucene 8.11? Not sure of the details on that but
>>> sounds like a giant mess waiting to happen (at the very least, would
>>> require a bunch of complicated changes to the release process). We
>>> need to stop adding features to 8x and focus on 9. I can foresee an
>>> 8.11.2 with bug fixes only (8.11.1 is already planned to drop
>>> soon'ish). Why would Solr need an 8.12? I suspect it's related to
>>> upgrading plugins, but that's been an open issue for a long while and
>>> seems to keep getting pushed out. We can't just keep planning new
>>> feature releases because of this plugin upgrade problem. If we really
>>> need an 8.12, then we need to see a concrete design on how the upgrade
>>> process will work in an 8.12. Perhaps there's a better approach that
>>> only relies on code changes to the 9x line? Tough to say, we have no
>>> designs or descriptions of the upgrade problem at this point.
>>>
>>> As of today, I'd be strongly against a Solr 8.12 release.
>>>
>>> Tim
>>>
>>> On Sat, Nov 20, 2021 at 8:32 AM Ishan Chattopadhyaya
>>>  wrote:
>>> >
>>> > I think we should keep the door open for a 8.12 release of Solr (based
>>> on 8.11 Lucene). This might mean some split in the codebase, and this can
>>> either happen in the lucene-solr repo or the solr repo (I'm okay with
>>> either).
>>> >
>>> > On Sat, Nov 20, 2021 at 7:59 PM Adrien Grand 
>>> wrote:
>>> >>
>>> >> Uwe brought up the question on a the vote thread: we are not going to
>>> do a 8.12 release, so what should we do of branch_8x?
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>> --
> Sent from Gmail Mobile
>

Re: [VOTE] Release Lucene/Solr 8.11.0 RC1

[Atri Sharma]

+1 SUCCESS! [1:06:45.039403]

On Wed, Nov 10, 2021 at 2:02 PM Ignacio Vera  wrote:
>
> +1
>
> SUCCESS! [1:03:16.453882]
>
> On Wed, Nov 10, 2021 at 5:31 AM Gus Heck  wrote:
>>
>> +1 SUCCESS! [0:54:16.982080]
>>
>> On Tue, Nov 9, 2021 at 9:06 PM Mayya Sharipova 
>>  wrote:
>>>
>>> +1 SUCCESS! [1:09:47.023515]
>>>
>>> On Tue, Nov 9, 2021 at 6:42 PM Timothy Potter  wrote:

 totally unofficial, but I posted a Docker image for testing 8.11.0 RC1
 on K8s here: thelabdude/apache-solr-dev:8.11.0-rc1

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

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

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

-- 
Regards,

Atri
Apache Concerted

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

Re: Lucene 9.0 release

[Atri Sharma]

+1

On Fri, Oct 29, 2021 at 9:30 PM Adrien Grand  wrote:
>
> Hearing no objections, I will be moving forward with the plan I outlined 
> above. Next Monday is a holiday in France so I'll actually be cutting 
> branch_8_11, branch_9x and branch_9_0 on Tuesday.
>
> On Sun, Oct 17, 2021 at 3:40 PM Michael Sokolov  wrote:
>>
>> > 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.
>>
>> Thanks, that would be very welcome!
>>
>> On Fri, Oct 15, 2021 at 1:33 PM Timothy Potter  wrote:
>> >
>> > Sounds like a good plan Adrien, thanks for nailing down some concrete
>> > milestones and dates :-)
>> >
>> > Cheers,
>> > Tim
>> >
>> > On Fri, Oct 15, 2021 at 7:04 AM David Smiley  wrote:
>> > >
>> > > +1 Adrien.  Thanks for moving things along.
>> > >
>> > > ~ David Smiley
>> > > Apache Lucene/Solr Search Developer
>> > > http://www.linkedin.com/in/davidwsmiley
>> > >
>> > >
>> > > On Fri, Oct 15, 2021 at 3:30 AM Adrien Grand  wrote:
>> > >>
>> > >> For visibility, I recently opened a new issue about a case of index 
>> > >> corruption 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 

Re: [VOTE] Release Lucene/Solr 8.10.1 RC1

[Atri Sharma]

+1

SUCCESS! [1:28:35.594227]

On Fri, Oct 15, 2021 at 9:48 PM Michael Sokolov  wrote:
>
> +1 SUCCESS! [1:11:55.023477]
>
> I blame some random antivirus or something kicking in at the same time
>
> On Fri, Oct 15, 2021 at 10:44 AM Michael Sokolov  wrote:
> >
> > having a little trouble here with new laptop - after installing jdk8,
> > ant, and finally running the smoke tester - my laptop shut down due to
> > overheating! A little afraid to try it again, but I'll try improving
> > the air circulation ...
> >
> > On Thu, Oct 14, 2021 at 2:53 PM Namgyu Kim  wrote:
> > >
> > > +1 SUCCESS! [1:00:57.143976]
> > >
> > > On Fri, Oct 15, 2021 at 1:05 AM Houston Putman  wrote:
> > >>
> > >> +1 SUCCESS! [1:05:55.854939]
> > >>
> > >> On Thu, Oct 14, 2021 at 9:29 AM Michael Gibney 
> > >>  wrote:
> > >>>
> > >>> +1 SUCCESS! [1:00:31.099832]
> > >>>
> > >>> On Thu, Oct 14, 2021 at 7:42 AM Ignacio Vera  wrote:
> > 
> >  +1
> > 
> >  SUCCESS! [1:01:50.808390]
> > 
> > 
> >  On Thu, Oct 14, 2021 at 1:40 PM Michael McCandless 
> >   wrote:
> > >
> > > +1
> > >
> > >
> > > SUCCESS! [0:44:35.590557]
> > >
> > >
> > > Mike McCandless
> > >
> > > http://blog.mikemccandless.com
> > >
> > >
> > > On Tue, Oct 12, 2021 at 8:00 PM Mayya Sharipova  
> > > wrote:
> > >>
> > >> Please vote for release candidate 1 for Lucene/Solr 8.10.1
> > >>
> > >> The artifacts can be downloaded from:
> > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.1-RC1-rev2f24e6a49d48a032df1f12e146612f59141727a9
> > >>
> > >> You can run the smoke tester directly with this command:
> > >>
> > >> python3 -u dev-tools/scripts/smokeTestRelease.py \
> > >> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.10.1-RC1-rev2f24e6a49d48a032df1f12e146612f59141727a9
> > >>
> > >> The vote will be open for at least 72 hours i.e. until 2021-10-15 
> > >> 23:00 UTC.
> > >>
> > >> [ ] +1  approve
> > >> [ ] +0  no opinion
> > >> [ ] -1  disapprove (and reason why)
> > >>
> > >> Here is my +1 : SUCCESS! [1:07:19.906103]
> > >> 
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Regards,

Atri
Apache Concerted

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

Re: Welcome Michael Gibney as Lucene committer

[Atri Sharma]

Welcome, Michael!

On Thu, 7 Oct 2021, 23:29 Michael Sokolov,  wrote:

> Welcome, Michael!
>
> On Wed, Oct 6, 2021 at 9:34 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
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

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

[Atri Sharma]

That test rarely fails - hence warrants an investigation IMO

On Wed, 22 Sep 2021, 03:01 Timothy Potter,  wrote:

> Just an update here ... I'm still trying to get an RC built but the
> test suite continues to fail with flaky tests, this past run it was:
> org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming,
> which doesn't look like it fails all that much, see:
>
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming
>
>
> On Mon, Sep 20, 2021 at 3:14 PM Mike Drob  wrote:
> >
> > That was a bad backport from main, and I was mainly paying attention to
> the main jenkins tests. Apologies about that oversight. Please see PR
> https://github.com/apache/lucene-solr/pull/2578
> >
> > On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler  wrote:
> >>
> >> Hi,
> >>
> >> This test also fails on Jenkins all the time. In all branches and on
> all platforms. All the time, it's definitely a regression.
> >>
> >> Uwe
> >>
> >> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter <
> thelabd...@gmail.com>:
> >>>
> >>> Started building the RC1 again today and the smoke tester failed. The
> >>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> Re-ran that test from the RC checkout and it failed again:
> >>>
> >>>[junit4]   2> 5490 ERROR
> >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
> >>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED:
> >>>
> facet.query=*:*={!key%3DmultiSelect+ex%3Dt}*:*={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"=true=xml
> >>>[junit4]   2> 5491 INFO
> >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [
> >>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering
> >>>[junit4]   2> NOTE: reproduce with: ant test
> >>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering
> >>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true
> >>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true
> >>> -Dtests.file.encoding=US-ASCII
> >>>[junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<<
> >>>[junit4]> Throwable #1: java.lang.AssertionError: should have
> unwrapped
> >>>[junit4]> at
> >>>
> __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367)
> >>>[junit4]> at
> >>>
> org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368)
> >>>[junit4]> at
> >>>
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216)
> >>>[junit4]> at
> org.apache.solr.core.SolrCore.execute(SolrCore.java:2637)
> >>>
> >>> Looking at the stats for this test, it seems like it started failing
> >>> more consistently over the past week or so:
> >>>
> http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> I beasted it and 3/10 failed:
> >>>
> >>>   [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out
> of 10):
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>   [beaster]   -
> org.apache.solr.search.TestFiltering.testRandomFiltering
> >>>
> >>> I could just mark it as a BadApple and move on, but wanted to see if
> >>> anyone had any ideas about this test flakiness?
> >>>
> >>> Cheers,
> >>> Tim
> >>>
> >>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob  wrote:
> 
> 
>   Can we move discussion about the implementation to the JIRA issue or
> the PR?
> 
>   I'm not a lawyer, so not playing with the GPL fire is the easiest
> way for me to avoid getting burned. The regex I have is pretty
> straightforward, I do not feel like it is a great cause for alarm.
> 
>   On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
> >
> >
> >  Given that we don't ship the code or binaries that involve that
> python library, do we need to care about the license? I'm skeptical of hand
> rolled regex and would rather favour either of the libraries Jan 

Re: SOLR AWS S3 Connector

[Atri Sharma]

This is the Lucene developers' mailing list. Please use the Solr
users' mailing list for such questions.

On Tue, Aug 31, 2021 at 12:54 PM (Alex) Gainingam Phaomei
 wrote:
>
> Dear Solr Dev team,
>
>
>
> Thank you for making a wonderful product. Kudos to the team!
>
>
>
> Would appreciate a little help… is there a documentation for SOLR AWS S3 
> connector, such as Open source, Github fork?
>
>
>
> Thank you,
>
> Alex

-- 
Regards,

Atri
Apache Concerted

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

Re: Welcome Mayya Sharipova to the Lucene PMC

[Atri Sharma]

Congratulations!!

On Mon, 28 Jun 2021, 18:47 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
>
>

Re: Boolean Scorer

[Atri Sharma]

TBH, the proposal sound like an overkill to me - IndexSearcher's
concurrency should be good enough (unless you are searching a single large
segment)

On Mon, 21 Jun 2021, 19:04 Adrien Grand,  wrote:

> It should be possible to make something like this work. The main issue is
> that Lucene has the expectation that a (Bulk)Scorer is consumed in the
> thread where it was pulled, so this would require substantial changes to
> how BooleanScorer currently operates I believe.
>
> I'd be curious to know why you are looking into this rather than passing
> an Executor to IndexSearcher so that it can search segments concurrently.
> Is it not providing enough concurrency for you?
>
> On Mon, Jun 21, 2021 at 9:46 AM Arihant Samar  wrote:
>
>> Hi,
>> There is a function "ScoreWindowIntoBitSetAndReplay" in
>> "BooleanScorer.java" which runs over all the scorers.
>> I was wondering if we can use multi-threading here with numScorers
>> threads. Anyways we are using a special OrCollector here which updates the
>> matching array and the score in the buckets of 2048 docs. So we can use a
>> Reentrant lock for synchronization in the collector.
>>
>> I just wanted reviews on this since I tried this and some tests were not
>> passing. So if you could tell what is wrong in this approach, I
>> would appreciate it.
>>
>> Thanking You in advance,
>> Arihant.
>>
>> On Tue, 15 Jun 2021, 19:05 Adrien Grand,  wrote:
>>
>>> Glad it helped. :)
>>>
>>> On Tue, Jun 15, 2021 at 3:28 PM Greg Miller  wrote:
>>>
 Thanks for this explanation Adrien! I'd been wondering about this a bit
 myself since seeing that DrillSideways also implements a TAAT approach (in
 addition to a doc-at-a-time approach). This really helps clear that up.
 Appreciate you taking the time to explain!

 Cheers,
 -Greg

 On Mon, Jun 14, 2021 at 2:35 AM Adrien Grand  wrote:

> Hello Arihant,
>
> The Scorer for disjunctions uses a heap data structure that needs to
> be reordered upon every hit. While reordering heaps is efficient as it 
> runs
> in logarithmic time, the fact that it needs to run on every document might
> add non-negligible overhead. BooleanScorer tries to work around this
> overhead by scoring large windows of documents in a more TAAT
> (term-at-a-time) fashion so that Lucene only needs to reorder the heap
> every 2048 doc IDs (the hardcoded window size).
>
> This paper gives a bit more context:
> http://www.savar.se/media/1181/space_optimizations_for_total_ranking.pdf,
> see section 4 in particular.
>
> On Sat, Jun 12, 2021 at 5:47 PM Arihant Samar 
> wrote:
>
>> Hi ,
>>
>> I am new here . I would like to know what is the exact optimisation
>> carried out in “Boolean Scorer.java” code which led to a separate class 
>> for
>> resolving Boolean Queries in bulk documents. I could not find any 
>> material
>> in the documentation for this as well, hence I decided to ask here.
>>
>>
>> Thanking you in advance,
>>
>> Arihant.
>>
>>
>>
>> Sent from Mail  for
>> Windows 10
>>
>>
>>
>
>
> --
> Adrien
>

>>>
>>> --
>>> Adrien
>>>
>>
>
> --
> Adrien
>

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Atri Sharma]

+1 SUCCESS! [1:32:12.04043]

On Tue, Jun 15, 2021 at 8:27 PM Adrien Grand  wrote:
>
> +1 SUCCESS! [1:36:12.056443]
>
> On Tue, Jun 15, 2021 at 4:26 PM Mayya Sharipova 
>  wrote:
>>
>> Thanks Robert for such detailed investigations.
>>
>> Lucene-Solr-SmokeRelease-8.9 also had 2 recent failures. Failures are not 
>> reproducible on my local machine.
>>
>> build #13:  ant test  -Dtestcase=SolrCloudReportersTest 
>> -Dtests.method=testExplicitConfiguration -Dtests.seed=60FEAB39C2B47705 
>> -Dtests.multiplier=2 -Dtests.locale=ro-RO 
>> -Dtests.timezone=Africa/Brazzaville -Dtests.asserts=true 
>> -Dtests.file.encoding=UTF-8
>> build# 12: ant test -Dtestcase=LeaderTragicEventTest 
>> -Dtests.method=testLeaderFailsOver -Dtests.seed=BB301A174F4BDB5 
>> -Dtests.multiplier=2 -Dtests.locale=sr-Latn-RS 
>> -Dtests.timezone=Africa/Bissau -Dtests.asserts=true 
>> -Dtests.file.encoding=ISO-8859-1
>>
>> On Sat, Jun 12, 2021 at 5:06 PM Robert Muir  wrote:
>>>
>>> OK I managed to finally get this smoketester to pass on my machine, so
>>> for THIS release I will retract my -1 and change it to a +1.
>>>
>>> I have reset my system configuration back though, so we should really
>>> fix these test problems for the future.
>>>
>>> SUCCESS! [1:08:26.448122]
>>>
>>> There were a few compounding issues, I will break out some issues a
>>> bit later. I don't think they need to be blockers for THIS release,
>>> but let's please fix them! I can help try to dig on each one, but here
>>> are the biggest two problems:
>>>
>>> 1. some solr tests don't obey their sandbox and fail with
>>> tests.workDir (if it is set in the user's build.properties). These
>>> tests try to access wrong parts of the filesystem which can cause
>>> tests to meddle with each other. obeying the test sandbox
>>> (tests.workDir) is important, it is how I prevent these tests from
>>> destroying my SSDs.
>>>
>>> 2. some solr HDFS tests will falsely fail if they "think" disk space
>>> is low (even when it is not running out). They dump megabytes of
>>> output, but this part is the key:
>>>
>>>[junit4]   2> 1000960 WARN  (IPC Server handler 3 on 33951) [ ]
>>> o.a.h.h.s.b.BlockPlacementPolicy Failed to place enough replicas,
>>> still in need of 2 to reach 2 (unavailableStorages=[],
>>> storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK],
>>> creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true)
>>> For more information, please enable DEBUG log level on
>>> org.apache.hadoop.hdfs.server.blockmanagement.BlockPlacementPolicy and
>>> org.apache.hadoop.net.NetworkTopology
>>>[junit4]   2> 1000960 WARN  (IPC Server handler 3 on 33951) [ ]
>>> o.a.h.h.p.BlockStoragePolicy Failed to place enough replicas: expected
>>> size is 2 but only 0 storage types can be selected (replication=2,
>>> selected=[], unavailable=[DISK], removed=[DISK, DISK],
>>> policy=BlockStoragePolicy{HOT:7, storageTypes=[DISK],
>>> creationFallbacks=[], replicationFallbacks=[ARCHIVE]})
>>>[junit4]   2> 1000960 WARN  (IPC Server handler 3 on 33951) [ ]
>>> o.a.h.h.s.b.BlockPlacementPolicy Failed to place enough replicas,
>>> still in need of 2 to reach 2 (unavailableStorages=[DISK],
>>> storagePolicy=BlockStoragePolicy{HOT:7, storageTypes=[DISK],
>>> creationFallbacks=[], replicationFallbacks=[ARCHIVE]}, newBlock=true)
>>> All required storage types are unavailable:
>>> unavailableStorages=[DISK], storagePolicy=BlockStoragePolicy{HOT:7,
>>> storageTypes=[DISK], creationFallbacks=[],
>>> replicationFallbacks=[ARCHIVE]}
>>>[junit4]   2> 1000961 WARN  (Thread-2642) [ ]
>>> o.a.h.h.DataStreamer DataStreamer Exception
>>>[junit4]   2>   =>
>>> org.apache.hadoop.ipc.RemoteException(java.io.IOException): File
>>> /testfile could only be written to 0 of the 1 minReplication nodes.
>>> There are 2 datanode(s) running and 2 node(s) are excluded in this
>>> operation.
>>>
>>> So I think these tests should be tweaked to not require gigabytes of
>>> free space to pass. (fix the threshold or whatever, or add an assume
>>> or something). I worked around the situation by temporarily
>>> repartitioning and giving them another gigabyte (!). In no event was
>>> there ever any danger of running out of space! They just falsely fail
>>> even when there are hundreds of MB available. Seems they have some
>>> kind of bogus threshold in the algorithm (e.g. inspecting percentages
>>> or something).
>>>
>>> On Sat, Jun 12, 2021 at 12:22 PM Robert Muir  wrote:
>>> >
>>> > The tests also aren't "timing out". They are failing.
>>> >
>>> > On Sat, Jun 12, 2021 at 12:21 PM Robert Muir  wrote:
>>> > >
>>> > > Ishan, no, they arent running out of resources, not even close. I have
>>> > > 20GB of ram and by default it is only using 3 JVMs.
>>> > >
>>> > > On Sat, Jun 12, 2021 at 12:04 PM Ishan Chattopadhyaya
>>> > >  wrote:
>>> > > >
>>> > > > Hi Rob, could it be possible that the tests are timing out on your 
>>> > > > machine due to lack of resources? Can you try running 

Re: [VOTE] Release Lucene/Solr 8.9.0 RC1

[Atri Sharma]

It is not depending on timing -- it just includes the timing in its
output (it basically diffs the response message with and without CBs).

Atri

On Fri, Jun 11, 2021 at 8:02 PM Michael Sokolov  wrote:
>
> I ran the smoketester (FWIW I always have to pass --tmp-dir /local/tmp
> because my /tmp is not big enough for this thing), but it failed for
> me:
>
>[junit4] Tests with failures [seed: D9C1F978D5A8B019]:
>[junit4]   - 
> org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming
>
> Have to say, a test with the word "Timing" in the name makes me wary.
> I don't know what the test does exactly, but if it is sensitive to
> timing, that is a recipe for unreliability. Maybe it is just including
> timing in the response?
>
> I re-ran the test with ant test -Dtestcase=TestCircuitBreaker
> -Dtests.seed=D9C1F978D5A8B019 and it passed ...
>
> On Fri, Jun 11, 2021 at 9:48 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
> > > >> > >
> 

Re: Revisiting Standardized Test Names in Solr

[Atri Sharma]

+1.

Either way is fine, as long as its enforced.

On Thu, 3 Jun 2021, 05:12 Eric Pugh, 
wrote:

> I’m in the *Test.java camp, but primarily care about any consistent
> pattern!
>
>
> On Jun 2, 2021, at 7:29 PM, Marcus Eagan  wrote:
>
> Hi all,
>
> I am reviving this thread but perhaps it should be moved to
> d...@solr.apache.org given the project-level changes. Do people favor
> standardizing Solr to match Lucene's convention or do you prefer *Test.java
> as the convention?
>
> There are many more files, and a few that don't follow either convention,
> I bet.
>
> Curious about people's thoughts:
>
> Marcussorealheis:solr marcuseagan$ find . -name "Test*.java"  | wc -l
>  493
> Marcussorealheis:solr marcuseagan$ find . -name "*Test.java"  | wc -l
>  753
>
> On Fri, Feb 26, 2021 at 7:55 AM Gus Heck  wrote:
>
>> Maybe simply apply the standard in both places?
>>
>> On Fri, Feb 26, 2021 at 9:04 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>>
>>> I interpreted Mark as saying, we should forge ahead with the things like
>>> standardizing test names, and when the reference branch is ready, we tackle
>>> it.
>>>
>>> Having read most of the individual commits, all 1405 and counting, I
>>> think that bringing this code base in is going to be a major effort, and
>>> really isn’t going to be easy to bring in bit by bit.  The changes are to
>>> everything, and I think unwinding the changes into “chunks” is going to be
>>> even more herculean….   The changes touch everything, and honestly, since
>>> it’s all about restoring speed and paying down accumulated tech debt, I
>>> totally get why it’s so intrusive.  It’s a revolutionary change, not an
>>> evolutionary one.
>>>
>>>
>>>
>>> On Feb 26, 2021, at 8:26 AM, Jason Gerlowski 
>>> wrote:
>>>
>>> I hope that doesn’t sound too negative
>>>
>>>
>>> Not to me.  But I'm a little confused what your ultimate stand is on
>>> these renames Marcus is proposing.  I'm hearing different messages in
>>> different sections of your email.
>>>
>>> There are already so many conflicts, you will cry and then realize there
>>> are more.
>>>
>>>
>>> Sounds very much like you're saying that the test renames will cause
>>> really painful merge-conflicts, and that renames should wait because
>>> of the pain involved in reconciling ref_impl.
>>>
>>> But...
>>>
>>> You can’t let a specter freeze the tireless day to day shifting and
>>> shuffling of names and rules and locations.
>>>
>>>
>>> Sounds like you're saying that we shouldn't let fear of ref_impl
>>> complications stop us from doing renames, file-moves, etc.
>>>
>>> Sorry if I'm just being daft, but can you clarify please?  Are you
>>> saying that we should avoid big changes because of the ugly merges
>>> with ref_impl?  Or that we shouldn't let fear of ref_impl
>>> complications stop us from anything on master?  Or something else
>>> altogether?
>>>
>>> Best,
>>>
>>> Jason
>>>
>>> On Fri, Feb 26, 2021 at 7:50 AM Mark Miller 
>>> wrote:
>>>
>>>
>>> I hope that doesn’t sound too negative, “clinging” never sounds as
>>> positive as I’d like and I do negative plenty well without doing it by
>>> accident. Not a pessimistic statement though, I made it even better than I
>>> was planning or remembering I could or however that works. Resistance is
>>> built into the equation - this isn’t rock and roll, I’m a science bachelor.
>>> Though only a small few liberal arts classes made me go, so I wouldn’t
>>> trust the cert myself. Anyway, I learned from multiple Star Wars movies
>>> what to do here, you have to setup an ambush on the trench run and then
>>> just make the thing look like a huge black star.
>>>
>>> On Fri, Feb 26, 2021 at 4:38 AM Mark Miller 
>>> wrote:
>>>
>>>
>>> There are already so many conflicts, you will cry and then realize there
>>> are more. Even worse, some things have been changed due to their
>>> cost/benefit failings, things that someone, somewhere, will cling to like a
>>> life vest.
>>>
>>> The ref branch waits for no man, and expects the same.
>>>
>>> It lives on ridiculous speed and stability and throws mergability to the
>>> crows.
>>>
>>> It could not be merged into anything and survive, but it can absorb
>>> anything, as long as it behaves like a boss or can be jostled into doing
>>> so. So fear not for the fearless. You can’t let a specter freeze the
>>> tireless day to day shifting and shuffling of names and rules and
>>> locations. I swear, enough lucky shifts and this thing can rise to meet the
>>> living. I’ve seen it see dead people.
>>>
>>> End of the day, if the ref branch can’t survive even a large and lengthy
>>> divergence, if that is the freeze in its tracks, it’s not at all what I’ve
>>> said ive been working on and so does it even matter?
>>>
>>>
>>> On Mon, Feb 22, 2021 at 9:39 AM Jason Gerlowski 
>>> wrote:
>>>
>>>
>>> I'm fine with standardization, whichever convention we choose.  I have
>>> a slight preference for FooTest, for the same reason Gus mentioned,
>>> but any 

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

[Atri Sharma]

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

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

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

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


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

> I would appreciate a second opinion on the pull request. Substantive
> issues have been resolved. At this point, the discussion is about code
> style and coding standards. I don’t have detailed knowledge about the Solr
> coding style, so I’d appreciate another set of eyes.
>
> The current behavior is buggy, and we are not able to use it at Chegg. The
> patch fixes those bugs.
>
> https://github.com/apache/solr/pull/96
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 12:27 PM, Walter Underwood 
> wrote:
>
> I answered the comments. I don’t see those answers on github, oddly.
>
> I’ll re-answer them. Most of your questions are already answered in the
> discussion on Jira.
>
> I central issues is that load average is not always a CPU measure. In some
> systems, it includes threads in iowait. So it is potentially misleading to
> label it as CPU and document it as CPU. The updated documentation makes
> that clear, so that should have already answered your comment. that is why
> it is important to rename the existing circuit breaker.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Jun 1, 2021, at 12:20 PM, Atri Sharma  wrote:
>
> I tool a look at the PR and gave comments for SOLR-15056, and the last I
> checked, my comments were not addressed?
>
> On Wed, 2 Jun 2021, 00:31 Walter Underwood,  wrote:
>
>> Could someone else please take a look at SOLR-15056? This is a small
>> blast radius change that improves the circuit breakers. It includes unit
>> tests and documentation and has been ready since January.
>>
>> https://github.com/apache/solr/pull/96/files
>> https://issues.apache.org/jira/browse/SOLR-15056
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Jun 1, 2021, at 11:53 AM, Mayya Sharipova <
>> mayya.sharip...@elastic.co.INVALID> wrote:
>>
>> Thank you for the update, Houston.
>>
>> I've started the release process, the branch 8.9 is now cut.
>>
>> On Tue, Jun 1, 2021 at 11:21 AM Houston Putman 
>> wrote:
>>
>>> Mayya, SOLR-14978 is now in 8.x. So no longer a blocker.
>>>
>>> - Houston
>>>
>>> On Thu, May 27, 2021 at 11:42 PM David Smiley 
>>> wrote:
>>>
>>>> SOLR-15412 is rather serious as the title suggests.  I haven't been
>>>> tracking the progress so if it's already resolved, that's unknown to me and
>>>> isn't reflected in JIRA.
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Thu, May 27, 2021 at 5:24 PM Mayya Sharipova <
>>>> mayya.sharip...@elastic.co.invalid> wrote:
>>>>
>>>>> Hello everyone,
>>>>> I wonder if everyone is ok for May 31st (Monday) as the date for the
>>>>> feature freeze date and branch cut?
>>>>> I've noticed that `releaseWizard.py` is also asking for the length of
>>>>> feature freeze. What is the custom length to put there?
>>>>>
>>>>> Looks like Lucene
>>>>> <https://issues.apache.org/jira/projects/LUCENE/versions/12349562>
>>>>> doesn't have any unresolved issues for 8.9.
>>>>> SOLR <https://issues.apache.org/jira/projects/SOLR/versions/12349563>
>>>>>  has:
>>>>> -  SOLR-15412  Strict validation on Replica metadata can cause
>>>>> complete outage  (Looks like it may be resolved already?)
>>>>> - SOLR-15410 GC log is directed to console when starting Solr with
>>>>> Java 11 Open J9 on Windows
>>>>> - SOLR-15056  CPU circuit breaker needs to use CPU utilization, not
>>>>> Unix load average
>>>>>
>>>>> Are we ok to postpone these

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

[Atri Sharma]

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

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

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

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


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

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

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

[Atri Sharma]

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

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

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

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

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

 Thank you.






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

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

Re: Circuit Breakers -- SOLR-15056

[Atri Sharma]

Hello,

I have been recovering from Covid so this has been delayed.

Apologies for not being able to look into this. This is on my ToDo
list for this week.

On Thu, May 6, 2021 at 9:48 PM Walter Underwood  wrote:
>
> How do we make progress on SOLR-15056?
>
> This is a simple fix:
>
> * Improve the name for an existing circuit breaker
> * Add a new circuit breaker that does what the name for the first one 
> suggested
> * Make the documentation more accurate
>
> I submitted a patch in mid-January. I resubmitted those as a PR last month.
>
> https://issues.apache.org/jira/browse/SOLR-15056
> https://github.com/apache/solr/pull/96
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>


-- 
Regards,

Atri
Apache Concerted

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

Re: Separate git repo(s) for Solr modules

[Atri Sharma]

I am a bit confused -- if Lucene was to become a sub module of Solr, are we
essentially forking Lucene?

I am in agreement with Ilan and Houston -- Solr should be depending on
Lucene only as a dependency.


On Tue, 4 May 2021, 19:52 Noble Paul,  wrote:

> @Ilan Ginzburg 
>
> I don't think the project split is counter productive because we have
> lucene as a sub module. Solr does not use lucene like a simple library.
> It's an integral part of Solr
>
>
> On Tue, May 4, 2021 at 10:02 PM Ilan Ginzburg  wrote:
>
>> As with any dependency on any project, you update the dependency project
>> first then consume the updated dependency in Solr.
>>
>> If the idea is to be able to modify Lucene and Solr in parallel, then the
>> project split is counterproductive.
>>
>> From the Solr perspective, Lucene and Zookerper are really two “similar”
>> dependencies and IMO we should think about them in that way.
>>
>> Ilan
>>
>> On Tue 4 May 2021 at 09:45, Noble Paul  wrote:
>>
>>> @Houston
>>>
>>> So, Are you suggesting we should not do that ?
>>>
>>> On Tue, May 4, 2021 at 2:35 PM Houston Putman 
>>> wrote:
>>>
 In the future we wont be able to “work on both at the same time”, once
 Lucene 9 is cut. Why not pull that bandaid now?

 On Mon, May 3, 2021 at 11:32 PM Noble Paul 
 wrote:

> I'm still struggling to understand the workflow when I'm working on a
> feature that spans lucene and solr.
>
> I'm yet to see an argument against sub-modules
>
> On Wed, Feb 17, 2021 at 3:18 AM Jason Gerlowski 
> wrote:
>
>> > Shoving such a component into lucene-solr repo makes no sense,
>> given its branching strategy is based on master / branch_8x
>>
>> I get how this could cause issues - I def hadn't thought much about
>> multi-version support and branching.  But I don't think moving plugins
>> to a separate repo solves that problem for us.  If our first class
>> plugins are set up to have different release "lines" that don't line
>> up with major Solr versions, it's only a matter of time before two of
>> those plugins have branch requirements that conflict.  Unless I'm
>> missing something here?
>>
>> > I'd prefer that a module only leave our "contribs" area when the
>> concerns/limitations become real.  Doing it prematurely could lead to
>> atrophy of the module
>>
>> +1 to David's comment.   I def hadn't considered the branching-scheme
>> issues that Ishan brought up in his last reply, and they seem like
>> valid concerns to me.  But the risk and the downsides of "atrophy" are
>> serious enough that I'd vote to not risk them until this starts to
>> cause us issues in practice.  Even if, for now, that means we won't be
>> able to build a single plugin jar that supports (e.g.) 3 major Solr
>> versions.  IMO that's a much smaller loss.
>>
>> On Tue, Feb 16, 2021 at 9:40 AM David Smiley 
>> wrote:
>> >
>> > On Tue, Feb 16, 2021 at 8:38 AM Eric Pugh <
>> ep...@opensourceconnections.com> wrote:
>> >>
>> >> Testing across multiple versions is always very difficult ;-).  I
>> recently saw this very interesting approach to using our Dockerized 
>> Solr’s
>> to test a component against a number of previous versions of Solr.
>> https://github.com/querqy/querqy/pull/147. I’m hopeful it could be a
>> model for other packages to adopt.
>> >
>> >
>> > Thanks for the link to that Querqy PR.  That is *very* similar to
>> what I do at work (minus multi-version testing), and also similar to how 
>> I
>> test multiple versions in one of my pet projects by using a CI build 
>> matrix
>> of a configurable dependency.  I didn't know Testcontainer.org has its 
>> own
>> Solr module -- https://www.testcontainers.org/modules/solr/ but we
>> implemented that ourselves; not hard.
>> >
>> >>
>> >> Trying to maintain across multiple versions is kind of a Sisyphean
>> task, and I don’t think plays to open source communities strengths.   
>> It’s
>> hard enough to keep all components of Solr up to date with the latest
>> Lucene and the latest Solr….  (Try out wt=xlsx Response Writer, it’s
>> currently broken on master) .  Reminds me of the Apache Gump project ;-)
>> >>
>> >> If something is really going to be backcompatible across certain
>> versions, then maybe having it’s own repo makes sense,
>> >
>> >
>> > I'd prefer that a module only leave our "contribs" area when the
>> concerns/limitations become real.  Doing it prematurely could lead to
>> atrophy of the module
>> >
>> >>
>> >> but I suspect it means those components may go stale….   Look at
>> DIH and Velocity components that are moved over to their own repos, both
>> are getting stale, and I’d argue it’s because they don’t live in the main
>> project where all of us have 

Re: Welcome Peter Gromov as Lucene committer

[Atri Sharma]

Did you set your 2FA up and get added to the Apache Software
Foundation Github org?

On Wed, Apr 7, 2021 at 12:42 PM Peter Gromov
 wrote:
>
> Thanks for the honor!
>
> (BTW I'm still not recognized by Github as having write access, and can't 
> merge my pull requests :))
>
> > Peter, the tradition is that new committers introduce themselves with a 
> > brief bio.
>
> Okay, time for some bragging :) I've been working at JetBrains for some 17 
> years, most of them on IntelliJ platform, mainly supporting various languages 
> and their infrastructure, analyzing snapshots and improving performance. 
> Aiming to catch more bugs before they hit production, I've introduced 
> property-based testing to IntelliJ by creating a small library called 
> jetCheck. Recently I've switched to the Grazie project and now I do some 
> rule-based computational linguistics there and enhance the IDE support for 
> English. As Grazie needs LanguageTool and Hunspell, I've also spent some time 
> rewriting the latter in Java (here in Lucene), and optimizing them both. In 
> my free time, I like mountain hiking (Munich/Germany is a great location for 
> that!), and some amateur piano/harmonica playing/singing.

-- 
Regards,

Atri
Apache Concerted

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

Re: SOLR-15056 circuit breaker bugfix?

[Atri Sharma]

We should update the documentation to point to making PRs.

On Wed, Mar 24, 2021 at 10:30 AM Ishan Chattopadhyaya
 wrote:
>
> I don't think asking contributors to do more work than required (as per 
> documentation) is a good idea.
>
> On Wed, 24 Mar, 2021, 10:13 am Atri Sharma,  wrote:
>>
>> I did share steps for your reference the last time we talked about this:
>>
>> https://markmail.org/message/2buvbboyoy7ip4v7?q=list:org%2Eapache%2Elucene%2Esolr-dev
>>
>> On Wed, Mar 24, 2021 at 9:57 AM Walter Underwood  
>> wrote:
>> >
>> > If patches are hard for people, then the How to Contribute page needs to 
>> > be rewritten to tell people to create PRs. I followed that page when doing 
>> > this work.
>> >
>> > It should have specific instructions on how to make PRs, maybe branch 
>> > naming, etc. I make PRs all day at work, but I never use github and I 
>> > don’t know what Solr wants.
>> >
>> > wunder
>> > Walter Underwood
>> > wun...@wunderwood.org
>> > http://observer.wunderwood.org/  (my blog)
>> >
>> > On Mar 23, 2021, at 8:10 PM, Atri Sharma  wrote:
>> >
>> > +1
>> >
>> > I tried reviewing the patch and echoed AB's point of needing a PR. Happy 
>> > to do the review as soon as we have that.
>> >
>> > On Wed, 24 Mar 2021, 03:04 Anshum Gupta,  wrote:
>> >>
>> >> 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
>> >
>> >
>>
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>


-- 
Regards,

Atri
Apache Concerted

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

Re: SOLR-15056 circuit breaker bugfix?

[Atri Sharma]

I did share steps for your reference the last time we talked about this:

https://markmail.org/message/2buvbboyoy7ip4v7?q=list:org%2Eapache%2Elucene%2Esolr-dev

On Wed, Mar 24, 2021 at 9:57 AM Walter Underwood  wrote:
>
> If patches are hard for people, then the How to Contribute page needs to be 
> rewritten to tell people to create PRs. I followed that page when doing this 
> work.
>
> It should have specific instructions on how to make PRs, maybe branch naming, 
> etc. I make PRs all day at work, but I never use github and I don’t know what 
> Solr wants.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Mar 23, 2021, at 8:10 PM, Atri Sharma  wrote:
>
> +1
>
> I tried reviewing the patch and echoed AB's point of needing a PR. Happy to 
> do the review as soon as we have that.
>
> On Wed, 24 Mar 2021, 03:04 Anshum Gupta,  wrote:
>>
>> 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
>
>


-- 
Regards,

Atri
Apache Concerted

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

Re: SOLR-15056 circuit breaker bugfix?

[Atri Sharma]

+1

I tried reviewing the patch and echoed AB's point of needing a PR. Happy to
do the review as soon as we have that.

On Wed, 24 Mar 2021, 03:04 Anshum Gupta,  wrote:

> 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: Lucene and Solr repositories mirrored, main branch ready

[Atri Sharma]

Totally agreed. They have really driven this to completion with as minimal
disruption as possible.

Special mention to Uwe, as always!

On Wed, 10 Mar 2021, 20:32 David Smiley,  wrote:

> Thank *you* Dawid!  You and Jan have been big heroes of this transition!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Mar 10, 2021 at 9:36 AM Dawid Weiss  wrote:
>
>> Thank you everyone for the collective effort to clean up stale project
>> references, templates, etc.
>>
>> D.
>>
>> On Wed, Mar 10, 2021 at 1:04 PM Dawid Weiss 
>> wrote:
>> >
>> > First of all, apologies for the e-mail commit bomb... Things like that
>> > can happen, hard to tell in advance. Thanks to infra for helping out.
>> >
>> > Solr and Lucene repositories have been cloned at commit 7ada403218.
>> >
>> > Master branch is wiped out of content on all repositories, branch_8x
>> > is wiped on lucene and solr repositories to avoid confusion (8x
>> > development takes place at the joint repository).
>> >
>> > I've removed lucene/solr from each other. Things should work out of
>> > the box but if something does not, please file an issue (or better -
>> > try to fix it).
>> >
>> > There is going to be a lot of mundane cleanup work to remove cross
>> > references and get the documentation going but it's all a follow-up.
>> >
>> > Here is a short help guide to port existing PRs:
>> > https://github.com/apache/lucene-solr/blob/master/PRs.md
>> >
>> > Github actions should work too, as shown here:
>> > https://github.com/apache/lucene/pull/2
>> >
>> > Builds can be enabled (perhaps slowly, at first? :).
>> >
>> > Solr developers: Lucene can be built and installed in your local maven
>> > repositories with:
>> > gradlew mavenToLocalRepo
>> >
>> > Dawid
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>

Re: Repository fork (master) about to happen (Wednesday)

[Atri Sharma]

Actually my question was more around what happens with PRs that cut across
both Lucene and Solr -- but your answer was helpful in itself, thank you!

On Mon, 8 Mar 2021, 21:46 Uwe Schindler,  wrote:

> I think the problem was what happens with the PR in Githubs user
> interface.
>
> This question was asked many times, answer is simple: NO you can't move
> over Pull requests to different repositories on Github! It's also
> impossible to export and reimport them. People have to recreate them.
>
> Dawid is correct: You can merge the pull request also into another rlocal
> repository, but this is impossible with the Github UI. So basically, you
> have to read the email that comes in with the Pull Request that lists the
> link to the branch and patch. Then use git command line (or Tortoise) and
> copypaste the URL there as "source branch" for the merge. Then you execute
> the merge, squash and commit/push.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
> > -Original Message-
> > From: Dawid Weiss 
> > Sent: Monday, March 8, 2021 3:25 PM
> > To: Lucene Dev 
> > Subject: Re: Repository fork (master) about to happen (Wednesday)
> >
> > > What happens to open PRs?
> >
> > A pull request on github is essentially a diff between two commits.
> > Existing PRs have to be placed on top of the new development branch.
> > Note these repositories are (initially) identical with lucene-solr so
> > if somebody clones the solr repo and the solr-lucene repo, they can
> > create the same PR over at the new project (pointing at the new main
> > branch as a reference).
> >
> > Dawid
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Repository fork (master) about to happen (Wednesday)

[Atri Sharma]

What happens to open PRs?

On Mon, 8 Mar 2021 at 7:28 PM, Dawid Weiss  wrote:

> I think my message got buried among other messages, so starting a new
> thread.
>
> With Solr established, I think we're ready to proceed with forking the
> git repository from:
>
> https://git-wip-us.apache.org/repos/asf/lucene-solr.git
>
> to:
>
> (Lucene)
> https://git-wip-us.apache.org/repos/asf/lucene.git
> (Solr)
> https://git-wip-us.apache.org/repos/asf/solr.git
>
> My plan is as follows:
>
> 1. DISABLE CI jobs and anything that pulls from current master. (Uwe,
> would you do help me with this?)
>
> 2. Branch master to lucene/main and solr/main. Remove sibling
> project's sources from each respective branch.
>
> 3. Create a wiping commit on master (leaving a note about Solr going
> TLP and new repository locations).
>
> 4. Push these changes and branches to lucene-solr.git.
>
> 5. Push a git mirror of everything up to this point to Lucene and Solr
> repositories.
>
> 6. Create and enable independent CI jobs for Lucene and Solr. (Again,
> some help here would be needed).
>
> 7. If everything goes ok, pop a celebratory beer.
>
> Just as a remainder - the development of branch_8x STAYS ON
> lucene-solr. Cherry-picking of individual commits can still be done if
> you have two remotes and know how to operate this (admittedly not a
> newbie git workflow). Anyone not comfortable - use patches, they're
> raw and work well on anything.
>
> Mainline development proceeds in each project's repository independently.
>
> Does Wednesday sound ok for this plan? Then it'd be a few work week
> days to clean up the dust.
>
> Dawid
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Regards,

Atri
Apache Concerted

Re: Lucene/Solr Code of Conduct and etiquette

[Atri Sharma]

+1

On Tue, 2 Mar 2021, 15:01 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
>
>

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

[Atri Sharma]

Congratulations!!

On Fri, 19 Feb 2021, 00:26 Anshum Gupta,  wrote:

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

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

[Atri Sharma]

Congratulations!

On Thu, 18 Feb 2021, 17:31 Jan Høydahl,  wrote:

> Congratulations Mike!
>
> Jan Høydahl
>
> > 17. feb. 2021 kl. 22:31 skrev 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
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.8.1 RC2

[Atri Sharma]

SUCCESS! [1:03:43.432934]

+1 Binding

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


-- 
Regards,

Atri
Apache Concerted

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

Re: Circuit Breakers interaction with Shards

[Atri Sharma]

This is a debate better suited for  a different forum  -- but I would
disagree with your assertion that rate limiting is a bad idea.

Solr allows you to specify node level request quotas which also follow the
principle of not limiting internal requests. I find that to be pretty
useful in two forms: 1. Use it in conjunction with a global request limit
which is typically 0.75 of my total load capacity given my average query
resource consumption. 2. Allow per node request limits to ensure fairness
and dedicated capacity for different types of requests. 3. Allow circuit
breakers to handle cases where a couple of rogue queries can take down
nodes.

We digress -- as I said, it should be fairly simple to have a circuit
breaker which rejects only external requests,  but should be clearly
documented with its downsides.

On Mon, 15 Feb 2021, 00:33 Walter Underwood,  wrote:

> We’ve looked at and rejected rate limiters as high-maintenance and not
> sufficient protection.
>
> We would have run nginx on each node, sent external traffic to nginx on a
> different port and let internal traffic stay on the default Solr port. This
> has other advantages (monitoring), but the rate limiting part is way too
> fiddly.
>
> Rates depend on how much CPU is used per query and on the size of the
> cluster (if they are not on each node). Some examples from our largest
> cluster which would need a change in rate limits. Some of these could be
> set by doing offline load benchmarks, some not.
>
> * Experiment cell that uses 2.5X more CPU for each query (running now in
> prod)
> * Increasing traffic allocated to that cell (did this last week)
> * Increase in index size (number of docs and CPU requirements increase
> about 5% every month)
> * Website slowdown that shifts most traffic to mobile, where queries use
> 2X as much CPU
> * Horizontal scaling from 24 tp 48 nodes
> * Vertical scaling from c5.8xlarge to c5.18xlarge
>
> And so on. Rate limiting would require almost weekly load benchmarks and
> it still wouldn’t catch the outage-causing problems.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Feb 14, 2021, at 10:25 AM, Atri Sharma  wrote:
>
> The way I look at it is that for cluster level stability, rate limiters
> should be used which allow rate limiting of only external requests. They
> are "circuit breakers" in the sense of defending against cluster level
> instability, which is what you describe.
>
> Circuit breakers, in Solr world, are targeted to be the last resort
> defense of a node.
>
> As I said earlier, it is possible to write a circuit breaker which rejects
> only external requests, but I personally do not see the benefit in presence
> of rate limiters.
>
> On Sun, 14 Feb 2021, 23:50 Walter Underwood, 
> wrote:
>
>> Ideally, it would only affect a few queries. In reality, with a sharded
>> system, the impact will be large.
>>
>> I disagree that the goal is to protect a node. The goal is to make the
>> entire cluster avoid congestion failure when overloaded, while providing
>> good service for the load that it can handle.
>>
>> I have had Solr clusters take down entire websites when overloaded, both
>> at Netflix and Chegg, and I’ve built defenses for this at both places. I’m
>> a huge fan of circuit breakers.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>> On Feb 14, 2021, at 9:50 AM, Atri Sharma  wrote:
>>
>> This has an issue of still leading to node outages if the fanout for a
>> query is high.
>>
>> Circuit breakers follow a simple rule -- defend the node at the cost of
>> degraded responses.
>>
>> Ideally, only few requests will be completely rejected -- some will see
>> partial results. Due to this non discriminating nature of circuit breakers,
>> the typical blip on service quality due to high resource usage is short
>> lived.
>>
>> However, it is possible to write a circuit breaker which rejects only
>> external requests in master branch (we have the ability to identify
>> requests as internal or external there).
>>
>> Regards,
>>
>> Atri
>>
>> On Sun, 14 Feb 2021, 23:07 Walter Underwood, 
>> wrote:
>>
>>> This got zero responses on the solr-user list, so I’ll raise the issue
>>> here.
>>>
>>> Should circuit breakers only kill external search requests and not
>>> cluster-internal requests to shards?
>>>
>>> Circuit breakers can kill any request, whether it is a client request
>>> from outside the cluster or an internal distribu

Re: Circuit Breaker Clean-up/Extension Jira

[Atri Sharma]

If you have a github account, you can fork Lucene/Solr repository, create a
branch in your fork, push your changes there and navigate to the Github
page of your fork which will provide you a button to create a PR.

On Sun, 14 Feb 2021, 23:46 Walter Underwood,  wrote:

> Sorry, couldn’t figure out how to do that for Solr. I do PRs all day on
> our company system, but that uses Bitbucket.
>
> The “how to contribute” docs just said to make a PR, which didn’t really
> help. I tried, but nothing worked.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Feb 14, 2021, at 9:56 AM, Atri Sharma  wrote:
>
> Also, if you could open a PR, it would be easier to review.
>
> On Sun, 14 Feb 2021, 23:22 Atri Sharma,  wrote:
>
>> Apologies for the delay. I will review this tomorrow
>>
>> On Sun, 14 Feb 2021, 23:06 Walter Underwood, 
>> wrote:
>>
>>> Please review for 8.9. We will use this feature after it is updated. The
>>> current circuit breakers won’t work for us.
>>>
>>> https://issues.apache.org/jira/browse/SOLR-15056
>>>
>>> This change:
>>>
>>> * Preserves existing functionality.
>>> * Renames the existing load average circuit breaker to a more accurate
>>> name.
>>> * Adds a circuit breaker for CPU usage that is available if the JVM
>>> supports it.
>>> * Adds detail to documentation, listing which JMX calls each circuit
>>> breaker is based on.
>>> * Copy-edits on docs for more detail, less complicated wording (good
>>> when English is not the reader’s primary language)
>>> * Includes unit tests.
>>>
>>> wunder
>>> Walter Underwood
>>> wun...@wunderwood.org
>>> http://observer.wunderwood.org/  (my blog)
>>>
>>>
>

Re: Circuit Breakers interaction with Shards

[Atri Sharma]

The way I look at it is that for cluster level stability, rate limiters
should be used which allow rate limiting of only external requests. They
are "circuit breakers" in the sense of defending against cluster level
instability, which is what you describe.

Circuit breakers, in Solr world, are targeted to be the last resort defense
of a node.

As I said earlier, it is possible to write a circuit breaker which rejects
only external requests, but I personally do not see the benefit in presence
of rate limiters.

On Sun, 14 Feb 2021, 23:50 Walter Underwood,  wrote:

> Ideally, it would only affect a few queries. In reality, with a sharded
> system, the impact will be large.
>
> I disagree that the goal is to protect a node. The goal is to make the
> entire cluster avoid congestion failure when overloaded, while providing
> good service for the load that it can handle.
>
> I have had Solr clusters take down entire websites when overloaded, both
> at Netflix and Chegg, and I’ve built defenses for this at both places. I’m
> a huge fan of circuit breakers.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
> On Feb 14, 2021, at 9:50 AM, Atri Sharma  wrote:
>
> This has an issue of still leading to node outages if the fanout for a
> query is high.
>
> Circuit breakers follow a simple rule -- defend the node at the cost of
> degraded responses.
>
> Ideally, only few requests will be completely rejected -- some will see
> partial results. Due to this non discriminating nature of circuit breakers,
> the typical blip on service quality due to high resource usage is short
> lived.
>
> However, it is possible to write a circuit breaker which rejects only
> external requests in master branch (we have the ability to identify
> requests as internal or external there).
>
> Regards,
>
> Atri
>
> On Sun, 14 Feb 2021, 23:07 Walter Underwood, 
> wrote:
>
>> This got zero responses on the solr-user list, so I’ll raise the issue
>> here.
>>
>> Should circuit breakers only kill external search requests and not
>> cluster-internal requests to shards?
>>
>> Circuit breakers can kill any request, whether it is a client request
>> from outside the cluster or an internal distributed request to a shard.
>> Killing a portion of distributed request will affect the main request. Not
>> sure whether a 503 from a shard will kill the whole request or cause
>> partial results, but it isn’t good.
>>
>> We run with 8 shards. If a circuit breaker is killing 10% of requests on
>> each host, that will hit 57% of all external requests (0.9^8 = 0.43). That
>> seems like “overkill” to me. If it only kills external requests, then 10%
>> means 10%.
>>
>> Killing only external requests requires that external requests go roughly
>> equally to all hosts in the cluster, or at least all NRT or PULL replicas.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>
>

Re: Circuit Breaker Clean-up/Extension Jira

[Atri Sharma]

Also, if you could open a PR, it would be easier to review.

On Sun, 14 Feb 2021, 23:22 Atri Sharma,  wrote:

> Apologies for the delay. I will review this tomorrow
>
> On Sun, 14 Feb 2021, 23:06 Walter Underwood, 
> wrote:
>
>> Please review for 8.9. We will use this feature after it is updated. The
>> current circuit breakers won’t work for us.
>>
>> https://issues.apache.org/jira/browse/SOLR-15056
>>
>> This change:
>>
>> * Preserves existing functionality.
>> * Renames the existing load average circuit breaker to a more accurate
>> name.
>> * Adds a circuit breaker for CPU usage that is available if the JVM
>> supports it.
>> * Adds detail to documentation, listing which JMX calls each circuit
>> breaker is based on.
>> * Copy-edits on docs for more detail, less complicated wording (good when
>> English is not the reader’s primary language)
>> * Includes unit tests.
>>
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>>
>>

Re: Circuit Breaker Clean-up/Extension Jira

[Atri Sharma]

Apologies for the delay. I will review this tomorrow

On Sun, 14 Feb 2021, 23:06 Walter Underwood,  wrote:

> Please review for 8.9. We will use this feature after it is updated. The
> current circuit breakers won’t work for us.
>
> https://issues.apache.org/jira/browse/SOLR-15056
>
> This change:
>
> * Preserves existing functionality.
> * Renames the existing load average circuit breaker to a more accurate
> name.
> * Adds a circuit breaker for CPU usage that is available if the JVM
> supports it.
> * Adds detail to documentation, listing which JMX calls each circuit
> breaker is based on.
> * Copy-edits on docs for more detail, less complicated wording (good when
> English is not the reader’s primary language)
> * Includes unit tests.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>
>

Re: Circuit Breakers interaction with Shards

[Atri Sharma]

This has an issue of still leading to node outages if the fanout for a
query is high.

Circuit breakers follow a simple rule -- defend the node at the cost of
degraded responses.

Ideally, only few requests will be completely rejected -- some will see
partial results. Due to this non discriminating nature of circuit breakers,
the typical blip on service quality due to high resource usage is short
lived.

However, it is possible to write a circuit breaker which rejects only
external requests in master branch (we have the ability to identify
requests as internal or external there).

Regards,

Atri

On Sun, 14 Feb 2021, 23:07 Walter Underwood,  wrote:

> This got zero responses on the solr-user list, so I’ll raise the issue
> here.
>
> Should circuit breakers only kill external search requests and not
> cluster-internal requests to shards?
>
> Circuit breakers can kill any request, whether it is a client request from
> outside the cluster or an internal distributed request to a shard. Killing
> a portion of distributed request will affect the main request. Not sure
> whether a 503 from a shard will kill the whole request or cause partial
> results, but it isn’t good.
>
> We run with 8 shards. If a circuit breaker is killing 10% of requests on
> each host, that will hit 57% of all external requests (0.9^8 = 0.43). That
> seems like “overkill” to me. If it only kills external requests, then 10%
> means 10%.
>
> Killing only external requests requires that external requests go roughly
> equally to all hosts in the cluster, or at least all NRT or PULL replicas.
>
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Atri Sharma]

Hi Noble,

Is the binding vote count not incorrect?

On Thu, 28 Jan 2021, 16:24 Noble Paul,  wrote:

> [+1]  9  (4 binding)
>
>  [0]  0
>
> [-1]  0
>
>
> This vote has PASSED.
>
> I shall proceed with the rest of the release process
>
> On Thu, Jan 28, 2021 at 6:24 PM Anshum Gupta 
> wrote:
> >
> > 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
>
>
>
> --
> -
> Noble Paul
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: [VOTE] Release Lucene/Solr 8.8.0 RC2

[Atri Sharma]

+1 (binding)

SUCCESS! [1:24:26.38423]

On Mon, Jan 25, 2021 at 3:52 PM 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
>


-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene/Solr 8.8.0 RC1

[Atri Sharma]

+1 (binding)

SUCCESS! [1:04:15:20393]

On Wed, Jan 20, 2021 at 1:03 PM Ignacio Vera  wrote:
>
> +1 (binding)
>
> SUCCESS! [1:05:30.358141]
>
>
> On Tue, Jan 19, 2021 at 8:25 PM Timothy Potter  wrote:
>>
>> +1 (binding)
>>
>> SUCCESS! [1:07:15.796578]
>>
>>
>> Also built a *local* Docker image from the RC and tested various features 
>> with the Solr operator on K8s, such as the updates to the Prom exporter & 
>> Grafana dashboard for query performance.
>>
>>
>> Looks good!
>>
>>
>> On Tue, Jan 19, 2021 at 12:06 PM Houston Putman  
>> wrote:
>>>
>>> +1
>>>
>>> SUCCESS! [1:01:28.552891]
>>>
>>> On Tue, Jan 19, 2021 at 1:53 PM Cassandra Targett  
>>> wrote:

 I’ve put up the DRAFT version of the Ref Guide for 8.8: 
 https://lucene.apache.org/solr/guide/8_8/.

 I also created the Jenkins job for building the 8.8 guide which pushes to 
 the Nightlies server in case we have edits between now and release 
 (https://nightlies.apache.org/Lucene/Solr-reference-guide-8.8/).

 Note branch_8_8 does not (yet) include the new Math Expressions guide 
 being worked on in SOLR-13105. Still hoping that will make it, but thought 
 I’d get this out sooner rather than later just in case.
 On Jan 19, 2021, 10:51 AM -0600, Ishan Chattopadhyaya 
 , 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
 

-- 
Regards,

Atri
Apache Concerted

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

Re: Separate git repo(s) for Solr modules

[Atri Sharma]

+1

This is also an opportunity to create the distinction between first party
supported packages and the other plug-ins.



On Wed, 13 Jan 2021, 21:00 Ishan Chattopadhyaya, 
wrote:

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

Re: Old programmers do fade away

[Atri Sharma]

It has been a privilege to watch you work your magic and reference the
great work that you have done in this project. Thank you for setting the
bar for us.

I am happy to support the BadApples report if you would like

On Wed, 30 Dec 2020, 19:46 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
>
>

Re: 9.0 release

[Atri Sharma]

+1

I think the division steps are pretty clearly documented-- a matter of
executing them now.

On Tue, 29 Dec 2020, 01:03 Dawid Weiss,  wrote:

> It would be great indeed if we could push to finalize dividing the
> codebases (some things have been proven to be doable - snapshot
> builds, splitting the code,
> build, etc.) and then follow up with proper releases of both Lucene
> and Solr (on their independent TLP).
>
>
> Dawid
>
> On Mon, Dec 28, 2020 at 7:17 PM Michael Sokolov 
> wrote:
> >
> > Hi everyone, as we head into a new year full of optimism, is it time
> > to start discussing the next major release? We released 8.0 on Jun 18,
> > 2019, over 18 months ago. Since then we've switched to a gradle-based
> > build. We have added vector-valued fields and an HNSW neighbor search
> > algorithm for them.  At the same time Solr has been getting a major
> > overhaul which should justify a release, I think? IIRC there was talk
> > of making 9.0 be the first release of Solr as its own TLP. Is it time
> > to start planning for that now?
> >
> > -Mike
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
> >
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

Re: Processing query clause combinations at indexing time

[Atri Sharma]

In that case, I would be interested to know if this can be merged into
Luwak.

On Tue, 15 Dec 2020, 21:50 Adrien Grand,  wrote:

> I like this idea. I can think of several users who have a priori knowledge
> of frequently used filters and would appreciate having Lucene take care of
> transparently optimizing the execution of such filters instead of having to
> do it manually.
>
> I'm not sure a separate project is the best option, it makes it more
> challenging to keep up-to-date with releases, more challenging for users to
> find it, etc. I'd rather add this feature to the Lucene repository, as a
> new module or as part of an existing module?
>
>
> On Tue, Dec 15, 2020 at 4:41 PM Michael Sokolov 
> wrote:
>
>> I feel like there could be some considerable overlap with features
>> provided by Luwak, which was contributed to Lucene fairly recently,
>> and I think does the query inversion work required for this; maybe
>> more of it already exists here? I don't know if that module handles
>> the query rewriting, or the term indexing you're talking about though.
>>
>> On Mon, Dec 14, 2020 at 11:25 PM Atri Sharma  wrote:
>> >
>> > +1
>> >
>> > I would suggest that this be an independent project hosted on Github
>> (there have been similar projects in the past that have seen success that
>> way)
>> >
>> > On Tue, 15 Dec 2020, 09:37 David Smiley,  wrote:
>> >>
>> >> Great optimization!
>> >>
>> >> I'm dubious on it being a good contribution to Lucene itself however,
>> because what you propose fits cleanly above Lucene.  Even at a ES/Solr
>> layer (which I know you don't use, but hypothetically speaking), I'm
>> dubious there as well.
>> >>
>> >> ~ David Smiley
>> >> Apache Lucene/Solr Search Developer
>> >> http://www.linkedin.com/in/davidwsmiley
>> >>
>> >>
>> >> On Mon, Dec 14, 2020 at 2:37 PM Michael Froh  wrote:
>> >>>
>> >>> My team at work has a neat feature that we've built on top of Lucene
>> that has provided a substantial (20%+) increase in maximum qps and some
>> reduction in query latency.
>> >>>
>> >>> Basically, we run a training process that looks at historical queries
>> to find frequently co-occurring combinations of required clauses, say "+A
>> +B +C +D". Then at indexing time, if a document satisfies one of these
>> known combinations, we add a new term to the doc, like "opto:ABCD". At
>> query time, we can then replace the required clauses with a single
>> TermQuery for the "optimized" term.
>> >>>
>> >>> It adds a little bit of extra work at indexing time and requires the
>> offline training step, but we've found that it yields a significant boost
>> at query time.
>> >>>
>> >>> We're interested in open-sourcing this feature. Is it something worth
>> adding to Lucene? Since it doesn't require any core changes, maybe as a
>> module?
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Adrien
>

Re: Processing query clause combinations at indexing time

[Atri Sharma]

+1

I would suggest that this be an independent project hosted on Github (there
have been similar projects in the past that have seen success that way)

On Tue, 15 Dec 2020, 09:37 David Smiley,  wrote:

> Great optimization!
>
> I'm dubious on it being a good contribution to Lucene itself however,
> because what you propose fits cleanly above Lucene.  Even at a ES/Solr
> layer (which I know you don't use, but hypothetically speaking), I'm
> dubious there as well.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Dec 14, 2020 at 2:37 PM Michael Froh  wrote:
>
>> My team at work has a neat feature that we've built on top of Lucene that
>> has provided a substantial (20%+) increase in maximum qps and some
>> reduction in query latency.
>>
>> Basically, we run a training process that looks at historical queries to
>> find frequently co-occurring combinations of required clauses, say "+A +B
>> +C +D". Then at indexing time, if a document satisfies one of these known
>> combinations, we add a new term to the doc, like "opto:ABCD". At query
>> time, we can then replace the required clauses with a single TermQuery for
>> the "optimized" term.
>>
>> It adds a little bit of extra work at indexing time and requires the
>> offline training step, but we've found that it yields a significant boost
>> at query time.
>>
>> We're interested in open-sourcing this feature. Is it something worth
>> adding to Lucene? Since it doesn't require any core changes, maybe as a
>> module?
>>
>

Re: DIH replacement

[Atri Sharma]

FWIW i am interested in this -- happy to collaborate

On Sun, 29 Nov 2020, 22:07 Erick Erickson,  wrote:

> How far can we get in replacing DIH with streams? I can write a simple DIH
> implementation by wrapping a jdbc stream in an update stream for instance
> (I think).
>
> It falls down with some of the more complex DIH constructs, but the simple
> “pull data from the DB and insert it into Solr” case seems covered...
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>

[ANNOUNCE] Apache Solr 8.7.0 released

[Atri Sharma]

3/11/2020, Apache Solr™ 8.7 available

The Lucene PMC is pleased to announce the release of Apache Solr 8.7

Solr is the popular, blazing fast, open source NoSQL search platform
from the Apache Lucene project. Its major features include powerful
full-text search, hit highlighting, faceted search and analytics, rich
document parsing, geospatial search, extensive REST APIs as well as
parallel SQL. Solr is enterprise grade, secure and highly scalable,
providing fault tolerant distributed search and indexing, and powers
the search and navigation features of many of the world's largest
internet sites.


The release is available for immediate download at:


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


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


https://lucene.apache.org/solr/8_7_0/changes/Changes.html


Solr 8.7.0 Release Highlights


SOLR-14588 -- Circuit Breakers Infrastructure and Real JVM Based Circuit Breaker


SOLR-14615 –- CPU Based Circuit Breaker


SOLR-14537 -- Improve performance of ExportWriter


SOLR-14651 -- The MetricsHistoryHandler Can Be Disabled


A summary of important changes is published in the Solr Reference
Guide at https://lucene.apache.org/solr/guide/8_7/solr-upgrade-notes.html.
For the most exhaustive list, see the full release notes at
https://lucene.apache.org/solr/8_7_0/changes/Changes.html or by
viewing the CHANGES.txt file accompanying the distribution.  Solr's
release notes usually don't include Lucene layer changes.  Lucene's
release notes are at
https://lucene.apache.org/core/8_7_0/changes/Changes.html


Note: The Apache Software Foundation uses an extensive mirroring network for

distributing releases. It is possible that the mirror you are using may not have

replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.



-- 
Regards,

Atri
Apache Concerted

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

[ANNOUNCE] Apache Lucene 8.7.0 released

[Atri Sharma]

03/11/2020, Apache Lucene™ 8.7 available

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


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


This release contains numerous bug fixes, optimizations, and
improvements, some of which are highlighted below. The release is
available for immediate download at:


http://lucene.apache.org/core/mirrors-core-latest-redir.html


Lucene 8.7 Release Highlights:

Better compression of stored fields. Stored fields now use
dictionaries in order to improve the compression ratio when there is a
lot of redundancy across documents. This works for both the BEST_SPEED
and the BEST_COMPRESSION modes.


Faster sorting by field. When a doc-value field is also indexed with
points, Lucene now takes advantage of this points index in order to
skip documents whose sort value is not competitive.


Faster flushing of stored fields when index sorting is enabled. This
can significantly speed up indexing when a non-negligible amount of
data is stored in the index and index sorting is enabled.


Further details of changes are available in the change log available
at: https://lucene.apache.org/core/8_7_0/changes/Changes.html


Please report any feedback to the mailing lists
(http://lucene.apache.org/core/discussion.html)


Note: The Apache Software Foundation uses an extensive mirroring
network for distributing releases. It is possible that the mirror you
are using may not have replicated the release yet. If that is the
case, please try another mirror. This also applies to Maven access.


Note: The Apache Software Foundation uses an extensive mirroring network for

distributing releases. It is possible that the mirror you are using may not have

replicated the release yet. If that is the case, please try another mirror.

This also applies to Maven access.



-- 
Regards,

Atri
Apache Concerted

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

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

[Atri Sharma]

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


+1  7  (6 binding)

 0  0

-1  0


This vote has PASSED



Regards,

Atri


On Sat, Oct 31, 2020 at 3:38 AM Houston Putman  wrote:
>
> +1 (non-binding)
>
> SUCCESS! [1:02:05.573929]
>
> On Fri, Oct 30, 2020 at 4:56 PM Tomás Fernández Löbbe  
> wrote:
>>
>> +1
>>
>> SUCCESS! [1:03:01.296851]
>>
>> On Fri, Oct 30, 2020 at 12:05 PM Nhat Nguyen 
>>  wrote:
>>>
>>> +1 (binding)
>>> SUCCESS! [0:53:20.894728]
>>>
>>>
>>> On Fri, Oct 30, 2020 at 1:50 PM Michael McCandless 
>>>  wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>> SUCCESS! [0:45:49.703726]
>>>>
>>>>
>>>> Mike McCandless
>>>>
>>>> http://blog.mikemccandless.com
>>>>
>>>>
>>>> On Fri, Oct 30, 2020 at 8:04 AM Ignacio Vera  wrote:
>>>>>
>>>>> +1 SUCCESS! [1:42:16.864208]
>>>>>
>>>>> On Fri, Oct 30, 2020 at 12:13 PM Adrien Grand  wrote:
>>>>>>
>>>>>> +1 SUCCESS! [2:11:05.149743]
>>>>>>
>>>>>> On Fri, Oct 30, 2020 at 5:54 AM Atri Sharma  wrote:
>>>>>>>
>>>>>>> Please vote for release candidate 1 for Lucene/Solr 8.7.0
>>>>>>>
>>>>>>>
>>>>>>> The artifacts can be downloaded from:
>>>>>>>
>>>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
>>>>>>>
>>>>>>>
>>>>>>> You can run the smoke tester directly with this command:
>>>>>>>
>>>>>>>
>>>>>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>>>>>
>>>>>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.7.0-RC1-rev2dc63e901c60cda27ef3b744bc554f1481b3b067
>>>>>>>
>>>>>>>
>>>>>>> The vote will be open for at least 72 hours i.e. until 2020-11-01 20:00 
>>>>>>> UTC.
>>>>>>>
>>>>>>>
>>>>>>> [ ] +1  approve
>>>>>>>
>>>>>>> [ ] +0  no opinion
>>>>>>>
>>>>>>> [ ] -1  disapprove (and reason why)
>>>>>>>
>>>>>>>
>>>>>>> Here is my +1
>>>>>>>
>>>>>>> 
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Regards,
>>>>>>>
>>>>>>> Atri
>>>>>>> Apache Concerted
>>>>>>>
>>>>>>> -
>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>>>>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Adrien

-- 
Regards,

Atri
Apache Concerted

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

[VOTE] Release Lucene/Solr 8.7.0 RC1

[Atri Sharma]

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

Re: 8.7 Release Blockers

[Atri Sharma]

RC1 is in progress at the moment.

Atri

On Mon, Oct 26, 2020 at 11:55 PM Adrien Grand  wrote:
>
> Are there any blockers left?
>
> On Thu, Oct 22, 2020 at 11:14 PM Eric Pugh  
> wrote:
>>
>> If we get down to just SOLR-14067 holding us up, I think it could be moved 
>> to the next release.  I’ve made a lot of progress, but it may still take a 
>> few more days to get to done done.
>>
>> On Oct 22, 2020, at 4:35 PM, Adrien Grand  wrote:
>>
>> Can someone help review this PR to get the above blocker resolved? 
>> https://github.com/apache/lucene-solr/pull/2019
>>
>> On Thu, Oct 22, 2020 at 4:11 PM Atri Sharma  wrote:
>>>
>>> Reminder: This is still a blocker for 8.7:
>>>
>>> https://issues.apache.org/jira/browse/SOLR-14354
>>>
>>> On Tue, Oct 20, 2020 at 1:02 PM Atri Sharma  wrote:
>>> >
>>> > Hi All,
>>> >
>>> > Below are the issues marked as release blockers for 8.7. Can the
>>> > owners please resolve or move at the earliest?
>>> >
>>> > https://issues.apache.org/jira/browse/SOLR-14354
>>> > https://issues.apache.org/jira/browse/SOLR-13973
>>> > https://issues.apache.org/jira/browse/SOLR-14067
>>> >
>>> > Atri
>>> >
>>> > --
>>> > Regards,
>>> >
>>> > Atri
>>> > Apache Concerted
>>>
>>>
>>>
>>> --
>>> Regards,
>>>
>>> Atri
>>> Apache Concerted
>>>
>>> --
>>> Regards,
>>>
>>> Atri
>>> Apache Concerted
>>>
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>>
>>
>>
>> --
>> Adrien
>>
>>
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>> http://www.opensourceconnections.com | My Free/Busy
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed
>> This e-mail and all contents, including attachments, is considered to be 
>> Company Confidential unless explicitly stated otherwise, regardless of 
>> whether attachments are marked as such.
>>
>
>
> --
> Adrien

-- 
Regards,

Atri
Apache Concerted

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

Re: two 8x branches?

[Atri Sharma]

And, done.

On Sun, Oct 25, 2020 at 10:30 PM Atri Sharma  wrote:
>
> Yes, I will remove it tomorrow morning my time.
>
> On Sun, 25 Oct 2020 at 10:16 PM, Erick Erickson  
> wrote:
>>
>> We have two 8x branches,
>>
>>
>> origin/branch_8_x
>> origin/branch_8x
>>
>> Can someone remove/rename branch_8_x? I’ve managed to completely screw up my 
>> fork when trying to delete branches, so I’m not feeling confident when it 
>> comes to deleting branches on master...
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
> --
> Regards,
>
> Atri
> Apache Concerted



-- 
Regards,

Atri
Apache Concerted

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

Fixing 8.7 Section In solr/CHANGES.txt

[Atri Sharma]

Hi All,

I have raised a pull request to fix the merge issues in the 8.7
section of branch_8_7.

Please review asap and edit in the PR if any issues are seen (or let
me know and I will fix them).

https://github.com/apache/lucene-solr/pull/2030

-- 
Regards,

Atri
Apache Concerted

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

Re: two 8x branches?

[Atri Sharma]

Yes, I will remove it tomorrow morning my time.

On Sun, 25 Oct 2020 at 10:16 PM, Erick Erickson 
wrote:

> We have two 8x branches,
>
>
> origin/branch_8_x
> origin/branch_8x
>
> Can someone remove/rename branch_8_x? I’ve managed to completely screw up
> my fork when trying to delete branches, so I’m not feeling confident when
> it comes to deleting branches on master...
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> --
Regards,

Atri
Apache Concerted

Re: 8.7 Release

[Atri Sharma]

Thanks Shalin, I have been meaning to fix that.

On Sat, 24 Oct 2020 at 5:48 PM, Shalin Shekhar Mangar <
shalinman...@gmail.com> wrote:

> Also strangely, Solr's CHANGES.txt on branch_8x has two 8.7.0 sections!
>
> On Sat, Oct 24, 2020 at 5:40 PM Shalin Shekhar Mangar <
> shalinman...@gmail.com> wrote:
>
>> FYI - I have added a 8.8.0 section in Solr's change log on master as part
>> of SOLR-14942
>>
>> On Wed, Oct 21, 2020 at 1:36 PM Atri Sharma  wrote:
>>
>>> Please go ahead.
>>>
>>> I will add the section today. I believed the section is added once the
>>> RC1 is generated — but let me get this done. Thanks for pointing it out.
>>>
>>> On Wed, 21 Oct 2020 at 07:01, Houston Putman 
>>> wrote:
>>>
>>>> I will be committing SOLR-14907
>>>> <https://issues.apache.org/jira/browse/SOLR-14907> tomorrow, which
>>>> provides a V2 API for a feature that was added with a V1 endpoint. Would
>>>> you mind if I add this to branch_8_7 Atri?
>>>>
>>>> On a side note, I am making a PR for something that doesn't have to be
>>>> included in 8_7. I notice there isn't an 8.8.0 CHANGES.txt section yet in
>>>> master or 8x. The next minor/major version sections should get created when
>>>> minor/major version branches are cut, right? Please correct me if I'm wrong
>>>> on that. (I looked at the releaseWizard, and this looks like the case)
>>>>
>>>>
>>>> - Houston
>>>>
>>>> On Tue, Oct 20, 2020 at 5:36 AM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>>
>>>>> I have no bandwidth to tackle the deprecations, nor the energy to
>>>>> fight those who oppose it.
>>>>>
>>>>> On Tue, 20 Oct, 2020, 2:43 pm Atri Sharma,  wrote:
>>>>>
>>>>>> There are release blockers for 8_7:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SOLR-14354
>>>>>> https://issues.apache.org/jira/browse/SOLR-13973
>>>>>> https://issues.apache.org/jira/browse/SOLR-14067
>>>>>>
>>>>>> On Tue, Oct 20, 2020 at 1:23 PM Jan Høydahl 
>>>>>> wrote:
>>>>>> >
>>>>>> > I pushed SOLR-14936 that I mentioned yesterday - a non-code bugfix
>>>>>> for Grafana dashboard json.
>>>>>> >
>>>>>> > Jan
>>>>>> >
>>>>>> > 19. okt. 2020 kl. 19:19 skrev Adrien Grand :
>>>>>> >
>>>>>> > FYI I pushed a fix for a test-only bug introduced by LUCENE-9524.
>>>>>> >
>>>>>> > On Mon, Oct 19, 2020 at 2:47 PM Jan Høydahl 
>>>>>> wrote:
>>>>>> >>
>>>>>> >> I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change
>>>>>> which fixes a bug in grafana dashboard JSON.
>>>>>> >>
>>>>>> >> Jan
>>>>>> >>
>>>>>> >> > 19. okt. 2020 kl. 11:54 skrev Atri Sharma :
>>>>>> >> >
>>>>>> >> > Fixed the issue. Cherry picking to branch_8_7 now.
>>>>>> >> >
>>>>>> >> > Apologies, I must have created branch_8_x accidentally. Let me
>>>>>> delete.
>>>>>> >> >
>>>>>> >> > On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand 
>>>>>> wrote:
>>>>>> >> >>
>>>>>> >> >> 1. This is failing 8.7 builds, e.g.
>>>>>> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console,
>>>>>> so yes we should backport to 8.7.
>>>>>> >> >> By the way I don't understand why you created a branch_8_x
>>>>>> branch in addition to branch_8x, was it a mistake? The release wizard
>>>>>> doesn't seem to be recommending something like that?
>>>>>> >> >>
>>>>>> >> >> 2. Yes this is actually the point of cutting a branch, this
>>>>>> helps reduce chances of introducing blockers while we're working on
>>>>>> addressing the existing blockers.
>>>>>> >> >>
>>>>>> >> >> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma 
>>>>>> wrote:
>>>>

Re: 8.7 Release Blockers

[Atri Sharma]

Reminder: This is still a blocker for 8.7:

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

On Tue, Oct 20, 2020 at 1:02 PM Atri Sharma  wrote:
>
> Hi All,
>
> Below are the issues marked as release blockers for 8.7. Can the
> owners please resolve or move at the earliest?
>
> https://issues.apache.org/jira/browse/SOLR-14354
> https://issues.apache.org/jira/browse/SOLR-13973
> https://issues.apache.org/jira/browse/SOLR-14067
>
> Atri
>
> --
> Regards,
>
> Atri
> Apache Concerted



-- 
Regards,

Atri
Apache Concerted

-- 
Regards,

Atri
Apache Concerted

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

Re: 8.6.3 Release

[Atri Sharma]

Fair point -- I have changed accordingly.

On Thu, Oct 22, 2020 at 7:09 PM Cassandra Targett  wrote:
>
> That’s a fair thing to consider, but does it really matter if someone looks 
> at the draft notes pre-release? What would be the harm if users happen across 
> them before they’re done?
>
> (And to David’s point, it’s not in the RM steps to fix the page name after 
> release, so it’s pretty easy to forget to do it.)
> On Oct 22, 2020, 8:31 AM -0500, Atri Sharma , wrote:
>
> I added it since it looked a safe way to indicate that the draft notes
> are in progress and should not be referred to in case somebody is
> surfing the release notes.
>
> Atri
>
> On Thu, Oct 22, 2020 at 6:23 PM David Smiley  wrote:
>
>
> Jason: This is the first time I recall seeing release note pages in 
> Confluence with a "DRAFT-" prefix. And I also see that Atri has follow-ed 
> suit (following your lead, no doubt) for 8.6. Why? Looking at the page 
> navigation, it's clearly an oddity -- a change. And it's still DRAFT despite 
> it being released.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Thu, Oct 1, 2020 at 10:28 AM Jason Gerlowski  wrote:
>
>
> I've put together draft Release Notes for 8.6.3 here. [1] [2]. Can
> someone please sanity check the summaries there when they get a
> chance? Would appreciate the review.
>
> 8.6.3 is a bit interesting in that Lucene has no changes in this
> bugfix release. As a result I had to omit the standard phrase in the
> Solr release notes about there being additional changes at the Lucene
> level, and change some of the wording in the Lucene announcement to
> indicate the lack of changes. So that's something to pay particular
> attention to, if someone can check my wording there.
>
> [1] https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote863
> [2] https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote863
>
> On Wed, Sep 30, 2020 at 10:57 AM Jason Gerlowski  
> wrote:
>
>
> The only one that was previously mentioned as a blocker was
> SOLR-14835, but from the comments on the ticket it looks like it ended
> up being purely a cosmetic issue. Andrzej left a comment there
> suggesting that we "address" this with documentation for 8.6.3 but
> otherwise leave it as-is.
>
> So it looks like we're unblocked on starting the release process.
> Will begin the preliminary steps this afternoon.
>
> On Tue, Sep 29, 2020 at 3:40 PM Cassandra Targett  
> wrote:
>
>
> It looks to me like everything for 8.6.3 is resolved now 
> (https://issues.apache.org/jira/projects/SOLR/versions/12348713), and it 
> seems from comments in SOLR-14897 and SOLR-14898 that those fixes make a 
> Jetty upgrade less compelling to try.
>
> Are there any other issues not currently marked for 8.6.3 we’re waiting for 
> before starting the RC?
> On Sep 29, 2020, 12:04 PM -0500, Jason Gerlowski , 
> wrote:
>
> That said, if someone can use 8.6.3, what’s stopping them from going to 8.7 
> when it’e released?
>
>
> The same things that always stop users from going directly to the
> latest-and-greatest: fear of instability from new minor-release
> features, reliance on behavior changed across minor versions, breaking
> changes on Lucene elements that don't guarantee backcompat (e.g.
> SOLR-14254), security issues in later versions (new libraries pulled
> in with vulns), etc. There's lots of reasons a given user might want
> to stick on 8.6.x rather than 8.7 (in the short/medium term).
>
> I'm ambivalent to whether we upgrade Jetty in 8.6.3 - as I said above
> the worst of the Jetty issue should be mitigated by work on our end -
> but I think there's a lot of reasons users might not upgrade as far as
> we'd expect/like.
>
>
> On Mon, Sep 28, 2020 at 2:05 PM Erick Erickson  
> wrote:
>
>
> For me, there’s a sharp distinction between changing a dependency in a point 
> release just because there’s a new version, and changing the dependency 
> because there’s a bug in it. That said, if someone can use 8.6.3, what’s 
> stopping them from going to 8.7 when it’e released? Would it make more sense 
> to do the upgrades for 8.7 and get that out the door rather than backport?
>
> FWIW,
> Erick
>
> On Sep 28, 2020, at 1:45 PM, Jason Gerlowski  wrote:
>
> Hey all,
>
> I wanted to add 2 more blocker tickets to the list: SOLR-14897 and
> SOLR-14898. These tickets (while bad bugs in their own right) are
> especially necessary because they work around a Jetty buffer-reuse bug
> (see SOLR-14896) that causes sporadic request failures once triggered.
>
> So that brings the list of 8.6.3 blockers up to: SO

Re: 8.6.3 Release

[Atri Sharma]

r tickets to the list: SOLR-14897 and
>> > > SOLR-14898. These tickets (while bad bugs in their own right) are
>> > > especially necessary because they work around a Jetty buffer-reuse bug
>> > > (see SOLR-14896) that causes sporadic request failures once triggered.
>> > >
>> > > So that brings the list of 8.6.3 blockers up to: SOLR-14850,
>> > > SOLR-14835, SOLR-14897, and SOLR-14898. (Thanks David for the quick
>> > > work on SOLR-14768!)
>> > >
>> > > Additionally, should we also consider a Jetty upgrade for 8.6.3 in
>> > > light of the issue mentioned above? I know it's atypical for bug-fix
>> > > releases to change deps, but here the bug is serious and tied directly
>> > > to the dep. SOLR-14897 and SOLR-14898 help greatly here, but the
>> > > Jetty bug is likely still a problem for users making requests that
>> > > match a specific (albeit rare) profile. Anyone have thoughts?
>> > >
>> > > Best,
>> > >
>> > > Jason
>> > >
>> > > On Fri, Sep 25, 2020 at 12:28 AM Houston Putman 
>> > >  wrote:
>> > >
>> > >
>> > > If I recall correctly, thats a step in the release wizard.
>> > >
>> > > After checking, I think this fits the bill:
>> > > https://github.com/apache/lucene-solr/blob/master/dev-tools/scripts/releaseWizard.yaml#L1435
>> > >
>> > > - Houston
>> > >
>> > > On Fri, Sep 25, 2020 at 12:06 AM David Smiley  wrote:
>> > >
>> > >
>> > > When moving changes from 8.7 to 8.6.3, must we (the mover of an 
>> > > individual change) move the CHANGES.txt entry on all branches -- master, 
>> > > branch_8x, branch_8_6? I expect the release branch but am unsure of the 
>> > > other two. In the past I have but it's annoying. Does the RM sync 
>> > > CHANGES.txt on the other branches in one go? If not, I think it'd make 
>> > > sense for that to happen.
>> > >
>> > > ~ David Smiley
>> > > Apache Lucene/Solr Search Developer
>> > > http://www.linkedin.com/in/davidwsmiley
>> > >
>> > >
>> > > On Thu, Sep 24, 2020 at 6:22 AM Atri Sharma  wrote:
>> > >
>> > >
>> > > I will push the 8.7 release by a week to give Jason enough headroom to
>> > >
>> > >
>> > > do the 8.6.3 release.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Jason, let me know if you need me to assist on the 8.6.3 release.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Sep 24, 2020 at 3:23 PM Jason Gerlowski  
>> > > wrote:
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > OK, in that case I'll try my best to keep the 8.6.3 process moving
>> > >
>> > >
>> > >
>> > > then, so Atri can stick as close to his proposed schedule as possible.
>> > >
>> > >
>> > >
>> > > My apologies - I didn't realize I'd be putting the brakes on 8.7 by
>> > >
>> > >
>> > >
>> > > proposing a bug-fix release. But the reasons make sense given what
>> > >
>> > >
>> > >
>> > > others mentioned above.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > As branch_8_6 should be pretty stable by now I wonder if we really need 
>> > > to wait one week?
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > There's no special reason on my end. I suggested a week to give
>> > >
>> > >
>> > >
>> > > others time to backport anything they wanted included, but I'm happy
>> > >
>> > >
>> > >
>> > > to start the process as soon as all the expected changes land.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Best,
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > Jason
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > On Thu, Sep 24, 2020 at 1:48 AM Anshum Gupta  
>

Re: Seeking Inputs for Release Highlights

[Atri Sharma]

Hi Adrien,

Please find below:

https://cwiki.apache.org/confluence/display/SOLR/DRAFT-ReleaseNote87
https://cwiki.apache.org/confluence/display/LUCENE/DRAFT-ReleaseNote87

On Thu, Oct 22, 2020 at 4:37 PM Adrien Grand  wrote:
>
> Hi Atri, if you can create a page in the wiki, I'll be happy to add some 
> items to the release highlights. I have the compression for stored fields 
> improvements in mind as well as the speedups for queries sorted by a field 
> indexed with points.
>
> On Thu, Oct 22, 2020 at 12:54 PM Atri Sharma  wrote:
>>
>> Hi All,
>>
>> Can we come up with the items we wish to highlight in 8.7 release notes?
>>
>> Atri
>>
>> --
>> Regards,
>>
>> Atri
>> Apache Concerted
>>
>> -
>> 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

Seeking Inputs for Release Highlights

[Atri Sharma]

Hi All,

Can we come up with the items we wish to highlight in 8.7 release notes?

Atri

-- 
Regards,

Atri
Apache Concerted

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

Re: 8.7 Release

[Atri Sharma]

Please go ahead.

I will add the section today. I believed the section is added once the RC1
is generated — but let me get this done. Thanks for pointing it out.

On Wed, 21 Oct 2020 at 07:01, Houston Putman 
wrote:

> I will be committing SOLR-14907
> <https://issues.apache.org/jira/browse/SOLR-14907> tomorrow, which
> provides a V2 API for a feature that was added with a V1 endpoint. Would
> you mind if I add this to branch_8_7 Atri?
>
> On a side note, I am making a PR for something that doesn't have to be
> included in 8_7. I notice there isn't an 8.8.0 CHANGES.txt section yet in
> master or 8x. The next minor/major version sections should get created when
> minor/major version branches are cut, right? Please correct me if I'm wrong
> on that. (I looked at the releaseWizard, and this looks like the case)
>
>
> - Houston
>
> On Tue, Oct 20, 2020 at 5:36 AM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> I have no bandwidth to tackle the deprecations, nor the energy to fight
>> those who oppose it.
>>
>> On Tue, 20 Oct, 2020, 2:43 pm Atri Sharma,  wrote:
>>
>>> There are release blockers for 8_7:
>>>
>>> https://issues.apache.org/jira/browse/SOLR-14354
>>> https://issues.apache.org/jira/browse/SOLR-13973
>>> https://issues.apache.org/jira/browse/SOLR-14067
>>>
>>> On Tue, Oct 20, 2020 at 1:23 PM Jan Høydahl 
>>> wrote:
>>> >
>>> > I pushed SOLR-14936 that I mentioned yesterday - a non-code bugfix for
>>> Grafana dashboard json.
>>> >
>>> > Jan
>>> >
>>> > 19. okt. 2020 kl. 19:19 skrev Adrien Grand :
>>> >
>>> > FYI I pushed a fix for a test-only bug introduced by LUCENE-9524.
>>> >
>>> > On Mon, Oct 19, 2020 at 2:47 PM Jan Høydahl 
>>> wrote:
>>> >>
>>> >> I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change which
>>> fixes a bug in grafana dashboard JSON.
>>> >>
>>> >> Jan
>>> >>
>>> >> > 19. okt. 2020 kl. 11:54 skrev Atri Sharma :
>>> >> >
>>> >> > Fixed the issue. Cherry picking to branch_8_7 now.
>>> >> >
>>> >> > Apologies, I must have created branch_8_x accidentally. Let me
>>> delete.
>>> >> >
>>> >> > On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand 
>>> wrote:
>>> >> >>
>>> >> >> 1. This is failing 8.7 builds, e.g.
>>> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console,
>>> so yes we should backport to 8.7.
>>> >> >> By the way I don't understand why you created a branch_8_x branch
>>> in addition to branch_8x, was it a mistake? The release wizard doesn't seem
>>> to be recommending something like that?
>>> >> >>
>>> >> >> 2. Yes this is actually the point of cutting a branch, this helps
>>> reduce chances of introducing blockers while we're working on addressing
>>> the existing blockers.
>>> >> >>
>>> >> >> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma 
>>> wrote:
>>> >> >>>
>>> >> >>> BTw, guidance needed:
>>> >> >>>
>>> >> >>> 1. The doc fixes I need to do for this, should I be backporting
>>> them to branch_8_7, or apply them to branch_8_x and cut a new branch?
>>> >> >>>
>>> >> >>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it
>>> valid to be cutting a branch before those are resolved?
>>> >> >>>
>>> >> >>> Atri
>>> >> >>>
>>> >> >>> On Mon, 19 Oct 2020 at 01:14, Atri Sharma 
>>> wrote:
>>> >> >>>>
>>> >> >>>> Let me take a look tomorrow morning — must be something I broke
>>> in the cherry pick.
>>> >> >>>>
>>> >> >>>> On Mon, 19 Oct 2020 at 00:58, David Smiley 
>>> wrote:
>>> >> >>>>>
>>> >> >>>>> I don't know.  I searched for "missing description:
>>> org.apache.solr.util.circuitbreaker" in my email (covering our builds), and
>>> this started happening October 16th (2 days ago) on 8.x (not master).
>>> >> >>>>>
>>> >> >>>>> ~ David Smiley
>>> >> >>

Re: 8.7 Release

[Atri Sharma]

There are release blockers for 8_7:

https://issues.apache.org/jira/browse/SOLR-14354
https://issues.apache.org/jira/browse/SOLR-13973
https://issues.apache.org/jira/browse/SOLR-14067

On Tue, Oct 20, 2020 at 1:23 PM Jan Høydahl  wrote:
>
> I pushed SOLR-14936 that I mentioned yesterday - a non-code bugfix for 
> Grafana dashboard json.
>
> Jan
>
> 19. okt. 2020 kl. 19:19 skrev Adrien Grand :
>
> FYI I pushed a fix for a test-only bug introduced by LUCENE-9524.
>
> On Mon, Oct 19, 2020 at 2:47 PM Jan Høydahl  wrote:
>>
>> I’d like to merge in SOLR-14936 to 8.7. It’s a non-code change which fixes a 
>> bug in grafana dashboard JSON.
>>
>> Jan
>>
>> > 19. okt. 2020 kl. 11:54 skrev Atri Sharma :
>> >
>> > Fixed the issue. Cherry picking to branch_8_7 now.
>> >
>> > Apologies, I must have created branch_8_x accidentally. Let me delete.
>> >
>> > On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand  wrote:
>> >>
>> >> 1. This is failing 8.7 builds, e.g. 
>> >> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, 
>> >> so yes we should backport to 8.7.
>> >> By the way I don't understand why you created a branch_8_x branch in 
>> >> addition to branch_8x, was it a mistake? The release wizard doesn't seem 
>> >> to be recommending something like that?
>> >>
>> >> 2. Yes this is actually the point of cutting a branch, this helps reduce 
>> >> chances of introducing blockers while we're working on addressing the 
>> >> existing blockers.
>> >>
>> >> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma  wrote:
>> >>>
>> >>> BTw, guidance needed:
>> >>>
>> >>> 1. The doc fixes I need to do for this, should I be backporting them to 
>> >>> branch_8_7, or apply them to branch_8_x and cut a new branch?
>> >>>
>> >>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be 
>> >>> cutting a branch before those are resolved?
>> >>>
>> >>> Atri
>> >>>
>> >>> On Mon, 19 Oct 2020 at 01:14, Atri Sharma  wrote:
>> >>>>
>> >>>> Let me take a look tomorrow morning — must be something I broke in the 
>> >>>> cherry pick.
>> >>>>
>> >>>> On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:
>> >>>>>
>> >>>>> I don't know.  I searched for "missing description: 
>> >>>>> org.apache.solr.util.circuitbreaker" in my email (covering our 
>> >>>>> builds), and this started happening October 16th (2 days ago) on 8.x 
>> >>>>> (not master).
>> >>>>>
>> >>>>> ~ David Smiley
>> >>>>> Apache Lucene/Solr Search Developer
>> >>>>> http://www.linkedin.com/in/davidwsmiley
>> >>>>>
>> >>>>>
>> >>>>> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  wrote:
>> >>>>>>
>> >>>>>> Surprisingly it doesn’t fail for me? Local caching?
>> >>>>>>
>> >>>>>> On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:
>> >>>>>>>
>> >>>>>>> BTW on branch_8x, I see that "ant precommit" fails:
>> >>>>>>>
>> >>>>>>> -documentation-lint:
>> >>>>>>>    [jtidy] Checking for broken html (such as invalid tags)...
>> >>>>>>>   [delete] Deleting directory 
>> >>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>> >>>>>>> [echo] Checking for broken links...
>> >>>>>>> [exec]
>> >>>>>>> [exec] Crawl/parse...
>> >>>>>>> [exec]
>> >>>>>>> [exec] Verify...
>> >>>>>>> [echo] Checking for malformed docs...
>> >>>>>>> [exec]
>> >>>>>>> [exec] 
>> >>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>> >>>>>>> [exec]   missing description: org.apache.solr.util.circuitbreaker
>> >>>>>>> [exec]
>> >>>>>>> [exec] Missing javadocs were found!
>> >>>

8.7 Release Blockers

[Atri Sharma]

Hi All,

Below are the issues marked as release blockers for 8.7. Can the
owners please resolve or move at the earliest?

https://issues.apache.org/jira/browse/SOLR-14354
https://issues.apache.org/jira/browse/SOLR-13973
https://issues.apache.org/jira/browse/SOLR-14067

Atri

-- 
Regards,

Atri
Apache Concerted

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

Re: 8.7 Release

[Atri Sharma]

ab,

Please proceed to commit to 8x and 8_.

On Mon, Oct 19, 2020 at 3:24 PM Andrzej Białecki  wrote:
>
> Atri,
>
> I’d like to add a notice in 8.7.0 (no code change) to CHANGES.txt about the 
> deprecation of the spinning disk detection (LUCENE-9576 and SOLR-14930).
>
>
> On 19 Oct 2020, at 05:55, David Smiley  wrote:
>
> Given how recent branch_8_7 was cut, I don't think a RC should be released 
> Monday.  At least one extra day would be prudent.  Just my 2-cents.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Oct 18, 2020 at 4:11 PM Adrien Grand  wrote:
>>
>> 1. This is failing 8.7 builds, e.g. 
>> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, so 
>> yes we should backport to 8.7.
>> By the way I don't understand why you created a branch_8_x branch in 
>> addition to branch_8x, was it a mistake? The release wizard doesn't seem to 
>> be recommending something like that?
>>
>> 2. Yes this is actually the point of cutting a branch, this helps reduce 
>> chances of introducing blockers while we're working on addressing the 
>> existing blockers.
>>
>> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma  wrote:
>>>
>>> BTw, guidance needed:
>>>
>>> 1. The doc fixes I need to do for this, should I be backporting them to 
>>> branch_8_7, or apply them to branch_8_x and cut a new branch?
>>>
>>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be 
>>> cutting a branch before those are resolved?
>>>
>>> Atri
>>>
>>> On Mon, 19 Oct 2020 at 01:14, Atri Sharma  wrote:
>>>>
>>>> Let me take a look tomorrow morning — must be something I broke in the 
>>>> cherry pick.
>>>>
>>>> On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:
>>>>>
>>>>> I don't know.  I searched for "missing description: 
>>>>> org.apache.solr.util.circuitbreaker" in my email (covering our builds), 
>>>>> and this started happening October 16th (2 days ago) on 8.x (not master).
>>>>>
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>
>>>>>
>>>>> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  wrote:
>>>>>>
>>>>>> Surprisingly it doesn’t fail for me? Local caching?
>>>>>>
>>>>>> On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:
>>>>>>>
>>>>>>> BTW on branch_8x, I see that "ant precommit" fails:
>>>>>>>
>>>>>>> -documentation-lint:
>>>>>>> [jtidy] Checking for broken html (such as invalid tags)...
>>>>>>>[delete] Deleting directory 
>>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>>>>>>>  [echo] Checking for broken links...
>>>>>>>  [exec]
>>>>>>>  [exec] Crawl/parse...
>>>>>>>  [exec]
>>>>>>>  [exec] Verify...
>>>>>>>  [echo] Checking for malformed docs...
>>>>>>>  [exec]
>>>>>>>  [exec] 
>>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>>>>>>>  [exec]   missing description: org.apache.solr.util.circuitbreaker
>>>>>>>  [exec]
>>>>>>>  [exec] Missing javadocs were found!
>>>>>>>
>>>>>>> That package is missing a "package-info.java".  It's been this way for 
>>>>>>> a while... I wonder why it hasn't been noticed by others yet?
>>>>>>>
>>>>>>> ~ David Smiley
>>>>>>> Apache Lucene/Solr Search Developer
>>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma  wrote:
>>>>>>>>
>>>>>>>> I will start the first build candidate on upcoming Monday. This is my
>>>>>>>> first release so fingers crossed :)
>>>>>>>>
>>>>>>>> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
>>>>>>>> >
>>>>>>>&

Re: 8.7 Release

[Atri Sharma]

Fixed the issue. Cherry picking to branch_8_7 now.

Apologies, I must have created branch_8_x accidentally. Let me delete.

On Mon, Oct 19, 2020 at 1:40 AM Adrien Grand  wrote:
>
> 1. This is failing 8.7 builds, e.g. 
> https://builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.7/3/console, so 
> yes we should backport to 8.7.
> By the way I don't understand why you created a branch_8_x branch in addition 
> to branch_8x, was it a mistake? The release wizard doesn't seem to be 
> recommending something like that?
>
> 2. Yes this is actually the point of cutting a branch, this helps reduce 
> chances of introducing blockers while we're working on addressing the 
> existing blockers.
>
> On Sun, Oct 18, 2020 at 9:50 PM Atri Sharma  wrote:
>>
>> BTw, guidance needed:
>>
>> 1. The doc fixes I need to do for this, should I be backporting them to 
>> branch_8_7, or apply them to branch_8_x and cut a new branch?
>>
>> 2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be 
>> cutting a branch before those are resolved?
>>
>> Atri
>>
>> On Mon, 19 Oct 2020 at 01:14, Atri Sharma  wrote:
>>>
>>> Let me take a look tomorrow morning — must be something I broke in the 
>>> cherry pick.
>>>
>>> On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:
>>>>
>>>> I don't know.  I searched for "missing description: 
>>>> org.apache.solr.util.circuitbreaker" in my email (covering our builds), 
>>>> and this started happening October 16th (2 days ago) on 8.x (not master).
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  wrote:
>>>>>
>>>>> Surprisingly it doesn’t fail for me? Local caching?
>>>>>
>>>>> On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:
>>>>>>
>>>>>> BTW on branch_8x, I see that "ant precommit" fails:
>>>>>>
>>>>>> -documentation-lint:
>>>>>> [jtidy] Checking for broken html (such as invalid tags)...
>>>>>>[delete] Deleting directory 
>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>>>>>>  [echo] Checking for broken links...
>>>>>>  [exec]
>>>>>>  [exec] Crawl/parse...
>>>>>>  [exec]
>>>>>>  [exec] Verify...
>>>>>>  [echo] Checking for malformed docs...
>>>>>>  [exec]
>>>>>>  [exec] 
>>>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>>>>>>  [exec]   missing description: org.apache.solr.util.circuitbreaker
>>>>>>  [exec]
>>>>>>  [exec] Missing javadocs were found!
>>>>>>
>>>>>> That package is missing a "package-info.java".  It's been this way for a 
>>>>>> while... I wonder why it hasn't been noticed by others yet?
>>>>>>
>>>>>> ~ David Smiley
>>>>>> Apache Lucene/Solr Search Developer
>>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>>>
>>>>>>
>>>>>> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma  wrote:
>>>>>>>
>>>>>>> I will start the first build candidate on upcoming Monday. This is my
>>>>>>> first release so fingers crossed :)
>>>>>>>
>>>>>>> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
>>>>>>> >
>>>>>>> > Thanks Atri. Do you know when you will start the first build 
>>>>>>> > candidate as well? We had been doing some planning around Ishan's 
>>>>>>> > initial suggestion of cutting the branch on September 20th, so as 
>>>>>>> > this is getting delayed I'm trying to get a sense of whether the 
>>>>>>> > release would likely be out in the next two weeks.
>>>>>>> >
>>>>>>> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:
>>>>>>> >>
>>>>>>> >> Adrien,
>>>>>>> >>
>>>>>>> >> Sorry for the delay in response.
>>>>>>> >>
>

Re: 8.7 Release

[Atri Sharma]

BTw, guidance needed:

1. The doc fixes I need to do for this, should I be backporting them to
branch_8_7, or apply them to branch_8_x and cut a new branch?

2. I still see blocker issues on 8.7 (thanks Ishan!) — is it valid to be
cutting a branch before those are resolved?

Atri

On Mon, 19 Oct 2020 at 01:14, Atri Sharma  wrote:

> Let me take a look tomorrow morning — must be something I broke in the
> cherry pick.
>
> On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:
>
>> I don't know.  I searched for "missing description:
>> org.apache.solr.util.circuitbreaker" in my email (covering our builds), and
>> this started happening October 16th (2 days ago) on 8.x (not master).
>>
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>>
>>
>> On Sun, Oct 18, 2020 at 2:34 PM Atri Sharma  wrote:
>>
>>> Surprisingly it doesn’t fail for me? Local caching?
>>>
>>> On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:
>>>
>>>> BTW on branch_8x, I see that "ant precommit" fails:
>>>>
>>>> -documentation-lint:
>>>> [jtidy] Checking for broken html (such as invalid tags)...
>>>>[delete] Deleting directory
>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>>>>  [echo] Checking for broken links...
>>>>  [exec]
>>>>  [exec] Crawl/parse...
>>>>  [exec]
>>>>  [exec] Verify...
>>>>  [echo] Checking for malformed docs...
>>>>  [exec]
>>>>  [exec]
>>>> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>>>>  [exec]   missing description: org.apache.solr.util.circuitbreaker
>>>>  [exec]
>>>>  [exec] Missing javadocs were found!
>>>>
>>>> That package is missing a "package-info.java".  It's been this way for
>>>> a while... I wonder why it hasn't been noticed by others yet?
>>>>
>>>> ~ David Smiley
>>>> Apache Lucene/Solr Search Developer
>>>> http://www.linkedin.com/in/davidwsmiley
>>>>
>>>>
>>>> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma  wrote:
>>>>
>>>>> I will start the first build candidate on upcoming Monday. This is my
>>>>> first release so fingers crossed :)
>>>>>
>>>>> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand 
>>>>> wrote:
>>>>> >
>>>>> > Thanks Atri. Do you know when you will start the first build
>>>>> candidate as well? We had been doing some planning around Ishan's initial
>>>>> suggestion of cutting the branch on September 20th, so as this is getting
>>>>> delayed I'm trying to get a sense of whether the release would likely be
>>>>> out in the next two weeks.
>>>>> >
>>>>> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma 
>>>>> wrote:
>>>>> >>
>>>>> >> Adrien,
>>>>> >>
>>>>> >> Sorry for the delay in response.
>>>>> >>
>>>>> >> I will cut the branch this Friday morning (IST).
>>>>> >>
>>>>> >> Atri
>>>>> >>
>>>>> >> On Tue, 13 Oct 2020 at 05:43, Houston Putman <
>>>>> houstonput...@gmail.com> wrote:
>>>>> >>>
>>>>> >>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If
>>>>> you would mind waiting to cut 8.7 until then, I would appreciate it.
>>>>> >>>
>>>>> >>> - Houston
>>>>> >>>
>>>>> >>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand 
>>>>> wrote:
>>>>> >>>>
>>>>> >>>> Shall we move forward with 8.7 now that 8.6.3 is out?
>>>>> >>>>
>>>>> >>>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma 
>>>>> wrote:
>>>>> >>>>>
>>>>> >>>>> I plan to cut the branch on 30th September.
>>>>> >>>>>
>>>>> >>>>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett <
>>>>> casstarg...@gmail.com> wrote:
>>>>> >>>>>&g

Re: 8.7 Release

[Atri Sharma]

Let me take a look tomorrow morning — must be something I broke in the
cherry pick.

On Mon, 19 Oct 2020 at 00:58, David Smiley  wrote:

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

Re: 8.7 Release

[Atri Sharma]

Surprisingly it doesn’t fail for me? Local caching?

On Sun, 18 Oct 2020 at 23:08, David Smiley  wrote:

> BTW on branch_8x, I see that "ant precommit" fails:
>
> -documentation-lint:
> [jtidy] Checking for broken html (such as invalid tags)...
>[delete] Deleting directory
> /Users/dsmiley/DevSearch/lucene-solr_8x/lucene/build/jtidy_tmp
>  [echo] Checking for broken links...
>  [exec]
>  [exec] Crawl/parse...
>  [exec]
>  [exec] Verify...
>  [echo] Checking for malformed docs...
>  [exec]
>  [exec]
> /Users/dsmiley/DevSearch/lucene-solr_8x/solr/build/docs/solr-core/overview-summary.html
>  [exec]   missing description: org.apache.solr.util.circuitbreaker
>  [exec]
>  [exec] Missing javadocs were found!
>
> That package is missing a "package-info.java".  It's been this way for a
> while... I wonder why it hasn't been noticed by others yet?
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Oct 13, 2020 at 12:06 PM Atri Sharma  wrote:
>
>> I will start the first build candidate on upcoming Monday. This is my
>> first release so fingers crossed :)
>>
>> On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
>> >
>> > Thanks Atri. Do you know when you will start the first build candidate
>> as well? We had been doing some planning around Ishan's initial suggestion
>> of cutting the branch on September 20th, so as this is getting delayed I'm
>> trying to get a sense of whether the release would likely be out in the
>> next two weeks.
>> >
>> > On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:
>> >>
>> >> Adrien,
>> >>
>> >> Sorry for the delay in response.
>> >>
>> >> I will cut the branch this Friday morning (IST).
>> >>
>> >> Atri
>> >>
>> >> On Tue, 13 Oct 2020 at 05:43, Houston Putman 
>> wrote:
>> >>>
>> >>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If
>> you would mind waiting to cut 8.7 until then, I would appreciate it.
>> >>>
>> >>> - Houston
>> >>>
>> >>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand 
>> wrote:
>> >>>>
>> >>>> Shall we move forward with 8.7 now that 8.6.3 is out?
>> >>>>
>> >>>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>> >>>>>
>> >>>>> I plan to cut the branch on 30th September.
>> >>>>>
>> >>>>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett <
>> casstarg...@gmail.com> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Atri,
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Just so I understand your plans, when you say you are planning to
>> start the process at the end of this month, you mean you intend to create
>> the branch around Oct 1? No pressure, I ask only because Ishan’s original
>> mail mentioned cutting the branch this week and I just wanted to have a
>> clearer sense of your timeline.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> Thanks,
>> >>>>>>
>> >>>>>>
>> >>>>>> Cassandra
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma ,
>> wrote:
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> I was planning to start the process end of this month.
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>

Re: Branch 8.7

[Atri Sharma]

The branch is cut off.

On Fri, Oct 16, 2020 at 11:06 PM Atri Sharma  wrote:
>
> I am running precommit on the branch 8_x right now -- once it
> completes, I will cut the branch 8.7.
>
> --
> Regards,
>
> Atri
> Apache Concerted



-- 
Regards,

Atri
Apache Concerted

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

Branch 8.7

[Atri Sharma]

I am running precommit on the branch 8_x right now -- once it
completes, I will cut the branch 8.7.

-- 
Regards,

Atri
Apache Concerted

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

Re: 8.7 Release

[Atri Sharma]

I will start the first build candidate on upcoming Monday. This is my
first release so fingers crossed :)

On Tue, Oct 13, 2020 at 7:01 PM Adrien Grand  wrote:
>
> Thanks Atri. Do you know when you will start the first build candidate as 
> well? We had been doing some planning around Ishan's initial suggestion of 
> cutting the branch on September 20th, so as this is getting delayed I'm 
> trying to get a sense of whether the release would likely be out in the next 
> two weeks.
>
> On Tue, Oct 13, 2020 at 12:10 PM Atri Sharma  wrote:
>>
>> Adrien,
>>
>> Sorry for the delay in response.
>>
>> I will cut the branch this Friday morning (IST).
>>
>> Atri
>>
>> On Tue, 13 Oct 2020 at 05:43, Houston Putman  wrote:
>>>
>>> Adrien, I plan on merging SOLR-14907 to master and 8x tomorrow. If you 
>>> would mind waiting to cut 8.7 until then, I would appreciate it.
>>>
>>> - Houston
>>>
>>> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:
>>>>
>>>> Shall we move forward with 8.7 now that 8.6.3 is out?
>>>>
>>>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>>>>>
>>>>> I plan to cut the branch on 30th September.
>>>>>
>>>>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett  
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Atri,
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Just so I understand your plans, when you say you are planning to start 
>>>>>> the process at the end of this month, you mean you intend to create the 
>>>>>> branch around Oct 1? No pressure, I ask only because Ishan’s original 
>>>>>> mail mentioned cutting the branch this week and I just wanted to have a 
>>>>>> clearer sense of your timeline.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>> Cassandra
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> I was planning to start the process end of this month.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>>>>>>
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Unless it somehow got lost in a spam filter somewhere, I don't think we 
>>>>>>> have set a target date for the release yet? (roadmap says autumn 2020 
>>>>>>> which technically doesn't begin until the solstice on the 21st :) )
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Hoping that I might still get the Advanced Query parser in first, but 
>>>>>>> that's a much bigger prospect than these two tickets.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> -Gus
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher  
>>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Unless there are objections, I'm gonna get 
>>>>>>>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>>>>>>>
>>>>>>>>

Re: 8.7 Release

[Atri Sharma]

Adrien,

Sorry for the delay in response.

I will cut the branch this Friday morning (IST).

Atri

On Tue, 13 Oct 2020 at 05:43, Houston Putman 
wrote:

> Adrien, I plan on merging SOLR-14907
> <https://issues.apache.org/jira/browse/SOLR-14907> to master and 8x
> tomorrow. If you would mind waiting to cut 8.7 until then, I would
> appreciate it.
>
> - Houston
>
> On Mon, Oct 12, 2020 at 4:59 AM Adrien Grand  wrote:
>
>> Shall we move forward with 8.7 now that 8.6.3 is out?
>>
>> On Tue, Sep 22, 2020 at 9:32 PM Atri Sharma  wrote:
>>
>>> I plan to cut the branch on 30th September.
>>>
>>> On Wed, 23 Sep 2020 at 00:51, Cassandra Targett 
>>> wrote:
>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Atri,
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Just so I understand your plans, when you say you are planning to start
>>>> the process at the end of this month, you mean you intend to create the
>>>> branch around Oct 1? No pressure, I ask only because Ishan’s original mail
>>>> mentioned cutting the branch this week and I just wanted to have a clearer
>>>> sense of your timeline.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Thanks,
>>>>
>>>>
>>>> Cassandra
>>>>
>>>>
>>>>
>>>>
>>>> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>>>>
>>>>
>>>>
>>>>
>>>> I was planning to start the process end of this month.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>> Unless it somehow got lost in a spam filter somewhere, I don't think
>>>>> we have set a target date for the release yet? (roadmap says autumn 2020
>>>>> which technically doesn't begin until the solstice on the 21st :) )
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hoping that I might still get the Advanced Query parser in first, but
>>>>> that's a much bigger prospect than these two tickets.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> -Gus
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
>>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Unless there are objections, I'm gonna get
>>>>>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Erik
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON)
>>>>>>  wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> With a view towards including it in the release, I'd appreciate input
>>>>>> on the
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/SOLR-14828
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> solrj logging tweak if anyone has a moment?
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>>
>>>>>> Christine
>>>>>>
>>>>>>
>>>&g

Re: Hacktoberfest

[Atri Sharma]

>From my previous experiences, Hacktoberfest tends to lead to a lot of spam
which can IMO tarnish the overall quality of PRs of the project.

There is a Twitter handle (@shitoberfest) that highlights this...

On Sat, 10 Oct 2020 at 19:05, David Smiley  wrote:

> There is this open-source contribution incentive thing called
> "Hacktoberfest" --
> https://hacktoberfest.digitalocean.com
> If we merely add the "hacktoberfest" label to our GitHub repo here:
> https://github.com/apache/lucene-solr/blob/master/.asf.yaml
> then we may see some additional PR based contributions to Lucene/Solr.
> If a PR contributor mentions Hacktoberfest, we also then add the
> "hacktoberfest-accepted" label to the PR itself.  Example:
> https://github.com/apache/lucene-solr/pull/1970  That PR is what exposed
> me to this program.
>
> Can I get another PMC's +1 to the idea and I'll just edit our labels?
>
> "Risks" are perhaps more PRs/contributions than we are used to, some may
> be typo in nature, and probably without JIRA issues.  Granted, trivial ones
> don't need JIRA issues anyway.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> --
Regards,

Atri
Apache Concerted

Re: [VOTE] Release Lucene/Solr 8.6.3 RC1

[Atri Sharma]

+1 (binding)

SUCCESS! [1:04.32.39193]

On Sun, Oct 4, 2020 at 7:24 AM Jason Gerlowski  wrote:
>
> Please vote for release candidate 1 for Lucene/Solr 8.6.3
>
>
> The artifacts can be downloaded from:
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>
>
> You can run the smoke tester directly with this command:
>
>
> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.3-RC1-reve001c2221812a0ba9e9378855040ce72f93eced4
>
>
> The vote will be open for at least 72 hours i.e. until 2020-10-07 02:00 UTC.
>
>
> [ ] +1  approve
>
> [ ] +0  no opinion
>
> [ ] -1  disapprove (and reason why)
>
>
> Here is my +1

-- 
Regards,

Atri
Apache Concerted

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

Re: 8.6.3 Release

[Atri Sharma]

I will push the 8.7 release by a week to give Jason enough headroom to
do the 8.6.3 release.

Jason, let me know if you need me to assist on the 8.6.3 release.

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


-- 
Regards,

Atri
Apache Concerted

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

Re: 8.6.3 Release

[Atri Sharma]

I am not sure if two close releases are a good idea — would they not lead
to potential confusion amongst users?

In any case, I will defer to the opinion of committers.

On Wed, 23 Sep 2020 at 23:46, Jason Gerlowski  wrote:

> > do we want to delay that?
>
>
>
> It wasn't my intention to delay 8.7.  The releases will end up being
>
> close together, but they're on different release lines so there's
>
> nothing wrong with that necessarily.  Unless there's something
>
> inherent to the release process that makes it difficult to have two
>
> in-flight simultaneously? (I haven't RM'd a release yet, so there may
>
> well be.  Though now that I think back I'm pretty sure other
>
> committers have done this sort of thing before...)
>
>
>
> Was there a particular reason you brought up delaying 8.7?
>
>
>
> Jason
>
>
>
>
>
> On Wed, Sep 23, 2020 at 11:11 AM Atri Sharma  wrote:
>
> >
>
> > I was planning on a branch cut on 30th September for 8.7 — do we want to
> delay that?
>
> >
>
> > On Wed, 23 Sep 2020 at 19:37, Jason Gerlowski 
> wrote:
>
> >>
>
> >> Hi all,
>
> >>
>
> >>
>
> >>
>
> >> I ran into a query-parsing bug recently in SOLR-14859 that caused
>
> >>
>
> >> problems for some of my usecases.  I wanted to volunteer as RM for an
>
> >>
>
> >> 8.6.3 to get a bugfix release out for users that aren't ready for some
>
> >>
>
> >> of the bigger changes in 8.7
>
> >>
>
> >>
>
> >>
>
> >> I was thinking of cutting the branch in a week's time to give others a
>
> >>
>
> >> chance to backport any bug-fixes they might want included, with an RC
>
> >>
>
> >> to follow shortly.  Does anyone have any concerns with that plan, or
>
> >>
>
> >> have anything they'd like to fix or backport before an 8.6.3 goes out?
>
> >>
>
> >>
>
> >>
>
> >> Best,
>
> >>
>
> >>
>
> >>
>
> >> Jason
>
> >>
>
> >>
>
> >>
>
> >> -
>
> >>
>
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> >>
>
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
>
> >>
>
> >>
>
> >>
>
> > --
>
> > Regards,
>
> >
>
> > Atri
>
> > Apache Concerted
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.6.3 Release

[Atri Sharma]

I was planning on a branch cut on 30th September for 8.7 — do we want to
delay that?

On Wed, 23 Sep 2020 at 19:37, Jason Gerlowski  wrote:

> Hi all,
>
>
>
> I ran into a query-parsing bug recently in SOLR-14859 that caused
>
> problems for some of my usecases.  I wanted to volunteer as RM for an
>
> 8.6.3 to get a bugfix release out for users that aren't ready for some
>
> of the bigger changes in 8.7
>
>
>
> I was thinking of cutting the branch in a week's time to give others a
>
> chance to backport any bug-fixes they might want included, with an RC
>
> to follow shortly.  Does anyone have any concerns with that plan, or
>
> have anything they'd like to fix or backport before an 8.6.3 goes out?
>
>
>
> Best,
>
>
>
> Jason
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.7 Release

[Atri Sharma]

I plan to cut the branch on 30th September.

On Wed, 23 Sep 2020 at 00:51, Cassandra Targett 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
> Atri,
>
>
>
>
>
> Just so I understand your plans, when you say you are planning to start
> the process at the end of this month, you mean you intend to create the
> branch around Oct 1? No pressure, I ask only because Ishan’s original mail
> mentioned cutting the branch this week and I just wanted to have a clearer
> sense of your timeline.
>
>
>
>
>
> Thanks,
>
>
> Cassandra
>
>
>
>
> On Sep 15, 2020, 11:53 PM -0500, Atri Sharma , wrote:
>
>
>
>
> I was planning to start the process end of this month.
>
>
>
>
>
>
>
> On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:
>
>
>
>>
>> Unless it somehow got lost in a spam filter somewhere, I don't think we
>> have set a target date for the release yet? (roadmap says autumn 2020 which
>> technically doesn't begin until the solstice on the 21st :) )
>>
>>
>>
>>
>> Hoping that I might still get the Advanced Query parser in first, but
>> that's a much bigger prospect than these two tickets.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> -Gus
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
>> wrote:
>>
>>
>>
>>>
>>> Unless there are objections, I'm gonna get
>>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>>
>>>
>>>
>>>
>>> Erik
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
>>> cpoersc...@bloomberg.net> wrote:
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> With a view towards including it in the release, I'd appreciate input on
>>> the
>>>
>>>
>>>
>>>
>>> https://issues.apache.org/jira/browse/SOLR-14828
>>>
>>>
>>>
>>>
>>>
>>> solrj logging tweak if anyone has a moment?
>>>
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>> Christine
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> From: dev@lucene.apache.org At: 08/20/20 22:48:39
>>>
>>>
>>> To: dev@lucene.apache.org
>>>
>>>
>>> Subject: Re: 8.7 Release
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Also, we should try to respect the stuff we have put on the roadmap
>>> (Which includes me getting a patch up for SIP-9 much sooner rather than
>>> even a little later!)
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand  wrote:
>>>
>>>
>>>
>>>>
>>>> Thanks for the explanation Ishan.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com> wrote:
>>>>
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>> Hi Adrien,
>>>>>
>>>>>
>>>>> I think I am mainly concerned about getting the configuration and
>>>>> modularity of this right before we release:
>>>>> https://issues.apache.org/jira/browse/SOLR-14588.
>>>>>
>>>>>
>>>>> If we aren't able to resolve it, we should revert that feature.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> There may be some other performance issues that may have been marked
>>>>> as blockers just to infuse a sense of urgency among those that need to fix
>>>>> it. But, I wouldn't consider them something that actually holds up a
>>>>> release.
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
&g

Re: Github PR Actions

[Atri Sharma]

+1.

Ability to run tests in Github actions should help prevent a ton of build
breakages.

Thanks for leading this, Houston!

On Fri, 18 Sep 2020 at 21:24, Houston Putman 
wrote:

> Good point on the reference_impl branch. Eventually that's the goal, but
> given there's not a timeline for that to be merged yet I think this is a
> good stop-gap. It's a few minutes of work to get these PR actions written,
> so I feel like there is little downside. And we can always remove them when
> the reference_imp branch gets merged.
>
> This may block my ability to merge any PR whatsoever.
>
>
> The docker tests will not be run on any PRs that don't touch bin/solr,
> solr/packaging or solr/docker.
>
> There are complications around running integration tests in a
> non-containerized environment as well. And if the docker image tests are
> failing on the PR, wouldn't you rather know before committing? Even if you
> don't want to install docker, you can call in someone else that has it to
> help debug. Much like PRs that affect solr.cmd, for committers without
> access to a windows machine.
>
> On Thu, Sep 17, 2020 at 6:23 PM Ishan Chattopadhyaya <
> ichattopadhy...@gmail.com> wrote:
>
>> > It would be great to run all the tests every time, but clearly that is
>> too expensive.
>>
>> The reference_impl branch requires around 30 seconds to run all solr-core
>> tests. That's where we should all put our collective efforts.
>> Also, I have reservations against docker based tests blocking PRs. If I
>> don't have docker running on my dev machine, I wouldn't be able to make
>> those tests pass. This may block my ability to merge any PR whatsoever.
>> Why can't we have integration tests that do not rely on docker?
>>
>> On Thu, Sep 17, 2020 at 9:26 PM Houston Putman 
>> wrote:
>>
>>> Thought I'd make this a thread instead of a discussion on a single JIRA
>>> ticket.
>>>
>>> Currently we have gradle precommit run on PRs for master, which is very
>>> useful and gives people confidence in approving PRs. But precommit is
>>> obviously not the only thing we care about before committing. It would be
>>> great to run all the tests every time, but clearly that is too expensive.
>>>
>>> In SOLR-14856 , I
>>> proposed adding a github action to build and test the solr docker image for
>>> PRs that affected relevant parts of the repo (solr/docker, solr/bin,
>>> solr/packaging and solr/contrib/prometheus-exporter/bin). Running the
>>> docker tests currently takes roughly 12 minutes in the github action, which
>>> would be costly if it ran on every PR. But when running on the small
>>> percentage of PRs that affect those code paths, I think the benefit
>>> outweighs the cost.
>>>
>>> Beyond just the docker tests, I think we can leverage this ability for
>>> other features that are limited to certain code paths. For example running
>>> tests for contrib modules, testing solr/examples, and many of
>>> the independent lucene modules. The SolrJ tests just ran in 3 minutes
>>> locally for me, maybe that'd be a good candidate as well.
>>>
>>> Anyways I'm sure there are other good candidates out there, but I just
>>> wanted to start the discussion and hear other opinions before diving any
>>> deeper.
>>>
>>>
>>>
>>
>>
>
> --
Regards,

Atri
Apache Concerted

Re: Github PR Actions

[Atri Sharma]

+1 to not depending on Docker for local tests.

I do not wish to derail this thread — but re: reference branch, doesn’t it
have a bunch of tests disabled?

On Fri, 18 Sep 2020 at 03:53, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> > It would be great to run all the tests every time, but clearly that is
> too expensive.
>
> The reference_impl branch requires around 30 seconds to run all solr-core
> tests. That's where we should all put our collective efforts.
> Also, I have reservations against docker based tests blocking PRs. If I
> don't have docker running on my dev machine, I wouldn't be able to make
> those tests pass. This may block my ability to merge any PR whatsoever.
> Why can't we have integration tests that do not rely on docker?
>
> On Thu, Sep 17, 2020 at 9:26 PM Houston Putman 
> wrote:
>
>> Thought I'd make this a thread instead of a discussion on a single JIRA
>> ticket.
>>
>> Currently we have gradle precommit run on PRs for master, which is very
>> useful and gives people confidence in approving PRs. But precommit is
>> obviously not the only thing we care about before committing. It would be
>> great to run all the tests every time, but clearly that is too expensive.
>>
>> In SOLR-14856 , I
>> proposed adding a github action to build and test the solr docker image for
>> PRs that affected relevant parts of the repo (solr/docker, solr/bin,
>> solr/packaging and solr/contrib/prometheus-exporter/bin). Running the
>> docker tests currently takes roughly 12 minutes in the github action, which
>> would be costly if it ran on every PR. But when running on the small
>> percentage of PRs that affect those code paths, I think the benefit
>> outweighs the cost.
>>
>> Beyond just the docker tests, I think we can leverage this ability for
>> other features that are limited to certain code paths. For example running
>> tests for contrib modules, testing solr/examples, and many of
>> the independent lucene modules. The SolrJ tests just ran in 3 minutes
>> locally for me, maybe that'd be a good candidate as well.
>>
>> Anyways I'm sure there are other good candidates out there, but I just
>> wanted to start the discussion and hear other opinions before diving any
>> deeper.
>>
>>
>>
>
> --
Regards,

Atri
Apache Concerted

Re: Our test failure rate is unacceptable.

[Atri Sharma]

When I said temporary, I meant 3-4 hours. Definitely not more than that.

IMO we should just roll back offending commits if they are easily
identifiable. I agree with you — we all have been guilty of breaking builds
(mea culpa as well). The bad part here is the longevity of the failures.


On Fri, 18 Sep 2020 at 21:05, Erick Erickson 
wrote:

> bq. IMO if a temporary instability is to be introduced deliberately, it
> should be published on the list
>
>
>
> Actually, I disagree. Having anything in the tests that fail 100% of the
> time is just unacceptable since it becomes a barrier for everyone else.
> AFAIK, if the problem can be identified to a particular push, I have no
> problems with that push being unilaterally rolled back.
>
>
>
> The exception for me is when the problem is addressed immediately, I’ve
> certainly been the source of that kind of problem, as have others.
>
>
>
> What I take great exception to is the fact that some of these tests have
> been failing 100% of the time for the last seven days! If it’s the case
> that the full test suite was never run before the push that’s another
> discussion. Yeah, it takes a long time but…
>
>
>
> Erick
>
>
>
> > On Sep 18, 2020, at 11:28 AM, Atri Sharma  wrote:
>
> >
>
> > IMO if a temporary instability is to be introduced deliberately, it
> should be published on the list. If it’s inadvertently added, we either fix
> it within an hour or so or revert the offending commit.
>
> >
>
> > On Fri, 18 Sep 2020 at 20:26, Erick Erickson 
> wrote:
>
> > http://fucit.org/solr-jenkins-reports/failure-report.html
>
> >
>
> >
>
> >
>
> > HdfsAutoAddReplicasTest failing 100% of the time.
>
> >
>
> > TestPackages.classMethod failing 100% of the time
>
> >
>
> > 3-4 AutoAddReplicas tests failing 98% of the time.
>
> >
>
> >
>
> >
>
> > Is anyone looking at these? I realize the code base is changing a lot,
> and some temporary instability is to be expected. What I’d like is for some
> indication that people are actively addressing these.
>
> >
>
> >
>
> >
>
> > Erick
>
> >
>
> > -
>
> >
>
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> >
>
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
> >
>
> >
>
> >
>
> > --
>
> > Regards,
>
> >
>
> > Atri
>
> > Apache Concerted
>
>
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: Our test failure rate is unacceptable.

[Atri Sharma]

IMO if a temporary instability is to be introduced deliberately, it should
be published on the list. If it’s inadvertently added, we either fix it
within an hour or so or revert the offending commit.

On Fri, 18 Sep 2020 at 20:26, Erick Erickson 
wrote:

> http://fucit.org/solr-jenkins-reports/failure-report.html
>
>
>
> HdfsAutoAddReplicasTest failing 100% of the time.
>
> TestPackages.classMethod failing 100% of the time
>
> 3-4 AutoAddReplicas tests failing 98% of the time.
>
>
>
> Is anyone looking at these? I realize the code base is changing a lot, and
> some temporary instability is to be expected. What I’d like is for some
> indication that people are actively addressing these.
>
>
>
> Erick
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.7 Release

[Atri Sharma]

I was planning to start the process end of this month.

On Wed, 16 Sep 2020 at 04:07, Gus Heck  wrote:

> Unless it somehow got lost in a spam filter somewhere, I don't think we
> have set a target date for the release yet? (roadmap says autumn 2020 which
> technically doesn't begin until the solstice on the 21st :) )
>
> Hoping that I might still get the Advanced Query parser in first, but
> that's a much bigger prospect than these two tickets.
>
> -Gus
>
> On Tue, Sep 15, 2020 at 5:29 PM Erik Hatcher 
> wrote:
>
>> Unless there are objections, I'm gonna get
>> https://issues.apache.org/jira/browse/SOLR-14799 into 8.7 as well.
>>
>> Erik
>>
>>
>> On Sep 14, 2020, at 10:06 AM, Christine Poerschke (BLOOMBERG/ LONDON) <
>> cpoersc...@bloomberg.net> wrote:
>>
>> With a view towards including it in the release, I'd appreciate input on
>> the
>>
>> https://issues.apache.org/jira/browse/SOLR-14828
>>
>> solrj logging tweak if anyone has a moment?
>>
>> Thanks,
>> Christine
>>
>> From: dev@lucene.apache.org At: 08/20/20 22:48:39
>> To: dev@lucene.apache.org
>> Subject: Re: 8.7 Release
>>
>> Also, we should try to respect the stuff we have put on the roadmap
>> (Which includes me getting a patch up for SIP-9 much sooner rather than
>> even a little later!)
>>
>> On Thu, Aug 20, 2020 at 5:18 PM Adrien Grand  wrote:
>>
>>> Thanks for the explanation Ishan.
>>>
>>> On Thu, Aug 20, 2020 at 10:33 PM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>>
 Hi Adrien,
 I think I am mainly concerned about getting the configuration and
 modularity of this right before we release:
 https://issues.apache.org/jira/browse/SOLR-14588.
 If we aren't able to resolve it, we should revert that feature.

 There may be some other performance issues that may have been marked as
 blockers just to infuse a sense of urgency among those that need to fix it.
 But, I wouldn't consider them something that actually holds up a release.
 Regards,
 Ishan

 On Fri, Aug 21, 2020 at 1:56 AM Adrien Grand  wrote:

> Noble, I'm curious what blockers you have in mind. I just checked
> JIRA, and while I see a number of 9.0 blockers, I'm not counting many 8.7
> blockers?
>
> On Thu, Aug 20, 2020 at 11:13 AM Noble Paul 
> wrote:
>
>> There are a lot of blockers for 8.7. It's good to plan in advance
>>
>> On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattopadhyaya
>>  wrote:
>> >
>> > Hi devs,
>> > A lot of changes are now in 8.7 or in-flight. I'd like to volunteer
>> for a 8.7 release in around a month from now (cutting the release branch
>> around 20 September) and RC shortly after. I feel this timeline will give
>> all of us ample time to wrap up the release blockers, other changes and
>> improvements.
>> >
>> > Does someone have any thoughts, concerns or objections?
>> > Regards,
>> > Ishan
>> >
>>
>>
>> --
>> -
>> Noble Paul
>>
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>
> --
> Adrien
>

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

Atri
Apache Concerted

Re: Migrate Solr helm chart into apache/lucene-solr repo

[Atri Sharma]

The CouchDB example is a good one -- it is not a part of the core repository.

It might be a wide audience, but I would start a discussion at
committ...@apache.org for this.

Atri

On Thu, Sep 3, 2020 at 8:05 PM LEE Ween Jiann
 wrote:
>
> No, where and who would be the right place and person to get this discussion 
> going?
>
>
>
> Some charts have already begun moving like 
> https://github.com/apache/couchdb-helm, whereas others like Airflow, Hadoop, 
> Spark, etc. (+ others that I might have missed) have yet to move.
>
>
>
> Other than that, I think zookeeper is being maintained by Bitnami.
>
>
>
>
>
> From: Atri Sharma 
> Reply to: "dev@lucene.apache.org" 
> Date: Thursday, 3 September 2020 at 10:17 PM
> To: "dev@lucene.apache.org" 
> Subject: Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
> Is this a consensus between all the Apache projects? Is there a discussion 
> going on?
>
>
>
> On Thu, 3 Sep 2020 at 19:43, LEE Ween Jiann  
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The ideal case would be to have Apache/charts with all the helm charts that 
> are orphaned.
>
>
>
> If not I guess, we will just wait and see if anyone picks up those charts.
>
>
>
>
>
>
>
>
>
>
>
>
>
> From: Atri Sharma 
>
>
> Reply to: "dev@lucene.apache.org" 
>
>
> Date: Thursday, 3 September 2020 at 10:08 PM
>
>
> To: "dev@lucene.apache.org" 
>
>
> Subject: Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I still don’t see this as a reason to add it to the main repo. Maybe create a 
> new repo just for this helm chart?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Anyways, as David said, the third party plug-in repository will be perfect 
> for this.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 3 Sep 2020 at 19:36, LEE Ween Jiann  
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hey there,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The thing is there will **not** be repository after Nov 13.
>
>
>
>
>
>
>
> Please refer to this link which was previously posted,
>
>
>
>
>
>
>
>
>
>
>
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
>
>
>
> WJ
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> From:
>
> Atri Sharma 
>
>
>
>
>
>
>
>
> Reply to: "dev@lucene.apache.org" 
>
>
>
>
>
>
>
>
> Date: Thursday, 3 September 2020 at 10:02 PM
>
>
>
>
>
>
>
>
> To: "dev@lucene.apache.org" 
>
>
>
>
>
>
>
>
> Subject: Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Jumping in late, but I don’t see why the help chart needs to be a part of the 
> core repository.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Like the HDFS repository, why not just add a link to the existing repository 
> somewhere on the main website?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 3 Sep 2020 at 19:29, LEE Ween Jiann  
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>

Re: Migrate Solr helm chart into apache/lucene-solr repo

[Atri Sharma]

Is this a consensus between all the Apache projects? Is there a discussion
going on?

On Thu, 3 Sep 2020 at 19:43, LEE Ween Jiann 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> The ideal case would be to have Apache/charts with all the helm charts
> that are orphaned.
>
>
> If not I guess, we will just wait and see if anyone picks up those charts.
>
>
>
>
>
>
>
>
>
>
> *From: *Atri Sharma 
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>
> *Date: *Thursday, 3 September 2020 at 10:08 PM
>
>
> *To: *"dev@lucene.apache.org" 
>
>
> *Subject: *Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
> I still don’t see this as a reason to add it to the main repo. Maybe
> create a new repo just for this helm chart?
>
>
>
>
>
>
>
>
>
>
>
>
>
> Anyways, as David said, the third party plug-in repository will be perfect
> for this.
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 3 Sep 2020 at 19:36, LEE Ween Jiann 
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hey there,
>
>
>
>
>
>
>
>
>
>
>
> The thing is there will **not** be repository after Nov 13.
>
>
>
>
>
> Please refer to this link which was previously posted,
>
>
>
>
>
>
>
>
>
>
>
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
>
> WJ
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:*Atri Sharma 
>
>
>
>
>
>
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>
>
>
>
>
>
>
> *Date: *Thursday, 3 September 2020 at 10:02 PM
>
>
>
>
>
>
>
>
> *To: *"dev@lucene.apache.org" 
>
>
>
>
>
>
>
>
> *Subject: *Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Jumping in late, but I don’t see why the help chart needs to be a part of
> the core repository.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Like the HDFS repository, why not just add a link to the existing
> repository somewhere on the main website?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 3 Sep 2020 at 19:29, LEE Ween Jiann 
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi both,
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Is there any updates on this? The helm stable chart repo is now
> deprecated, could we move the helm chart to the apache GitHub repo?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
>
>
>
>
>
>
>
> WJ
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:*David Smiley 
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>

Re: Migrate Solr helm chart into apache/lucene-solr repo

[Atri Sharma]

I still don’t see this as a reason to add it to the main repo. Maybe create
a new repo just for this helm chart?

Anyways, as David said, the third party plug-in repository will be perfect
for this.

On Thu, 3 Sep 2020 at 19:36, LEE Ween Jiann 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hey there,
>
>
>
>
>
> The thing is there will **not** be repository after Nov 13.
>
>
> Please refer to this link which was previously posted,
>
>
>
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>
>
>
>
>
> Cheers,
>
>
> WJ
>
>
>
>
>
>
>
> *From: *Atri Sharma 
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>
> *Date: *Thursday, 3 September 2020 at 10:02 PM
>
>
> *To: *"dev@lucene.apache.org" 
>
>
> *Subject: *Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
> Jumping in late, but I don’t see why the help chart needs to be a part of
> the core repository.
>
>
>
>
>
>
>
>
>
>
>
>
>
> Like the HDFS repository, why not just add a link to the existing
> repository somewhere on the main website?
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Thu, 3 Sep 2020 at 19:29, LEE Ween Jiann 
> wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi both,
>
>
>
>
>
>
>
>
>
>
>
> Is there any updates on this? The helm stable chart repo is now
> deprecated, could we move the helm chart to the apache GitHub repo?
>
>
>
>
>
>
>
>
>
>
>
> Cheers,
>
>
>
>
>
> WJ
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> *From:*David Smiley 
>
>
>
>
>
>
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>
>
>
>
>
>
>
> *Date: *Monday, 3 February 2020 at 1:07 AM
>
>
>
>
>
>
>
>
> *To: *Solr/Lucene Dev 
>
>
>
>
>
>
>
>
> *Subject: *Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> I was looking for a "Why" Helm is ending its registry and didn't find it,
> though I did find the 2x vs 3x thing so I thought it was about version
> migration more than anything.  I'm wondering
>
> "Why" because this very project, Solr, will soon
>
>
>
>
>
> be grappling with how to create a repository of 3rd party plugins.
> Successful projects like Docker do this so I wonder why Helm seems to be
> backing out.  Perhaps we will have one main repository of 3rd party plugins
> we've vetted in some way (have high confidence
>
>
>
>
>
> in) and then for others we simply list URLs to "known" repos of packages
> of plugins that we have no opinion of.  This is uncharted territory for
> us.  Unlike Helm & Docker, I don't expect a vast number of entries.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ~ David Smiley
>
>
>
>
>
>
>
>
>
>
>
> Apache Lucene/Solr Search Developer
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> http://www.linkedin.com/in/davidwsmiley
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 1, 2020 at 5:52 PM Marcus Eagan  wrote:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> David, I think he is referring to the note here:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>
>
>
>
>
>
>
>
>
&g

Re: Migrate Solr helm chart into apache/lucene-solr repo

[Atri Sharma]

Jumping in late, but I don’t see why the help chart needs to be a part of
the core repository.

Like the HDFS repository, why not just add a link to the existing
repository somewhere on the main website?

On Thu, 3 Sep 2020 at 19:29, LEE Ween Jiann 
wrote:

>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Hi both,
>
>
>
>
>
> Is there any updates on this? The helm stable chart repo is now
> deprecated, could we move the helm chart to the apache GitHub repo?
>
>
>
>
>
> Cheers,
>
>
> WJ
>
>
>
>
>
>
>
> *From: *David Smiley 
>
>
> *Reply to: *"dev@lucene.apache.org" 
>
>
> *Date: *Monday, 3 February 2020 at 1:07 AM
>
>
> *To: *Solr/Lucene Dev 
>
>
> *Subject: *Re: Migrate Solr helm chart into apache/lucene-solr repo
>
>
>
>
>
>
>
>
>
>
>
>
>
> I was looking for a "Why" Helm is ending its registry and didn't find it,
> though I did find the 2x vs 3x thing so I thought it was about version
> migration more than anything.  I'm wondering "Why" because this very
> project, Solr, will soon
>
> be grappling with how to create a repository of 3rd party plugins.
> Successful projects like Docker do this so I wonder why Helm seems to be
> backing out.  Perhaps we will have one main repository of 3rd party plugins
> we've vetted in some way (have high confidence
>
> in) and then for others we simply list URLs to "known" repos of packages
> of plugins that we have no opinion of.  This is uncharted territory for
> us.  Unlike Helm & Docker, I don't expect a vast number of entries.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ~ David Smiley
>
>
>
>
> Apache Lucene/Solr Search Developer
>
>
>
>
>
>
> http://www.linkedin.com/in/davidwsmiley
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 1, 2020 at 5:52 PM Marcus Eagan  wrote:
>
>
>
>
>
>
>
>
>
>
> David, I think he is referring to the note here:
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> https://github.com/helm/charts/blob/master/README.md#deprecation-timeline
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> All the best,
>
>
>
>
>
>
>
>
>
>
>
>
>
> Marcus
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Feb 1, 2020 at 14:37 David Smiley 
> wrote:
>
>
>
>
>
>
>
>
>
>
> Hi Lee,
>
>
>
>
>
>
>
>
>
>
>
> We're currently in-process of adopting Solr's Docker image.  I confess
> I've never used Helm so I have no clue how it's maintained, tested, etc and
> so I'll leave this sort of decision to others here.
>
>
>
>
>
>
>
>
>
>
>
>
>
> BTW I went to that link about Helm deprecation and AFAICT it seems about
> 2.x version of Helm and not about 3.x.  See
>
>
>
> https://helm.sh/blog/2019-10-22-helm-2150-released/#helm-2-support-plan
> too.  Am I missing something?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ~ David Smiley
>
>
>
>
> Apache Lucene/Solr Search Developer
>
>
>
>
>
>
> http://www.linkedin.com/in/davidwsmiley
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Fri, Jan 31, 2020 at 1:09 AM LEE Ween Jiann <
> wjlee.2...@phdcs.smu.edu.sg> wrote:
>
>
>
>
>
>
>
>
>
>
> Hi,
>
>
>
>
>
> Since helm stable repo is deprecated, it’s taking a lot of time to get the
> pull requests approved.
>
>
> Also the helm chart for Solr has to go somewhere soon, refer to
>
> https://github.com/helm/charts#deprecation-timeline.
>
>
>
>
>
> Would you guys be adopting it?
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
>
>
>
>
>
>
> Marcus Eagan
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: [VOTE] Lucene logo contest, here we go again

[Atri Sharma]

D (binding).

On Tue, Sep 1, 2020 at 5:56 AM Ryan Ernst  wrote:
>
> Dear Lucene and Solr developers!
>
> In February a contest was started to design a new logo for Lucene 
> [jira-issue]. The initial attempt [first-vote] to call a vote resulted in 
> some confusion on the rules, as well the request for one additional 
> submission. I would like to call a new vote, now with more explicit 
> instructions on how to vote.
>
> Please read the following rules carefully before submitting your vote.
>
> Who can vote?
>
> Anyone is welcome to cast a vote in support of their favorite submission(s). 
> Note that only PMC member's votes are binding. If you are a PMC member, 
> please indicate with your vote that the vote is binding, to ease collection 
> of votes. In tallying the votes, I will attempt to verify only those marked 
> as binding.
>
> How do I vote?
>
> Votes can be cast simply by replying to this email. It is a ranked-choice 
> vote [rank-choice-voting]. Multiple selections may be made, where the order 
> of preference must be specified. If an entry gets more than half the votes, 
> it is the winner. Otherwise, the entry with the lowest number of votes is 
> removed, and the votes are retallied, taking into account the next preferred 
> entry for those whose first entry was removed. This process repeats until 
> there is a winner.
>
> The entries are broken up by variants, since some entries have multiple color 
> or style variations. The entry identifiers are first a capital letter, 
> followed by a variation id (described with each entry below), if applicable. 
> As an example, if you prefer variant 1 of entry A, followed by variant 2 of 
> entry A, variant 3 of entry C, entry D, and lastly variant 4e of entry B, the 
> following should be in your reply:
>
> (binding)
> vote: A1, A2, C3, D, B4e
>
> Entries
>
> The entries are as follows:
>
> A. Submitted by Dustin Haver. This entry has two variants, A1 and A2.
>
> [A1] 
> https://issues.apache.org/jira/secure/attachment/12999548/Screen%20Shot%202020-04-10%20at%208.29.32%20AM.png
> [A2] https://issues.apache.org/jira/secure/attachment/12997172/LuceneLogo.png
>
> B. Submitted by Stamatis Zampetakis. This has several variants. Within the 
> linked entry there are 7 patterns and 7 color palettes. Any vote for B should 
> contain the pattern number followed by the lowercase letter of the color 
> palette. For example, B3e or B1a.
>
> [B] https://issues.apache.org/jira/secure/attachment/12997768/zabetak-1-7.pdf
>
> C. Submitted by Baris Kazar. This entry has 8 variants.
>
> [C1] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo1_full.pdf
> [C2] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo2_full.pdf
> [C3] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo3_full.pdf
> [C4] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo4_full.pdf
> [C5] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo5_full.pdf
> [C6] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo6_full.pdf
> [C7] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo7_full.pdf
> [C8] 
> https://issues.apache.org/jira/secure/attachment/13006392/lucene_logo8_full.pdf
>
> D. The current Lucene logo.
>
> [D] https://lucene.apache.org/theme/images/lucene/lucene_logo_green_300.png
>
> Please vote for one of the above choices. This vote will close one week from 
> today, Mon, Sept 7, 2020 at 11:59PM.
>
> Thanks!
>
> [jira-issue] https://issues.apache.org/jira/browse/LUCENE-9221
> [first-vote] 
> http://mail-archives.apache.org/mod_mbox/lucene-dev/202006.mbox/%3cCA+DiXd74Mz4H6o9SmUNLUuHQc6Q1-9mzUR7xfxR03ntGwo=d...@mail.gmail.com%3e
> [rank-choice-voting] https://en.wikipedia.org/wiki/Instant-runoff_voting

-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene/Solr 8.6.2 RC1

[Atri Sharma]

+1 (binding)

SUCCESS! [1:14:17.24939]

On Thu, 27 Aug 2020 at 18:41, Michael Sokolov  wrote:

> SUCCESS! [0:56:28.589654]
>
>
>
> +1
>
>
>
> On Wed, Aug 26, 2020 at 12:41 PM Nhat Nguyen
>
>  wrote:
>
> >
>
> > +1
>
> >
>
> > SUCCESS! [0:52:44.607871]
>
> >
>
> > On Wed, Aug 26, 2020 at 12:12 PM Tomoko Uchida <
> tomoko.uchida.1...@gmail.com> wrote:
>
> >>
>
> >> +1 (non-binding)
>
> >> SUCCESS! [0:51:55.207272]
>
> >>
>
> >>
>
> >> 2020年8月26日(水) 22:42 Ignacio Vera :
>
> >>>
>
> >>> Please vote for release candidate 1 for Lucene/Solr 8.6.2
>
> >>>
>
> >>>
>
> >>> The artifacts can be downloaded from:
>
> >>>
>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
> >>>
>
> >>>
>
> >>> You can run the smoke tester directly with this command:
>
> >>>
>
> >>>
>
> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>
> >>>
>
> >>>
> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.2-RC1-rev016993b65e393b58246d54e8ddda9f56a453eb0e
>
> >>>
>
> >>>
>
> >>> The vote will be open for at least 72 hours i.e. until 2020-08-29
> 15:00 UTC.
>
> >>>
>
> >>>
>
> >>> [ ] +1  approve
>
> >>>
>
> >>> [ ] +0  no opinion
>
> >>>
>
> >>> [ ] -1  disapprove (and reason why)
>
> >>>
>
> >>>
>
> >>> Here is my +1
>
> >>>
>
> >>>
>
> >>> SUCCESS! [1:14:00.656250]
>
>
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
>

-- 
Regards,

Atri
Apache Concerted

Re: Failing tests 100% of the time.

[Atri Sharma]

This was my bad, sorry folks. Another reason for me to move from ant to
gradle.

Thanks a ton for taking this one, Erick!

On Thu, 27 Aug 2020 at 18:15, Erick Erickson 
wrote:

> There are a number of tests failing 100% of the time. I should be able to
> push a fix momentarily, it’s an NPE that seems straightforward to cure.
>
>
>
> In the interests of getting this out of people’s way ASAP, I’m going to
> push the fix after getting a few tests that have been failing to run,
> _then_ run the full test suite. If that doesn’t work I’ll roll back to
> before this problem started.
>
> -
>
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>
> For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
>
> --
Regards,

Atri
Apache Concerted

Re: 8.7 Release

[Atri Sharma]

+1

I am happy to take it up.

On Thu, 20 Aug 2020 at 14:56, Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:

> @Atri Sharma 
>
> Atri, I just remembered you wanted to volunteer for the release. If you're
> still interested, please let me know. I can shadow you and help you during
> the release in that case.
>
> On Thu, Aug 20, 2020 at 2:43 PM Noble Paul  wrote:
>
>> There are a lot of blockers for 8.7. It's good to plan in advance
>>
>>
>>
>>
>>
>> On Thu, Aug 20, 2020 at 7:11 PM Ishan Chattopadhyaya
>>
>>
>>  wrote:
>>
>>
>> >
>>
>>
>> > Hi devs,
>>
>>
>> > A lot of changes are now in 8.7 or in-flight. I'd like to volunteer for
>> a 8.7 release in around a month from now (cutting the release branch around
>> 20 September) and RC shortly after. I feel this timeline will give all of
>> us ample time to wrap up the release blockers, other changes and
>> improvements.
>>
>>
>> >
>>
>>
>> > Does someone have any thoughts, concerns or objections?
>>
>>
>> > Regards,
>>
>>
>> > Ishan
>>
>>
>> >
>>
>>
>>
>>
>>
>>
>>
>>
>> --
>>
>>
>> -
>>
>>
>> Noble Paul
>>
>>
>>
>>
>>
>> -
>>
>>
>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
>>
>>
>> For additional commands, e-mail: dev-h...@lucene.apache.org
>>
>>
>>
>>
>>
>>
>
> --
Regards,

Atri
Apache Concerted

Re: Error - Document contains at least one immense term

[Atri Sharma]

Perhaps you have a field which exceeds the set limit?

On Wed, Aug 12, 2020 at 4:47 PM Rajesh Somvanshi
 wrote:
>
>
> Hi Team,
>
>
> I am using solr library to be indexing my documents. It is working as 
> expected but sometimes I am getting below error. Could you please help with 
> this?
>
>
>
> The document contains at least one immense term in field="FileContent_en***" 
> (whose UTF8 encoding is longer than the max length 32766), all of which were 
> skipped. Please correct the analyzer to not produce such terms. The prefix of 
> the first immense term is: '[110, 97, 109, 101, 61, 34, 97, 99, 113, 117, 
> 105, 115, 105, 116, 105, 111, 110, 115, 116, 111, 114, 101, 34, 62, 101, 106, 
> 122, 107, 118, 118]...', original message: bytes can be at most 32766 in 
> length; got 422071. Perhaps the document has an indexed string field 
> (solr.StrField) which is too large solr.field
>
>
>
>
>
> Thanks
>
> Rajesh Somvanshi

-- 
Regards,

Atri
Apache Concerted

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

Re: [VOTE] Release Lucene/Solr 8.6.1 RC2

[Atri Sharma]

+1 (non binding).

SUCCESS! [1:03:32.13920]

On Wed, Aug 12, 2020 at 3:24 AM Gus Heck  wrote:
>
> SUCCESS! [0:54:03.106188]
>
> And installed the tarball as a 4 node cluster, created a collection and added 
> a document - success :)
>
> +1
>
> On Tue, Aug 11, 2020 at 12:13 PM Timothy Potter  wrote:
>>
>> Thanks Houston.
>>
>> SUCCESS! [1:34:35.219332]
>>
>> +1
>>
>> On Mon, Aug 10, 2020 at 1:02 PM Houston Putman  
>> wrote:
>>>
>>> Please vote for release candidate 2 for Lucene/Solr 8.6.1
>>>
>>> The artifacts can be downloaded from:
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
>>>
>>> You can run the smoke tester directly with this command:
>>>
>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>> https://dist.apache.org/repos/dist/dev/lucene/lucene-solr-8.6.1-RC2-rev6e11a1c3f0599f1c918bc69c4f51928d23160e99
>>>
>>> The vote will be open for at least 72 hours i.e. until 2020-08-13 20:00 UTC.
>>>
>>> [ ] +1  approve
>>> [ ] +0  no opinion
>>> [ ] -1  disapprove (and reason why)
>>>
>>> Here is my +1
>
>
>
> --
> http://www.needhamsoftware.com (work)
> http://www.the111shift.com (play)

-- 
Regards,

Atri
Apache Concerted

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

Re: Badapple report

[Atri Sharma]

Merged (thanks Mike D!).

Atri

On Tue, Aug 11, 2020 at 5:32 PM Erick Erickson  wrote:
>
> Great, thanks! Let me know when you push it, I can beast the test again.
>
> > On Aug 11, 2020, at 3:48 AM, Atri Sharma  wrote:
> >
> > I investigated testRequestRateLimiters and hardened the tests up:
> >
> > https://github.com/apache/lucene-solr/pull/1736
> >
> > This will stop testConcurrentRequests from failing and should
> > hopefully stop testSlotBorrowing as well. If testSlotBorrowing
> > continues to fail, I will have to rethink the test.
> >
> > On Mon, Aug 10, 2020 at 8:17 PM Erick Erickson  
> > wrote:
> >>
> >> We’re backsliding some. I encourage people to look at: 
> >> http://fucit.org/solr-jenkins-reports/failure-report.html, we have a 
> >> number of ill-behaved tests, particularly TestRequestRateLimiter, 
> >> TestBulkSchemaConcurrent, TestConfig, SchemaApiFailureTest and 
> >> TestIndexingSequenceNumbers…
> >>
> >>
> >> Raw fail count by week totals, most recent week first (corresponds to 
> >> bits):
> >> Week: 0  had  100 failures
> >> Week: 1  had  82 failures
> >> Week: 2  had  94 failures
> >> Week: 3  had  502 failures
> >>
> >>
> >> Failures in Hoss' reports for the last 4 rollups.
> >>
> >> There were 585 unannotated tests that failed in Hoss' rollups. Ordered by 
> >> the date I downloaded the rollup file, newest->oldest. See above for the 
> >> dates the files were collected
> >> These tests were NOT BadApple'd or AwaitsFix'd
> >>
> >> Failures in the last 4 reports..
> >>   Report   Pct runsfails   test
> >> 0123   4.4 1583 37  BasicDistributedZkTest.test
> >> 0123   4.3 1727 77  CloudExitableDirectoryReaderTest.test
> >> 0123   2.5 8598248  
> >> CloudExitableDirectoryReaderTest.testCreepThenBite
> >> 0123   1.9 1712 36  
> >> CloudExitableDirectoryReaderTest.testWhitebox
> >> 0123   0.5 1587 11  
> >> DocValuesNotIndexedTest.testGroupingDVOnlySortLast
> >> 0123   2.2 1679 82  HttpPartitionOnCommitTest.test
> >> 0123   0.5 1592 16  HttpPartitionTest.test
> >> 0123   1.0 1578  9  HttpPartitionWithTlogReplicasTest.test
> >> 0123   1.3 1569 13  LeaderFailoverAfterPartitionTest.test
> >> 0123   7.4 1643 59  MultiThreadedOCPTest.test
> >> 0123   0.3 1567  8  ReplaceNodeTest.test
> >> 0123   0.2 1588  6  ShardSplitTest.testSplitShardWithRule
> >> 0123 100.0   38 33  SharedFSAutoReplicaFailoverTest.test
> >> 0123   2.1  818 19  
> >> TestCircuitBreaker.testBuildingMemoryPressure
> >> 0123   2.6  818 13  
> >> TestCircuitBreaker.testResponseWithCBTiming
> >> 0123   6.2 1848104  TestContainerPlugin.testApiFromPackage
> >> 0123   2.5 1662 33  TestDistributedGrouping.test
> >> 0123   0.4 1448  6  TestDynamicLoading.testDynamicLoading
> >> 0123   6.4 1614 74  TestExportWriter.testExpr
> >> 0123   8.6 1356 70  TestHdfsCloudBackupRestore.test
> >> 0123   9.1 1697136  TestLocalFSCloudBackupRestore.test
> >> 0123   0.5 1607 26  TestPackages.testPluginLoading
> >> 0123   0.7 1596 15  
> >> TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast
> >> 0123   1.5 1610 59  
> >> TestReRankQParserPlugin.testMinExactCount
> >> 0123   0.3 1552  4  TestReplicaProperties.test
> >> 0123   0.3 1556  5  
> >> TestSolrCloudWithDelegationTokens.testDelegationTokenRenew
> >> 0123   0.3 1565  9  TestSolrConfigHandlerCloud.test
> >> 
> >>
> >>
> >> -
> >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> >> For additional commands, e-mail: dev-h...@lucene.apache.org
> >
> > --
> > Regards,
> >
> > Atri
> > Apache Concerted
> >
> > -
> > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> > For additional commands, e-mail: dev-h...@lucene.apache.org
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org
>


-- 
Regards,

Atri
Apache Concerted

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

Re: Badapple report

[Atri Sharma]

I investigated testRequestRateLimiters and hardened the tests up:

https://github.com/apache/lucene-solr/pull/1736

This will stop testConcurrentRequests from failing and should
hopefully stop testSlotBorrowing as well. If testSlotBorrowing
continues to fail, I will have to rethink the test.

On Mon, Aug 10, 2020 at 8:17 PM Erick Erickson  wrote:
>
> We’re backsliding some. I encourage people to look at: 
> http://fucit.org/solr-jenkins-reports/failure-report.html, we have a number 
> of ill-behaved tests, particularly TestRequestRateLimiter, 
> TestBulkSchemaConcurrent, TestConfig, SchemaApiFailureTest and 
> TestIndexingSequenceNumbers…
>
>
> Raw fail count by week totals, most recent week first (corresponds to bits):
> Week: 0  had  100 failures
> Week: 1  had  82 failures
> Week: 2  had  94 failures
> Week: 3  had  502 failures
>
>
> Failures in Hoss' reports for the last 4 rollups.
>
> There were 585 unannotated tests that failed in Hoss' rollups. Ordered by the 
> date I downloaded the rollup file, newest->oldest. See above for the dates 
> the files were collected
> These tests were NOT BadApple'd or AwaitsFix'd
>
> Failures in the last 4 reports..
>Report   Pct runsfails   test
>  0123   4.4 1583 37  BasicDistributedZkTest.test
>  0123   4.3 1727 77  CloudExitableDirectoryReaderTest.test
>  0123   2.5 8598248  
> CloudExitableDirectoryReaderTest.testCreepThenBite
>  0123   1.9 1712 36  
> CloudExitableDirectoryReaderTest.testWhitebox
>  0123   0.5 1587 11  
> DocValuesNotIndexedTest.testGroupingDVOnlySortLast
>  0123   2.2 1679 82  HttpPartitionOnCommitTest.test
>  0123   0.5 1592 16  HttpPartitionTest.test
>  0123   1.0 1578  9  HttpPartitionWithTlogReplicasTest.test
>  0123   1.3 1569 13  LeaderFailoverAfterPartitionTest.test
>  0123   7.4 1643 59  MultiThreadedOCPTest.test
>  0123   0.3 1567  8  ReplaceNodeTest.test
>  0123   0.2 1588  6  ShardSplitTest.testSplitShardWithRule
>  0123 100.0   38 33  SharedFSAutoReplicaFailoverTest.test
>  0123   2.1  818 19  
> TestCircuitBreaker.testBuildingMemoryPressure
>  0123   2.6  818 13  
> TestCircuitBreaker.testResponseWithCBTiming
>  0123   6.2 1848104  TestContainerPlugin.testApiFromPackage
>  0123   2.5 1662 33  TestDistributedGrouping.test
>  0123   0.4 1448  6  TestDynamicLoading.testDynamicLoading
>  0123   6.4 1614 74  TestExportWriter.testExpr
>  0123   8.6 1356 70  TestHdfsCloudBackupRestore.test
>  0123   9.1 1697136  TestLocalFSCloudBackupRestore.test
>  0123   0.5 1607 26  TestPackages.testPluginLoading
>  0123   0.7 1596 15  
> TestQueryingOnDownCollection.testQueryToDownCollectionShouldFailFast
>  0123   1.5 1610 59  TestReRankQParserPlugin.testMinExactCount
>  0123   0.3 1552  4  TestReplicaProperties.test
>  0123   0.3 1556  5  
> TestSolrCloudWithDelegationTokens.testDelegationTokenRenew
>  0123   0.3 1565  9  TestSolrConfigHandlerCloud.test
> 
>
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
> For additional commands, e-mail: dev-h...@lucene.apache.org

-- 
Regards,

Atri
Apache Concerted

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