Re: PR labeling

[Jan Høydahl]

+1 to try.

60 days for stale and another 60 days before close should be enough imo.

We can set the ‘close-pr-label’ for easier reference of what prs were auto 
closed, should anyone wish to do archeology or re-open stuff that obviously 
went below people’s radar despite two notifications to the list.

Jan Høydahl

> On 22 Sep 2024, at 15:11, Eric Pugh  wrote:
> 
> What if we tried it for a few months and then reevaluated?
> 
> 
> Sent from my iPhone
> 
>> On Sep 20, 2024, at 3:02 PM, Jan Høydahl  wrote:
>> 
>> Any commit or comment on a stale PR will make it un-stale for 60 more days 
>> too.
>> 
>> Jan Høydahl
>> 
>>>> On 19 Sep 2024, at 23:14, David Smiley  wrote:
>>> 
>>> Upon seeing a "stale" warning, how do I signal to the bot that this PR
>>> shouldn't be closed soon?  Or perhaps upon re-opening, the bot ought to
>>> back off on this one forevermore?
>>> 
>>>>> On Thu, Sep 19, 2024 at 3:06 PM Jan Høydahl  wrote:
>>>> 
>>>> +1 I’ve tried suggesting this several times, also for abandoned JIRA
>>>> issues, but always big pushback.
>>>> 
>>>> If we get a stale warning and then, if no one cares, another notification
>>>> when auto-closing, no one can say they were not warned. And old closed PRs
>>>> can always be re-opened, but at that point there will be so many merge
>>>> conflicts so who’d want to anyway? 😉
>>>> 
>>>> Jan Høydahl
>>>> 
>>>>>> On 19 Sep 2024, at 20:07, David Smiley  wrote:
>>>>> 
>>>>> I don't see in the dev list here a discussion on auto-closing old PRs
>>>> but
>>>>> FWIW I'm in favor of that provided we could somehow choose to keep a PR
>>>>> open that we're still passionate about, that we don't want to be
>>>>> forgotten.  This was discussed in the meetup yesterday.
>>>>> 
>>>>>> On Fri, Jan 26, 2024 at 10:56 AM Eric Pugh <
>>>> ep...@opensourceconnections.com>
>>>>>> wrote:
>>>>>> 
>>>>>> When I picked up https://github.com/apache/solr/pull/2225 it was cool
>>>> to
>>>>>> see the “start-script” label!  Thanks!
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>> On Jan 26, 2024, at 10:33 AM, Jan Høydahl 
>>>> wrote:
>>>>>>> 
>>>>>>> The StaleBot is now active, running once a day at midnight.
>>>>>>> I started in a conservative way, only labeling 10 PRs a day, and
>>>> setting
>>>>>> the threshold at 60 days.
>>>>>>> This gives us some time to evaluate without labeling the entire
>>>> backlog.
>>>>>>> Will be interesting to see whether the Bot results in some fogotten PRs
>>>>>> being completed.
>>>>>>> 
>>>>>>> Jan
>>>>>>> 
>>>>>>>> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl :
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> Got some initial (positive) feedback on the auto-categorization PR and
>>>>>> plan to merge on Thursday, giving you some more time to review. I feel I
>>>>>> have not 100% nailed perfect labels. Obviously we can't auto label
>>>> things
>>>>>> like feature/bug, or versions, so this is only a "category". Ideally
>>>> there
>>>>>> would be a a 1:1 between these "category" labels and the "Components"
>>>>>> defined in JIRA. But here are 96 different "Components" there, most of
>>>> them
>>>>>> are old/irrelevant and not always very good IMO. So I'd rather attempt
>>>> to
>>>>>> align JIRA components with whatever we come up with here...
>>>>>>>> 
>>>>>>>> Lucene has just put their StaleBot to work, and I created
>>>>>> https://github.com/apache/solr/pull/2184 to do the same for Solr. Have
>>>> a
>>>>>> look.
>>>>>>>> 
>>>>>>>> Jan
>>>>>>>> 
>>>>>>>>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
>>>>>>>>> 
>>>>>>>>> H

Re: PR labeling

[Jan Høydahl]

Any commit or comment on a stale PR will make it un-stale for 60 more days too.

Jan Høydahl

> On 19 Sep 2024, at 23:14, David Smiley  wrote:
> 
> Upon seeing a "stale" warning, how do I signal to the bot that this PR
> shouldn't be closed soon?  Or perhaps upon re-opening, the bot ought to
> back off on this one forevermore?
> 
>> On Thu, Sep 19, 2024 at 3:06 PM Jan Høydahl  wrote:
>> 
>> +1 I’ve tried suggesting this several times, also for abandoned JIRA
>> issues, but always big pushback.
>> 
>> If we get a stale warning and then, if no one cares, another notification
>> when auto-closing, no one can say they were not warned. And old closed PRs
>> can always be re-opened, but at that point there will be so many merge
>> conflicts so who’d want to anyway? 😉
>> 
>> Jan Høydahl
>> 
>>>> On 19 Sep 2024, at 20:07, David Smiley  wrote:
>>> 
>>> I don't see in the dev list here a discussion on auto-closing old PRs
>> but
>>> FWIW I'm in favor of that provided we could somehow choose to keep a PR
>>> open that we're still passionate about, that we don't want to be
>>> forgotten.  This was discussed in the meetup yesterday.
>>> 
>>>> On Fri, Jan 26, 2024 at 10:56 AM Eric Pugh <
>> ep...@opensourceconnections.com>
>>>> wrote:
>>>> 
>>>> When I picked up https://github.com/apache/solr/pull/2225 it was cool
>> to
>>>> see the “start-script” label!  Thanks!
>>>> 
>>>> 
>>>> 
>>>>>> On Jan 26, 2024, at 10:33 AM, Jan Høydahl 
>> wrote:
>>>>> 
>>>>> The StaleBot is now active, running once a day at midnight.
>>>>> I started in a conservative way, only labeling 10 PRs a day, and
>> setting
>>>> the threshold at 60 days.
>>>>> This gives us some time to evaluate without labeling the entire
>> backlog.
>>>>> Will be interesting to see whether the Bot results in some fogotten PRs
>>>> being completed.
>>>>> 
>>>>> Jan
>>>>> 
>>>>>> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl :
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> Got some initial (positive) feedback on the auto-categorization PR and
>>>> plan to merge on Thursday, giving you some more time to review. I feel I
>>>> have not 100% nailed perfect labels. Obviously we can't auto label
>> things
>>>> like feature/bug, or versions, so this is only a "category". Ideally
>> there
>>>> would be a a 1:1 between these "category" labels and the "Components"
>>>> defined in JIRA. But here are 96 different "Components" there, most of
>> them
>>>> are old/irrelevant and not always very good IMO. So I'd rather attempt
>> to
>>>> align JIRA components with whatever we come up with here...
>>>>>> 
>>>>>> Lucene has just put their StaleBot to work, and I created
>>>> https://github.com/apache/solr/pull/2184 to do the same for Solr. Have
>> a
>>>> look.
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
>>>>>>> 
>>>>>>> Hi,
>>>>>>> 
>>>>>>> We tend to not use the GitHub's PR labels we have defined.
>>>>>>> So I whipped up https://github.com/apache/solr/pull/2180 which is
>>>> configured to auto-label PRs based on what files are changed. Feedback
>>>> welcome.
>>>>>>> 
>>>>>>> Also, I hope we can implement StaleBot for labeling PRs as stale.
>>>> Lucene is going to test it, see
>>>> https://github.com/apache/lucene/pull/12813. If that goes well, let's
>>>> copy their config :)
>>>>>>> 
>>>>>>> - Jan
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>>> 
>>>>> -
>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>>>> 
>>>> 
>>>> ___
>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>>>> http://www.opensourceconnections.com <
>>>> http://www.opensourceconnections.com/> | My Free/Busy <
>>>> http://tinyurl.com/eric-cal>
>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>>>> 
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw
>>> 
>>>> 
>>>> This e-mail and all contents, including attachments, is considered to be
>>>> Company Confidential unless explicitly stated otherwise, regardless of
>>>> whether attachments are marked as such.
>>>> 
>>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 

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

Re: PR labeling

[Jan Høydahl]

+1 I’ve tried suggesting this several times, also for abandoned JIRA issues, 
but always big pushback.

If we get a stale warning and then, if no one cares, another notification when 
auto-closing, no one can say they were not warned. And old closed PRs can 
always be re-opened, but at that point there will be so many merge conflicts so 
who’d want to anyway? 😉

Jan Høydahl

> On 19 Sep 2024, at 20:07, David Smiley  wrote:
> 
> I don't see in the dev list here a discussion on auto-closing old PRs but
> FWIW I'm in favor of that provided we could somehow choose to keep a PR
> open that we're still passionate about, that we don't want to be
> forgotten.  This was discussed in the meetup yesterday.
> 
>> On Fri, Jan 26, 2024 at 10:56 AM Eric Pugh 
>> wrote:
>> 
>> When I picked up https://github.com/apache/solr/pull/2225 it was cool to
>> see the “start-script” label!  Thanks!
>> 
>> 
>> 
>>>> On Jan 26, 2024, at 10:33 AM, Jan Høydahl  wrote:
>>> 
>>> The StaleBot is now active, running once a day at midnight.
>>> I started in a conservative way, only labeling 10 PRs a day, and setting
>> the threshold at 60 days.
>>> This gives us some time to evaluate without labeling the entire backlog.
>>> Will be interesting to see whether the Bot results in some fogotten PRs
>> being completed.
>>> 
>>> Jan
>>> 
>>>> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl :
>>>> 
>>>> Hi,
>>>> 
>>>> Got some initial (positive) feedback on the auto-categorization PR and
>> plan to merge on Thursday, giving you some more time to review. I feel I
>> have not 100% nailed perfect labels. Obviously we can't auto label things
>> like feature/bug, or versions, so this is only a "category". Ideally there
>> would be a a 1:1 between these "category" labels and the "Components"
>> defined in JIRA. But here are 96 different "Components" there, most of them
>> are old/irrelevant and not always very good IMO. So I'd rather attempt to
>> align JIRA components with whatever we come up with here...
>>>> 
>>>> Lucene has just put their StaleBot to work, and I created
>> https://github.com/apache/solr/pull/2184 to do the same for Solr. Have a
>> look.
>>>> 
>>>> Jan
>>>> 
>>>>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
>>>>> 
>>>>> Hi,
>>>>> 
>>>>> We tend to not use the GitHub's PR labels we have defined.
>>>>> So I whipped up https://github.com/apache/solr/pull/2180 which is
>> configured to auto-label PRs based on what files are changed. Feedback
>> welcome.
>>>>> 
>>>>> Also, I hope we can implement StaleBot for labeling PRs as stale.
>> Lucene is going to test it, see
>> https://github.com/apache/lucene/pull/12813. If that goes well, let's
>> copy their config :)
>>>>> 
>>>>> - Jan
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> ___
>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com <
>> http://www.opensourceconnections.com/> | My Free/Busy <
>> http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> 
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> 
>> 

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

Re: [VOTE] Release Apache Solr 9.7.0 RC2

[Jan Høydahl]

+1 (binding)

SUCCESS! [0:42:01.595127]

Once again on third attempt.

Also built docker images and spun it up.

Jan

> 4. sep. 2024 kl. 03:00 skrev Anshum Gupta :
> 
> Please vote for release candidate 2 for Solr 9.7.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC2-rev-675a41516e3f3bacfc975590773e7abdca444ff4
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC2-rev-675a41516e3f3bacfc975590773e7abdca444ff4
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC2-rev-675a41516e3f3bacfc975590773e7abdca444ff4/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.7.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.7.0-2 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.7.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.7.0-2-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-09-07 01:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -Anshum Gupta


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

Re: [VOTE] Release Solr 9.7.0 RC1

[Jan Høydahl]

On third attempt smoketester passed:

SUCCESS! [0:53:19.266825]

+1 (binding)

Jan

> 27. aug. 2024 kl. 21:09 skrev Anshum Gupta :
> 
> Please vote for Release Candidate 1 for Apache Solr 9.7.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC1-rev-dd176f1217f0573ea9b9b72c75a3e52e7a49e139
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC1-rev-dd176f1217f0573ea9b9b72c75a3e52e7a49e139
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.7.0-RC1-rev-dd176f1217f0573ea9b9b72c75a3e52e7a49e139/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.7.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.7.0-1 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.7.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.7.0-1-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-08-30 20:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> -Anshum Gupta


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

Re: Getting this error

[Jan Høydahl]

Hi Gyan,

Your post is cross-posted to several lists. Please do not do that.
The correct list for questions like this is the "users@" mailing list. Please 
subscribe to that list and re-post.
When posting your question, please give much more context and information on 
your setup and how it can be reproduced.
Images/screenshots do not work well with the list software, please instead use 
text or put images on an external service and provide a link.

Please do not continue discussion on this list. I will not respond to any 
followups, other than on "users" list.

Jan

> 23. aug. 2024 kl. 09:21 skrev Gyan Sharma :
> 
>  
>  
> 
> 
> Gyan Sharma 
> Search Relevance Engineer
> 
> 
> 
> e: gsha...@progressresidential.com 
> RentProgress.com 
> 
> From: Gyan Sharma  >
> Date: Friday, August 23, 2024 at 12:20 AM
> To: us...@solr.apache.org  
> mailto:us...@solr.apache.org>>
> Subject: Getting this error
> 
> 

Re: Simple Query String Builder for SolrJ

[Jan Høydahl]

I did not use the term "legacy" to suggest we remove it. No no. Just in lack of 
better name. Guess it could also be called http-parameter-request-api/dsl or 
localparam-dsl, as opposed to JSON-request-api/dsl. "Lucene query string" is in 
my mind the "+foo -(bar baz)~2" string, while our Solr query parser also 
supports local-params for composing more complex queries.

I'm happy that Yonik bootstrapped the JSON request DSL, but that was back in 
2017, and it has remained somewhat under the radar for many users partly due to 
a lack of SolrJ support, poor documentation and poor AdminUI support. I don't 
know how to lift JSON-request-dsl as a 1st class citizen in Solr, but it 
certainly won't help to ignore it in efforts like this.

Geoffrey, don't take this as criticism of your work in any way. We all fix our 
own needs and I appreciate that you contribute and thus also lift the topic for 
discussion. It would be better to have some builder help in SolrJ than nothing, 
and perfection can be the enemy of progress and all that. Just lifting the 
discussion to a higher design level for a while.

Jan

> 21. aug. 2024 kl. 05:57 skrev David Smiley :
> 
> Since when is Solr’s, venerable “lucene” query syntax legacy?  I don’t
> imagine it would ever disappear.
> 
> On Tue, Aug 20, 2024 at 7:30 PM Geoffrey Slinker
>  wrote:
> 
>> I am very happy that a discussion is underway and that maybe in the end
>> there will be new ways to generate queries for end users.
>> 
>> I am not in a position to speak for what is already “inside” Apache Solr.
>> 
>> If I can help please let me know.
>> 
>> Geoffrey
>> 
>>> On Aug 20, 2024, at 4:49 PM, Uwe Schindler  wrote:
>>> 
>>> +1: Thanks for this writeup, Jan!
>>> 
>>> Am 20.08.2024 um 22:49 schrieb Jan Høydahl:
>>>> Having written tons of Java client code for querying elasticsearch, one
>> thing I
>>>> appreciate with the various QueryBuilders is how closely they map to
>> the actual
>>>> Lucene Query objects being the end result. Also, they are nicely
>> composable,
>>>> and of course map almost 1:1 to ES JSON query dsl.
>>>> 
>>>> So if we want to evolve SolrJ's ability to construct complex queries,
>> I'd propose
>>>> we couple the SolrJ builders to our JSON Query DSL and take the
>> opportunity to
>>>> evolving, fixing and documenting that DSL in the process.
>>>> 
>>>> It would be a bonus if builders could output/serialize to
>> legacy-query-string
>>>> as an option, but supporting only legacy would be a strange design
>> choice.
>>>> 
>>>> Jan
>>>> 
>>>>> 20. aug. 2024 kl. 22:10 skrev Gus Heck :
>>>>> 
>>>>> Also if expressed as xml the lucene classes can be sent to solr (not
>> sure
>>>>> if we have a tool to express them as xml however)
>>>>> 
>>>>> 
>> https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#xml-query-parser
>>>>> 
>>>>> On Tue, Aug 20, 2024 at 1:11 PM Mike Drob  wrote:
>>>>> 
>>>>>> At the risk of sounding ignorant, what is the advantage of this over
>> using
>>>>>> Lucene classes to programmatically build queries and then toString
>> those?
>>>>>> It's not a single class, but the lucene search package has always
>> seemed
>>>>>> pretty straightforward to me.
>>>>>> 
>>>>>> 
>> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/package-summary.html#query
>>>>>> 
>>>>>> 
>> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/Query.html
>>>>>> 
>>>>>> If the goal is human readable query methods, I had previously done
>> some of
>>>>>> the work in the opposite direction (matching queries to descriptions
>>>>>> instead of descriptions to queries) in test framework's QueryMatcher,
>> might
>>>>>> be worth comparing against.
>>>>>> 
>>>>>> 
>> https://github.com/apache/solr/blob/main/solr/test-framework/src/java/org/apache/solr/util/QueryMatchers.java
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> On Tue, Aug 20, 2024 at 11:07 AM David Smiley 
>> wrote:
>>>>>> 
>>>>>>> Let's bikeshed before you write code, okay?  Otherwise you
>> potential

Re: Simple Query String Builder for SolrJ

[Jan Høydahl]

Having written tons of Java client code for querying elasticsearch, one thing I
appreciate with the various QueryBuilders is how closely they map to the actual
Lucene Query objects being the end result. Also, they are nicely composable,
and of course map almost 1:1 to ES JSON query dsl.

So if we want to evolve SolrJ's ability to construct complex queries, I'd 
propose
we couple the SolrJ builders to our JSON Query DSL and take the opportunity to
evolving, fixing and documenting that DSL in the process.

It would be a bonus if builders could output/serialize to legacy-query-string
as an option, but supporting only legacy would be a strange design choice.

Jan

> 20. aug. 2024 kl. 22:10 skrev Gus Heck :
> 
> Also if expressed as xml the lucene classes can be sent to solr (not sure
> if we have a tool to express them as xml however)
> 
> https://solr.apache.org/guide/solr/latest/query-guide/other-parsers.html#xml-query-parser
> 
> On Tue, Aug 20, 2024 at 1:11 PM Mike Drob  wrote:
> 
>> At the risk of sounding ignorant, what is the advantage of this over using
>> Lucene classes to programmatically build queries and then toString those?
>> It's not a single class, but the lucene search package has always seemed
>> pretty straightforward to me.
>> 
>> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/package-summary.html#query
>> 
>> https://lucene.apache.org/core/9_7_0/core/org/apache/lucene/search/Query.html
>> 
>> If the goal is human readable query methods, I had previously done some of
>> the work in the opposite direction (matching queries to descriptions
>> instead of descriptions to queries) in test framework's QueryMatcher, might
>> be worth comparing against.
>> 
>> https://github.com/apache/solr/blob/main/solr/test-framework/src/java/org/apache/solr/util/QueryMatchers.java
>> 
>> 
>> 
>> On Tue, Aug 20, 2024 at 11:07 AM David Smiley  wrote:
>> 
>>> Let's bikeshed before you write code, okay?  Otherwise you potentially
>>> waste time and/or grow attached to sunk costs.
>>> 
>>> Feedback:
>>> * avoid the word "term"; it already has Lucene definition and a Solr
>>> query parser but you're using it in a way that isn't either.  I
>>> recommend simply  for "fieldQuery" -- these queries target specific
>>> fields after all.
>>> * Can we avoid top level classes that the user must know about;
>>> instead having one class -- QueryBuilder (or named QueryStringBuilder)
>>> with factory methods that are easily discoverable?  Not a huge deal.
>>> * Instead of "Group", lets acknowledge these map to a BooleanQuery so
>>> I think "bool" in some way should be used instead.  Some bool builder
>>> can then have must() should() filter() methods without needing an
>>> enum.
>>> * Can't import any Lucene things
>>> 
>>> I'll add examples below of my feedback ideas.
>>> 
>>> On Tue, Aug 20, 2024 at 11:04 AM Geoffrey Slinker
>>>  wrote:
>>> 
 Instantiate a Term and set the values and call toString to get a string
>>> that can be used in a Standard Solr Query.
   Term term = new Term("pink panther").withBoost(1.5f);
   term. toString()
 
   Output: "pink panther"^1.5
 
   Term term = new Term("title", "pink panther").withBoost(1.5f);
   term. toString()
 
   Output: title:"pink panther"^1.5
>>> 
>>> final QueryStringBuilder B = new QueryStringBuilder(potential
>>> options); // immutable
>>> B.field("title", "ping panther").withBoost(1.5f).toString();
>>> 
>>> 
  TermGroup group = new TermGroup().with(Occur.
>>> MUST).withBoost(1.4f);
  group. addTerm(new Term("foo", "bar").withProximity(1));
 
  String query = group. toString();
 
  Output: +( foo:bar~1 )^1.4
>>> 
>>> the outer MUST is pointless but I'll recreate anyway:
>>> 
>>> final QueryStringBuilder B = new QueryStringBuilder(potential
>>> options); // immutable
>>> B.bool().must(B.fieldFuzzy("foo", "bar", 1).withBoost(1.4)).toString();
>>> 
 Example:
  TermGroup group = new TermGroup().withConstantScore(5.0f);
  group. addTerm(new Term("foo", "bar").withProximity(1));
 
  String query = group. toString();
 
  Output: ( foo:bar~1 )^=5
>>> 
>>> final QueryStringBuilder B = new QueryStringBuilder(potential
>>> options); // immutable
>>> B.fieldFuzzy("foo", "bar", 1).withConstantScore(5.0f).toString();
>>> // no "group" terminology necessary
>>> 
 Instead of using string manipulation to create complex query strings
>> the
>>> TermGroup allows complex queries to be built inside an object model that
>>> can be more easily changed.
 If you need to generate a query like this:
  +(
(
title:"Grand Illusion"~1
title:"Paradise Theatre"~1
)^0.3
(
title:"Night At The Opera"~1
title:"News Of The World"~1
)^0.3
(
title:"Van

Re: Updating Dependencies - Apache Tika

[Jan Høydahl]

Hi

Wrt Tika, I had been hoping that we could replace extracting handler with a 
processor that delegates to Tika Server, but is otherwise feature parity. It 
would remove tons of dependencies and attack surface from Solr.

I tried a POC once but could not find a suitable Java client for Tika Server 
REST API. Perhaps that exists now?

Jan Høydahl

> 12. aug. 2024 kl. 16:20 skrev Christos Malliaridis :
> 
> Hello everyone,
> 
> I've been looking into the dependencies of the project and thought that we
> could update a couple of them, together with their license files (wherever
> necessary).
> 
> I tried to start with Apache Tika and upgrade it from 1.28.5 to 2.9.2,
> which is a huge step due to some restructuring of Apache Tika. The affected
> modules are extraction and langid.
> 
> There is a PR from solrbot <https://github.com/apache/solr/pull/2583> that
> requires some manual work that I have already picked up for learning
> purposes. I'd like to create a ticket for the upgrade, but also saw that
> there is also SOLR-13973
> <https://issues.apache.org/jira/browse/SOLR-13973> that
> is titled "Deprecate Tika". From the age and conversation on the ticket, it
> sounds like Tika will not be deprecated and the ticket can be closed. But I
> am not sure and would like to ask for your input on this.
> 
> In the migration to 2.9.2 it seems that there are some conflicts with the
> way the title from documents is extracted. Some metadata tags have also
> been removed / replaced, which needs more attention. See Migrating to Tika
> 2.0.0
> <https://cwiki.apache.org/confluence/display/TIKA/Migrating+to+Tika+2.0.0> for
> more details.
> 
> I'd be happy to create a PR for the upgrade and look into the fixes with
> someone that has already worked with Apache Tika 2.X or the affected
> modules (extraction/langid).
> 
> Best,
> Christos

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

Re: Copying data from master to slave

[Jan Høydahl]

Hi,

I replied to you email yesterday, asking you to use the users mailing list for 
such questions. Please stop posting user questions to the dev mailing list.
See https://solr.apache.org/community.html#mailing-lists-chat 

Jan

> 8. aug. 2024 kl. 10:47 skrev Mugi, Krishnavamsireddy 
> :
> 
> Hi Team,
> 
> I am trying to copy data from master to slave through replication handler. 
> But I am getting leaderurl malformed even though leaderurl being valid. Am I 
> missing anything here, Can anyone please help me on this?
> 
> This is the /replication handler of mine.
> 
> 
>  
> name="leaderUrl">https://sss-nick-solr-m.use1.prod.aws.viacbs.tech/solr/nickjr_webplexhttps://sss-nick-solr-m.use1.prod.aws.viacbs.tech/solr/nickjr_webplex%3c/str>>
>1
>1
>internal
>00:01:00
>  
> 
> 
> Thanks&Regards
> KrishnaVamsi

Re: Solr reindexing

[Jan Høydahl]

Hi,

You are emailing the developers list. This list is not for user support, but 
for developing Solr.
Please use the "users" mailing list instead for such questions.

Jan

> 7. aug. 2024 kl. 15:00 skrev Mugi, Krishnavamsireddy 
> :
> 
> Hi Team,
> 
> We are copying the data from one of the solr server in EC2 instance to K8s 
> solr instance.
> 
> EC2 instance solr version is 6.5.1
> K8s instance solr version is 9.2.1
> 
> We are copying the data through solr replication handler, Will the copying 
> work seamlessly or do we need to make any changes in the latest version?
> 
> Thanks&Regards
> KrishnaVamsi


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

Re: JSON Parsing, Jackson / Noggit

[Jan Høydahl]

Noggit features like optional quotation of strings, comments, trailing comma 
etc are nice but not crucial.
I'd like us to move to standard JSON if it is not significantly slower. 
On the SolrJ client side I'd hope we could shade Jackson to avoid version 
conflicts in user code.

Jan

> 5. aug. 2024 kl. 20:09 skrev David Smiley :
> 
> I just finished some benchmarking work using Solr's benchmark module.
> It should be pretty easy to tweak an existing benchmark to try both.
> Purely from a maintainability standpoint, we could make a hard break
> decision in Solr 10.
> 
> On Mon, Aug 5, 2024 at 1:00 PM Jason Gerlowski  wrote:
>> 
>> My hunch is that Jackson would be more performant than Noggit, but I
>> don't have any hard numbers to back that up so it's just an educated
>> guess.  I swear there was some other issue that gave Noggit vs.
>> Jackson numbers but I can't find it now.  SOLR-16691 (where Noble
>> switched at least some things over to using Jackson) mentions perf
>> improvements in the issue description but doesn't quantify those.
>> Maybe someone else with context can chime in with data?
>> 
>> Personally, I'd rather see us use Jackson across the board.  I'm sure
>> we can write and maintain great serialization code if we want to spend
>> that effort, but do we?  Ultimately we're here for Search - it's hard
>> to imagine us wanting to spend anywhere near the amount of time on
>> serde code that a project like Jackson does as their raison d'etre.
>> 
>> The Noggit lenient parsing *is* really nice for making requests by
>> hand, but that's a minority use case.  If there's evidence that
>> Jackson is faster, is it worth slowing down 99% of JSON requests just
>> so that we can leniently parse the 0.1% of malformed reqs that need
>> it?  Is it worth the cost of maintaining our own JSON parsing code in
>> perpetuity?
>> 
>> Best,
>> 
>> Jason
>> 
>> On Mon, Aug 5, 2024 at 11:54 AM David Smiley  wrote:
>>> 
>>> We have a couple JSON Parsing libraries -- "Noggit" (internal to Solr)
>>> and "Jackson".  Noggit is more lenient in parsing.  I suppose Solr
>>> should use Noggit for parsing JSON coming into it, but AFAIK Solr only
>>> returns/emits valid JSON; yes?  For parsing JSON that we assume is
>>> compliant (e.g. from Solr), should we prefer Jackson or Noggit?  Are
>>> there performance advantages?
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Re: Compatability of predefined class in solr versions

[Jan Høydahl]

Hi,

Please ask user questions on the us...@solr.apache.org 
 mailing list. And note that image attachments 
won't make it to the list, so better put plain text of logs rather than 
screenshot.
What is likely the reason is that you have not started Solr with the 'langid' 
module: SOLR_MODULES=langid bin/solr start -c
See 
https://solr.apache.org/guide/solr/latest/indexing-guide/language-detection.html#module
 for more

Jan

> 19. juli 2024 kl. 15:02 skrev Mugi, Krishnavamsireddy 
> :
> 
> Hi Team,
>  
> Is the below Solr predefined class works in solr version 9.6.1? We are 
> migrating our solr version from 8.11.1 to 9.6.1 which is giving the below 
> error while creating the core.
>  
> Class: 
> org.apache.solr.update.processor.LangDetectLanguageIdentifierUpdateProcessorFactory
>  
> 
>  
> Can you please help me on this?
>  
> Thanks&Regards
> KrishnaVamsi

Re: [DISCUSS] Solr 9.7 release

[Jan Høydahl]

Hi,

Sounds ok. 

Will try to merge some of the latest dependency upgrades. There are still ~30 
dependency PRs, so anyone feel free to jump in and resolve some of them before 
the release.

Jan

> 16. juli 2024 kl. 22:12 skrev Anshum Gupta :
> 
> Hi everyone,
> 
> The Change log for Solr 9.7 looks pretty good already with the Lucene
> upgrade and a bunch of other fixes, improvements, and features.
> 
> I'd like to start the release process next *Tuesday, July 23 *unless there
> are objections or reasons to wait.
> 
> -Anshum


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

Re: SIP-7 New Admin UI

[Jan Høydahl]

> - What technology stack would you consider and why?
> - Would you consider a web-based / javascript-based framework easier to get
> started with, or a JVM-based / kotlin-based UI framework?

I consider these related. And it boils down to who will maintain the Admin UI 
app.
If frontend devs are to maintain it and we want to attract frontend 
professionals, then stick to industry standard React or similar.
However, for the lifetime of the project it's been Java devs who have 
maintained the UI with a few huge re-writes being the exceptions, but those 
were mostly one-offs or at least one-person.

So I see why you propse the Kotlin based Compose. In a previous life in the 
90's with Java 1, I did Swing programming, which is hopefully far from what 
Compose offers, which I know nothing about.

> - What was your experience so far with Solr's UI code? What would you avoid
> doing again, what did you like before?

I helped patch both the jQuery and the Angular UI. Notable contributions 
include the OIDC auth impl, the Nodes screen and the ZK Status page.
On one side I like the simplificy of the current UI, just some JS/HTML/CSS 
files, not build, compiling etc.
On the other hand, it makes it hard to add 3rd party modules, upgrade libs etc.
I dislike the fact that the UI is hosted by the main Solr process and talks 
directly to Solr backend APIs. I'd like for the UI to be served by a separate 
servlet/backend that acts as a proxy, so that the Admin UI could be installed 
separately in a DMZ network and poke a hole in firewalls between the AdminUI's 
own backend and the Solr cluster (which would be on a secure inner network).

If we managed to separate the new UI as an independent servlet, perhaps with 
its own /login logic, it would be so much easier to later move the entire UI to 
a separate repo, should the need arise.

> - Would you be interested in contributing to the UI implementation?

I could probably lend a helping hand here and there, do some reviews, and if we 
manage to partition the elephant, pick a few tasks further down the road.

I do Kotlin in day job, and it is an absolute joy to work with. Not hard at 
all, so to committers fearing a "new" language, it is actually not that 
different, just skip the "new" keywork and semicolons, hehe.

Jan Høydahl

> 15. juli 2024 kl. 15:49 skrev Christos Malliaridis :
> 
> Thanks for the references David, those are very insightful to me. I am
> definitely not the first one coming up with these ideas, that's for sure.
> 
> I think the fact that there are multiple third-party frontends for Solr
> shows how important the UI is to the users and it should push us even more
> to do something about the current state.
> 
> *If there is no objection about the proposed approach I would like to
> proceed and discuss the technology stack that could be used and fulfill our
> current requirements.*
> 
> As I already mentioned before, I've been working on a proof-of-concept with
> Compose Multiplatform (Kotlin) that demonstrates what an integration would
> look like.
> Since there are many pros and cons for all the available UI frameworks out
> there, I broke down my point of view and reasons for Compose in a writeup
> <https://docs.google.com/document/d/17B6TuUbbpvg823ixrsnVPT6hJ4vuVv9UHzIz4jITvHI/edit?usp=sharing>
> again.
> 
> But because this is a very opinionated topic, *your input is needed*. To be
> more precise, here are a few questions:
> - What technology stack would you consider and why?
> - What was your experience so far with Solr's UI code? What would you avoid
> doing again, what did you like before?
> - Would you be interested in contributing to the UI implementation?
> - Would you consider a web-based / javascript-based framework easier to get
> started with, or a JVM-based / kotlin-based UI framework?
> 
> Best,
> Christos
> 
> On Fri, Jul 12, 2024 at 11:39 PM David Smiley  wrote:
> 
>> An admin UI can definitely be plugged in.  Here is one:
>> https://github.com/yasa-org/yasa
>> And you would not be the first to consider a desktop client.  There is
>> one of those too: https://solr.search-navigator.org/
>> 
>> On Tue, Jul 9, 2024 at 9:37 PM Christos Malliaridis
>>  wrote:
>>> 
>>> Thanks for your input, votes and feedback so far, I appreciate it.
>>> 
>>> The security concerns are justified and are something I am currently
>>> looking into. With a rewrite it will be easier to take that into account
>>> and consider alternative options that could also enhance security, too.
>> For
>>> example, I am experimenting with a JVM-based and standalone desktop
>> client
>>> (that is probably a safer option and provides extended authentication
>>>

Re: Vex file 404

[Jan Høydahl]

Hi,

Sorry bout that, was on holiday this week and there were some merging left to 
do. Should be ok now.

Jan

> 13. juli 2024 kl. 14:55 skrev Christos Malliaridis :
> 
> Apparently the file is available at
> https://solr.staged.apache.org/solr.vex.json, but not the production /
> official site. Looking into the commit history, the changes where VEX was
> re-enabled
> <https://github.com/apache/solr-site/commit/d34a288028772cc7ca09eb1ac11f764047c58576>
> are not merged yet into the production branch.
> 
> @Jan Høydahl Is there a reason the changes were not released?
> 
> Best,
> Christos
> 
> On Thu, Jul 11, 2024 at 9:53 PM Gus Heck  wrote:
> 
>> I was just trying to tell someone that we publish a machine readable VEX
>> file and went to show them the link on our security page... but it came up
>> 404..
>> 
>> https://solr.apache.org/solr.vex.json
>> 
>> -Gus
>> 
>> --
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>> 


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

Re: [Solr site] Deployment to production process

[Jan Høydahl]

There was also an update to the infrastructure-actions/pelican@main action that 
required a small config change in our repo. Did that and merged main into prod. 
Hope it is fine now and that your PRs will contain only your own stuff..

Jan

> 12. juli 2024 kl. 17:52 skrev Houston Putman :
> 
> It looks like the build stuff Jan had been working on wasn't merged to
> production I'd definitely wait for him to do that.
> 
> - Houston
> 
> On Fri, Jul 12, 2024 at 10:27 AM Alessandro Benedetti 
> wrote:
> 
>> Hi all,
>> we've been working with my colleagues on adding external Solr blogs to the
>> site and we plan to do this periodically, so that each week more or less a
>> new blog is published.
>> 
>> But I am confused about the deployment pipeline:
>> 
>> 1) Pull Request *from*:  *to*: main
>> That's easy peasy, the review happens and when everyone is happy, merge
>> 
>> Then I'm lost, is it:
>> 
>> 2) Pull Request *from*: main *to*: production
>> https://github.com/apache/solr-site/pull/111
>> Trying that I see many differences and not the only blog post I was
>> supposed to deploy live.
>> 
>> What am I missing?
>> 
>> Cheers
>> --
>> *Alessandro Benedetti*
>> Director @ Sease Ltd.
>> *Apache Lucene/Solr Committer*
>> *Apache Solr PMC Member*
>> 
>> e-mail: a.benede...@sease.io
>> 
>> 
>> *Sease* - Information Retrieval Applied
>> Consulting | Training | Open Source
>> 
>> Website: Sease.io 
>> LinkedIn  | Twitter
>>  | Youtube
>>  | Github
>> 
>> 


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

Re: Your ZK connection string (3 hosts) is different from the dynamic ensemble config (3 hosts)

[Jan Høydahl]

Hi,

Please do not use the dev mailing list for user questions. This list is for 
discussions regarindg the development of Solr itself. When re-posting your 
question to the users@ mailing list, please include some more details about 
your setup such as the contents of zookeeper config files and a screenshot of 
the error message on Admin UI.

Jan

> 10. juli 2024 kl. 16:18 skrev Storch, Robin :
> 
> Hello,
> 
> I'm trying to migrate from centos7 to rhel9 on a server that is running 
> solr/zookeeper.
> 
> I copied over the configuration and made changes to the config files that 
> listed the server names.  I also copied over the contents of 
> /opt/solr/aerscloud/solr/configsets which apparently contained information 
> about the previous server names.  I have three nodes and solr and zookeeper 
> and starting up and running on all three.  
> 
> The problem is that on the active node, it is showing the old server names 
> when I run this command:
> 
> /usr/lib/zookeeper/bin/zkCli.sh
> config
> 
> The other two nodes show the correct new server names.
> 
> There are currently two configsets under 
> /opt/solr/aerscloud/solr/configsets/, the old one and a new one that was 
> created by the solr admin.  Is there a way to correct this so that the 
> zookeeper config points to the new server names?
> 
> 
> 
> Robin Storch, M.Ed.
> Systems Engineer
> IS Research IT
> Information Services
> Cincinnati Children's
>  Burnet Avenue, Cincinnati, OH 45229

Re: Use MockDirectoryFactory not RAMDirectoryFactory in test configs

[Jan Høydahl]

+1

Experienced the same locally, tried to override lock factory but did not dig 
deeper and ended up running some tests in gradle instead of IntelliJ. Annoying!

Jan Høydahl

> 1. juli 2024 kl. 22:57 skrev David Smiley :
> 
> Some of our tests don't run correctly/consistently via IntelliJ's
> internal JUnit runner (compared to Gradle).  IntelliJ's JUnit runner
> is faster and better integrated, saving developer productivity.
> 
> I debugged the issue.  The test TestInPlaceUpdatesDistrib failed
> because "RAMDirectory can only be used with the 'single' lock factory
> type.".  This test's solrconfig.xml is very typical:
>class="${solr.directoryFactory:solr.RAMDirectoryFactory}"
> The code for this does *not* set the property.  It turns out the
> randomization.gradle configures all tests to run with this property
> set to "org.apache.solr.core.MockDirectoryFactory".  At least this is
> the only one; the others set there have null values.
> https://github.com/apache/solr/blob/bde8c14bddecc2a417d2fd36abe965675e8e670e/gradle/testing/randomization.gradle#L129
> 
> Proposal: remove this from the gradle config.  Instead, replace all
> "solr.directoryFactory:solr.RAMDirectoryFactory" with
> "solr.directoryFactory:solr.MockDirectoryFactory" in all test
> solrconfig files.
> This is ultimately a minor refactoring of sorts; an improvement to the
> build.  No JIRA.
> 
> Any insights / concerns?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

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

Re: Looking for final review of SOLR-16842

[Jan Høydahl]

From an upgrade 9->10 perspective, it would be good to start getting 
deprecation warnings in 9.x for old options and change scripts etc so you don't 
have a big-bang moment in 10.0.

A potential option 5) is to introduce the new options and deprecate old in 
10.0, meaning they won't be removed until 11.0

Jan

> 28. juni 2024 kl. 13:18 skrev Eric Pugh :
> 
> Hi all….  Quick update that I merged SOLR-16842 into main.
> 
> I wanted to confirm that our Jenkins builds are still happy, and while our 
> normal Jenkins boxes are busted, I see that we have “Solr-Check-main-s390x”?  
>  Looking at it, it appears that recent code merges are fine, that the one 
> test that failed on run 
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-main-s390x/646/ is 
> probably just flaky.   So feeling good about that!
> 
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-main-s390x/
> 
> I have started a back port PR to branch_9x, however it’s not going well…. 
> :-(.   https://github.com/apache/solr/pull/2540.  There are more differences 
> between main and branch_9x for the CLI than I quite realized.   Bats tests on 
> main that aren’t on branch_9x, all the changes in how we craft Solr urls, the 
> fact that we never back ported basic auth for SolrCLI tools….  We replaced 
> “CreateCoreTool" and “CreateCollectionTool" tools with “CreateTool” on 
> main...  I haven’t committed all my local changes as the tests are failing, 
> but may try that….  
> 
> I’m running out of time before vacation for three weeks (hello Spain!) and so 
> thinking:
> 
> 1) Ask for help.  If someone else wanted to take a crack at the back port who 
> has more Git-fu than I do, more than welcome.
> 2) Push up the code to the branch even though tests etc fail.
> 3) Not worry about back port to branch_9x till I get back last week of July.
> 4) Pivot on the back port plan and declare SOLR-16842 to be a Solr 10 only 
> feature.  Figure out a new plan for removing deprecated options from code.  
> (That is starting to feel the path of least resistance to me).
> 
> I would very much like to NOT rollback the change so didn’t list that as an 
> option….
> 
> 
> Thanks
> 
> Eric
> 
> 
>> On Jun 22, 2024, at 10:05 AM, Eric Pugh > > wrote:
>> 
>> Thanks Jason, I’m happy to stall till end of day on Monday to click “merge”! 
>>   Thanks.
>> 
>> 
>>> On Jun 21, 2024, at 12:33 PM, Jason Gerlowski  wrote:
>>> 
>>> Hey Eric,
>>> 
>>> Sorry for the delay - I am hoping to review that PR.  I'll try to have
>>> a review done by Monday (if not today).  That should leave a week or
>>> so for any followups prior to your big trip!  (Safe travels!)
>>> 
>>> If Monday isn't early enough and you need to merge on Saturday, IMO
>>> that's fine.  The PR's been open for nearly a year and you've been
>>> more than patient at this point.  In that case I'll just review
>>> post-merge and we can handle any follow ups as needed.
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>>> On Fri, Jun 21, 2024 at 12:07 PM Eric Pugh
>>>  wrote:
 
 Hi all, I’m planning on merging https://github.com/apache/solr/pull/1768, 
 SOLR-16824: Adopt Linux Command line tool pattern of -- for long option 
 commands tomorrow (Saturday).
 
 I’m going to be traveling (Spain!) for three weeks starting June 29th, and 
 I’d like to make sure this fairly big change has plenty time for any 
 panicky follow up fixes that turn out to be needed when it goes into main 
 and branch_9x.
 
 Eric
 
 
 ___
 Eric Pugh | Founder | 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.
 
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> ___
>> Eric Pugh | Founder | 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.
>> 
> 
> ___

Solr Website now built by Github Actions

[Jan Høydahl]

Hi,

Quick update on the build process for solr website -- 
https://github.com/apache/solr-site
Earlier the Pelican based site was built by ASF buildbot and handled by special 
.asf.yaml sections.
Now it is built with Github Actions, see SOLR-17339 
 and the solr-site README 
 for details.

Also, building the site locally has been simplified. Instead of requiring a 
local Python3 + Pelican install,
the build.sh script in the git repo will now everything in a python docker 
image, so you only need Docker.
Would be nice if a Windows+WSL2 user could try the build script, which is not 
tested on WSL yet.

Jan

Re: Simplify Ref Guide Examples by Merging Windows and Mac/Linux Examples?

[Jan Høydahl]

+1

I have done this myself with paths when running java on Windows - easier to 
handle forward/slash, less escaping etc.

PS: I still hope we can remove bin\solr.cmd from 10.0 (but keep support for 
Windows paths etc in Java).

Jan

> 14. juni 2024 kl. 19:30 skrev David Smiley :
> 
> +1
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
> On Fri, Jun 14, 2024 at 3:30 PM Eric Pugh 
> wrote:
> 
>> In the ref guide we duplicate all out bin/solr post examples to deal with
>> the / for unix/Mac and \ for windows.
>> 
>> I asked ChatGPT about this, and it said that Java just deals with it…
>> 
>> I was thinking we could reduce the duplication by just providing the linux
>> example, and not labeling it “Linux/Mac” and not having a separate windows
>> one…
>> 
>> Thoughts?
>> 
>> Eric
>> 
>> 
>> What ChatGPT said:
>> In Java, the file path handling is designed to be platform-independent, so
>> a path like example/films/films.json will generally work on both Unix-based
>> systems (like Linux or macOS) and Windows, regardless of the underlying
>> file system conventions.
>> 
>> Java's File class, which is used to interact with the file system,
>> automatically handles the differences in path separators between platforms.
>> On Unix-based systems, the path separator is the forward slash (/), while
>> on Windows, it's the backslash (\).
>> 
>> When you pass a path like example/films/films.json to Java, it will
>> interpret the path correctly on both platforms. On Windows, Java will
>> automatically convert the forward slashes to backslashes as needed.
>> 
>> Similarly, if you pass a Windows-style path like example\films\films.json,
>> Java will also handle that correctly on both Unix-based systems and Windows.
>> 
>> The key point is that Java abstracts away the differences in file system
>> conventions between platforms, allowing your code to work consistently
>> across different operating systems. As long as you use Java's file system
>> APIs (such as File, Path, or Paths), you don't need to worry about the
>> underlying path separator characters.
>> 
>> ___
>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 |
>> http://www.opensourceconnections.com <
>> http://www.opensourceconnections.com/> | My Free/Busy <
>> http://tinyurl.com/eric-cal>
>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>> 
>> This e-mail and all contents, including attachments, is considered to be
>> Company Confidential unless explicitly stated otherwise, regardless of
>> whether attachments are marked as such.
>> 
>> 


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

Re: Seeking guidance on Upgrading Minimum Java Version for Main Branch

[Jan Høydahl]

Hi,

Thanks for starting the topic. Looks like we'll align Solr 10 with Lucene 10, 
so somewhere between now and the release of Lucene 10 we definitely should make 
the same move.
Our typical concern is if the change causes lots of other code changes that 
makes backporting harder for a prolonged period. That speaks for waiting, since 
our 10.0 release won't be until the end of year anyway.

A good timing for our cutover could be once the Lucene project starts preparing 
for a 10.0 release. We could then switch Solr main to using a nighlty lucene 
main build and start implementing new and changes APIs.

However, if bumping min Java version for main won't cause much fuzz (i.e. we 
could delay doing sweeping codebase changes for new language features), I'm not 
opposed to doing the change sooner.

Jan

> 4. juni 2024 kl. 07:46 skrev sanjay dutt :
> 
> The purpose of this email thread is to initiate a discussion about upgrading 
> the minimum Java version (Could be same as Lucene minimum Java for main 
> branch i.e. 21) for the main branch. We seek to understand the community's 
> major concerns and gather their guidance on this matter.
> Regards,Sanjay


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

Re: Purpose of IndexUpgraderTool

[Jan Høydahl]

I used it back in the days when you could migrate from v3->4->5->6. It solved
the issue that Solr 6 could only read a Lucene 6 or Lucene 5 index, but after 
the
sequence of upgrades you'd get there. I even wrote a wrapper to automate it all 
at
https://github.com/cominvent/solr-tools/tree/master/upgradeindex

However, now that Lucene 9 refuses to work with any index created before Lucene 
8,
I agree with Jason that I cannot see any utility for the upgrade tool anymore. 
Since,
if you have a Solr 6 index, it won't work in Solr 9 even if you used the 
upgrader.
And if you already have a Lucene 8 index, no need to upgrade by hand, just start
Solr 9 on top of the Lucene 8 index and it will be upgraded.

+1 to remove mention from ref-guide.

PS: If the upgrader tool was able to patch the original-index-version from the 
binary 
index (and user understands the risks), then there could be some utility. But 
I'm not
aware of such an option.

Jan

> 3. juni 2024 kl. 21:20 skrev Gus Heck :
> 
> I've fielded many questions on this from clients. Folks who have managed
> databases expect to be able to upgrade the data serially across versions
> and such, so these questions come up alot with organizations early in their
> journey with search. Essentially, I tell them that it's a stop gap tool for
> use if there's a serious security issue and you really need to move up one
> version to get away from the security issue, but otherwise the correct
> procedure is to re-index. (And this is sometimes when I find out if they've
> really planned for reindexing or not). A down-side of the existence of this
> tool is that its presence in the ref guide allows people to prolong the
> period where they confuse managing a search index with managing a database.
> That said, I think it may have a place to help folks who got going without
> knowing enough about search engines to extend the period they have to dig
> themselves out of bad situations (by allowing an upgrade while they figure
> out how they are going to handle re-indexing more data than they previously
> planned on indexing all at once). So far every one of my clients has taken
> my advice and simply re-indexed (though not always without grumbling!), so
> I have to admit I've not actually seen it used, but in theory it makes some
> sense.
> 
> -Gus
> 
> On Mon, Jun 3, 2024 at 2:20 PM David Smiley  wrote:
> 
>> FWIW, in my experience I've never run this tool (nor colleagues) at
>> any stage in my career that I can remember.  For one reason, all the
>> systems could re-index if they needed to.
>> It may be best to remove this information, as it could introduce more
>> confusion than it helps.
>> 
>> On Mon, Jun 3, 2024 at 1:34 PM Jason Gerlowski 
>> wrote:
>>> 
>>> Hey all,
>>> 
>>> I was poking around the ref-guide a bit recently and noticed our page
>>> on the "IndexUpgraderTool" that Lucene produces. [1]
>>> 
>>> AFAICT, the page doesn't hint at when/why a user might want to use the
>>> IndexUpgraderTool.  Maybe at one point the tool might've been
>>> preferred to loading the index in an upgraded Solr version, but I
>>> haven't heard of anyone doing that in the last few years.
>>> 
>>> Is this something we expect users to still do?  If so, for what
>>> usecase?  And if not - should we drop it from the ref-guide - it seems
>>> like it might confuse folks since it's not actually needed to upgrade
>>> Solr versions...
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>>> [1]
>> https://solr.apache.org/guide/solr/latest/deployment-guide/indexupgrader-tool.html
>>> 
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 
> 
> -- 
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)

Re: SIP-18: A Solr Kubernetes Module for native integration

[Jan Høydahl]

I think of this from time to time. To get some progress, should be first agree 
in this thread that it is a decent idea, and that a new Solr module is 
warranted for this?

I'd hate to see good initatives like this to he held up by arguments not 
related to the code itself but to the lifecycle or wish for separate git repos 
etc.

Once we agree to move forward, the JIRA could be split up into manageable tasks 
that more community members could help with.

Jan

On 2023/04/05 16:45:26 Houston Putman wrote:
> Hey everyone,
> 
> This is a new SIP, not a duplicate of SIP-17 (Authoscaling on Kubernetes),
> and completely unrelated.
> 
> Basically there is a lot of very messy logic we do in the Solr Operator to
> bootstrap security and manage various things. This logic must exist because
> Solr has no idea that Kubernetes exists.
> If we can use Kubernetes APIs to pull in information, instead of relying on
> the Solr Operator to inject that information in hacky-ways, the user
> experience on Kubernetes is going to get many times better for users
> wanting to secure their SolrClouds. This will also help us use
> authorization by default (which we always preach) via the Solr Operator.
> 
> This SIP is not very filled out because I'm still thinking on various
> aspects. But in general, we can attack the different plugins one-by-one and
> the SIP can evolve throughout the process. This SIP is very easy to break
> up, which is nice.
> 
> Please let me know if I can explain more, or how I can make the SIP page
> better.
> 
> - Houston
> 

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

Re: [VOTE] Release Solr 9.6.1 RC1

[Jan Høydahl]

+1

SUCCESS! [0:45:03.659058]

-Jan

> 23. mai 2024 kl. 21:39 skrev Houston Putman :
> 
> Please vote for release candidate 1 for Solr 9.6.1
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.1-RC1-rev-d7f7166567f52f1b31e3315b0188e11f2c4c9b60
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.1-RC1-rev-d7f7166567f52f1b31e3315b0188e11f2c4c9b60
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.1-RC1-rev-d7f7166567f52f1b31e3315b0188e11f2c4c9b60/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.6.1/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.6.1-1 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.6.1/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.6.1-1-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-05-29 20:00 UTC.
> (Extended due to weekend and US holiday)
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1


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

Re: Welcome Sanjay Dutt as Solr committer!

[Jan Høydahl]

Welcome on board Sanjay, thrilled to see the community grow. Thanks also for 
introducing yourself and for explaining Open Source to your Mom in such a 
simple way 😁

Jan

> 20. mai 2024 kl. 18:23 skrev David Smiley :
> 
> The Project Management Committee (PMC) for Apache Solr has invited
> Sanjay Dutt to become a committer and we are pleased to announce that
> they have accepted.
> 
> Sanjay, the tradition is that new committers introduce themselves with
> a brief bio.
> 
> Congratulations and welcome!
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Want to make your first contribution to Solr?

[Jan Høydahl]

Hi,

Are you part of the community and looking for places to contribute?
A good first issue is https://issues.apache.org/jira/browse/SOLR-17295 where we 
simply
want to add a new download link on the webapge for the new OpenAPI artifact.

It should be an easy win to get your feet wet.

Reply directly in the JIRA issue if you want to pursue the task.

PS: You can filter JIRA tasks with the "newdev" label 

 for tips on other simple beginner tasks

Jan

Re: solr query alerting

[Jan Høydahl]

Alerting, while overloaded is probably the most precise name we could choose - 
documentation would help explain the scope.
And if someone made an example project with a UI for experimentation that would 
make the feature much more approachable.

Jan

> 2. mai 2024 kl. 03:18 skrev Walter Underwood :
> 
> The functionality is alerts, but that doesn’t mean it has to be a push API. 
> Alerts can be fetched just as easily as pushed.
> 
> I don’t know the limits of this proposal, but LexisNexis needs alerting as we 
> move all of our 114 billion documents onto Solr. I’m retiring this week, so I 
> won’t be around to implement it, but that is one potential large customer.
> 
> wunder
> Walter Underwood
> wun...@wunderwood.org
> http://observer.wunderwood.org/  (my blog)
> 
>> On May 1, 2024, at 2:26 PM, Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD A) 
>>  wrote:
>> 
>>> I kind of like "search-alerts". "query-alerts" sounds like alerting on
>>> query metrics, but IMO "search-alerts" doesn't come with the same baggage.
>> 
>> Someone in the PR had mentioned that "alerts" is a bit off because the 
>> proposal does not really manage alerts and it feels too far out of solr's 
>> domain. The current approach, much like percolator, simply exposes a 
>> request/response API that then can be **used** by an alerting system 
>> (request/stream could also be considered if there is worry about 
>> scaling the number of queries one request can match). 
>> 
>>> I think this is certainly something that can start in the sandbox and move> 
>>> into the main repo once it's clear that there is interest from
>>> multiple committers and community members in using and maintaining it.
>> 
>> I've seen many homegrown/complex solutions of percolator-type functionality 
>> so even this narrower "inverted search" solution has **some** use but 
>> admittedly this is a niche area. It might not really gain traction unless it 
>> is marketed the right way as there are probably very few solr users that 
>> happen to be thinking about revamping their saved-search platform in any 
>> given year. Given that, what do you think I can do to reach them? :-)
>> 
>> I am trying my best to talk about this within my firm but the sample is 
>> obviously smaller.
>> 
>> From: dev@solr.apache.org At: 05/01/24 16:16:50 UTC-4:00To:  
>> dev@solr.apache.org
>> Subject: Re: solr query alerting
>> 
>> I think I'd prefer a more self-descriptive name than "Luwak", which is just
>> a product name that was decided a while ago.
>> 
>> I kind of like "search-alerts". "query-alerts" sounds like alerting on
>> query metrics, but IMO "search-alerts" doesn't come with the same baggage.
>> 
>> Luwak is fine though if everyone agrees on that.
>> 
>> On one hand we have a number of committers here from
>>> Bloomberg, yet the abandoned and now-removed "analytics" component
>>> shows that abandonment is a risk nonetheless.
>>> 
>> 
>> I don't want to bikeshed here, but I'm not sure this is a fair
>> assessment of what happened with the analytics module.
>> Sure there wasn't a ton of development, but in general it was feature rich
>> and had very little feature requests.
>> It was removed in 10, because a lack of user usage, not because it was
>> "abandoned" IMO. If there were requests from users
>> to keep it or improve it, then it would be a much different story. The
>> whole "thrown over the wall" comment is fair, but
>> not particularly relevant to this PR, which is being worked on in public.
>> 
>> I think this is certainly something that can start in the sandbox and move
>> into the main repo once it's clear that there is interest from
>> multiple committers and community members in using and maintaining it.
>> 
>> - Houston
>> 
>> On Wed, May 1, 2024 at 2:32 PM David Smiley  wrote:
>> 
>>> Luwak is good to me!
>>> 
>>> On Tue, Apr 30, 2024 at 4:01 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD
>>> A)  wrote:
>>>> 
>>>> I love the name "luwak"! I was about to suggest the same but was worried
>>> about the trademark concerns and I assumed there was a reason they changed
>>> the name when donating it to lucene.
>>>> 
>>>> From: dev@solr.apache.org At: 04/30/24 15:56:22 UTC-4:00To:
>>> dev@solr.apache.org
>>>> Subject: Re: solr query alerting

Re: solr query alerting

[Jan Høydahl]

Luwak is the original name of the Lucene monitor, contributed by Flax back in 
the days: https://github.com/flaxsearch/luwak

Perhaps we could go full circle (if no trademark issues) to call it the Solr 
luwak module? Luwak is a type of coffee, and thus related to percolator 😉

Otherwise “stored-queries” is an option.

Jan Høydahl

> 30. apr. 2024 kl. 19:26 skrev David Smiley :
> 
> I agree the feature is relevant / useful.
> 
> Another angle on the module vs sandbox or wherever else is maintenance
> cost.  If a lot of code is being contributed as is here, then as a PMC
> member I hope to get a subjective sense that folks are interested in
> maintaining it.  On one hand we have a number of committers here from
> Bloomberg, yet the abandoned and now-removed "analytics" component
> shows that abandonment is a risk nonetheless.  I don't know how to
> conclude this thought but I'm hoping to hear from folks that they
> intend to look after this module.  It's not just being "thrown over
> the wall", so to speak.
> 
> Naming is hard...
> * ...-monitor-: sorry I hate it
> * ...-percolator- No clue why this was chosen for ElasticSearch.
> I can appreciate a curious/non-obvious name like this that is not
> going to conflict with anyone's guesses at what a general name might
> convey.
> * "indexed-queries" or "query-indexing" would be a good name?  This is
> the best technical name I can think of.
> *  "reverse search" came to mind (based on the Netflix article)
> although that makes me think of leading-wildcard / suffix-search.
> * "inverted-search"
> *  "indexed-query-alerts" incorporates "alerts" thus might better
> convey the use-case
> 
>> On Mon, Apr 1, 2024 at 3:53 PM Luke Kot-Zaniewski (BLOOMBERG/ 919 3RD
>> A)  wrote:
>> 
>> Hi All,
>> 
>> A few months ago I wrote the user list about potentially integrating lucene 
>> monitor into solr. I have raised this PR with a first attempt at 
>> implementing this integration. I'd greatly appreciate any feedback on this 
>> even though I still have it marked as draft. I want to make sure I'm heading 
>> in the right direction here so input from solr dev community would be 
>> extremely valuable :-)
>> 
>> Many thanks,
>> Luke
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

Re: SolrJ HTTP SolrClient class hierarchy

[Jan Høydahl]

There is an umbrella issue for major SolrJ changes 
https://issues.apache.org/jira/browse/SOLR-15730. Some of the sub tasks are 
10.0 only. Could add a rename jira there?

Jan

> 30. apr. 2024 kl. 15:04 skrev Eric Pugh :
> 
> Please!   It would be nice if someone laid out the work to be done in some 
> tickets so folks could pick it up….  Otherwise it looks a bit daunting!
> 
>> On Apr 30, 2024, at 7:38 AM, Jan Høydahl  wrote:
>> 
>> In Solr 10, SolrJ will have new maven coordinates and the need to explicitly 
>> pull in solrj-xx dependencies. So we coult also do a few key renames such as 
>> "Http2SolrClient" -> "HttpJettySolrClient", while we're busy breaking things 
>> :)
>> 
>> Jan
>> 
>>> 30. apr. 2024 kl. 13:21 skrev Jason Gerlowski :
>>> 
>>> Thanks for summarizing this all David!
>>> 
>>> We have HttpSolrClientBase AND BaseHttpSolrClient?!
>>> 
>>> A bit of the messiness here seems like it will resolve itself
>>> "automatically" if we make good on removing the existing deprecations.
>>> (Though given how "entrenched" the Apache client is, that will require
>>> a good bit of work...).
>>> 
>>> I like the convention established by the JDK client, of naming our
>>> low-level SolrClient implementations based on the HttpClient vendor in
>>> use.  IMO doing otherwise can be confusing in a few different ways.
>>> It's not high on my list to act on it immediately, but if there's
>>> enough consensus on the idea of renaming (e.g.) Http2SolrClient, I
>>> could file a ticket to document that as an ideal step and maybe it'll
>>> hook someone eventually?
>>> 
>>> Best,
>>> 
>>> Jason
>>> 
>>> On Thu, Apr 25, 2024 at 11:34 PM Mark Miller  wrote:
>>>> 
>>>> It's too bad HttpSolrServer setup this client philosophy. It's momentum 
>>>> was directly opposite to what you want: a SolrClient that can optionally 
>>>> stream or load balance and a SolrCloudClient that wraps it.
>>>> 
>>>> [Mark Miller - Chat @ 
>>>> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=2kigx5)  
>>>> [2kigx5]
>>>> 
>>>> On April 25, 2024 at 20:07 GMT, David Smiley  wrote:
>>>> 
>>>> Our SolrJ class hierarchy is looking rather confusing right now for
>>>> the HTTP ones especially. This message is mostly a big FYI, with some
>>>> reflections and a recommendation or two.
>>>> 
>>>> SolrClient
>>>> - BaseHttpSolrClient (NOT yet deprecated but should be?)
>>>> - - HttpSolrClient (based on Apache HttpClient; deprecated)
>>>> - - - DelegationTokenHttpSolrClient
>>>> - CloudSolrClient
>>>> - - CloudHttp2SolrClient
>>>> - - CloudLegacySolrClient (based on Apache HttpClient; deprecated)
>>>> - ConcurrentUpdateHttp2SolrClient
>>>> - - ...
>>>> - ConcurrentUpdateSolrClient (based on Apache HttpClient; deprecated)
>>>> - - ...
>>>> - HttpSolrClientBase (this is new)
>>>> - - Http2SolrClient
>>>> - - HttpJdkSolrClient (this is new; based on the JDK HttpClient)
>>>> - LBSolrClient
>>>> - - LBHttp2SolrClient
>>>> - - LBHttpSolrClient (based on Apache HttpClient; deprecated)
>>>> 
>>>> In retrospect, we can see that some past names weren't so great after
>>>> all. I think our clients should reflect the vendor/source of the
>>>> HttpClient. "HttpJdkSolrClient" is the newest client, and it reflects
>>>> the vendor (JDK provided HttpClient). Personally I don't care enough
>>>> to rename all the ones with "2" in there to have "Jetty" but that's
>>>> what they are -- if it has a "2", it's using Jetty (and it supports
>>>> 1.1; FYI JDK also supports both 1.1 and 2 as well). The clients for
>>>> Apache HttpClient are all deprecated so perhaps we continue to leave
>>>> them be, mostly. Removing them will take some time; they are
>>>> entrenched! BaseHttpSolrClient (the parent of HttpSolrClient) is at
>>>> the moment even more confusing because HttpSolrClientBase was just
>>>> added. BaseHttpSolrClient should be removed now; it only holds 2
>>>> static inner classes for RemoteSolrException and
>>>> RemoteExecutionExceptio

Re: SolrJ HTTP SolrClient class hierarchy

[Jan Høydahl]

In Solr 10, SolrJ will have new maven coordinates and the need to explicitly 
pull in solrj-xx dependencies. So we coult also do a few key renames such as 
"Http2SolrClient" -> "HttpJettySolrClient", while we're busy breaking things :)

Jan

> 30. apr. 2024 kl. 13:21 skrev Jason Gerlowski :
> 
> Thanks for summarizing this all David!
> 
> We have HttpSolrClientBase AND BaseHttpSolrClient?!
> 
> A bit of the messiness here seems like it will resolve itself
> "automatically" if we make good on removing the existing deprecations.
> (Though given how "entrenched" the Apache client is, that will require
> a good bit of work...).
> 
> I like the convention established by the JDK client, of naming our
> low-level SolrClient implementations based on the HttpClient vendor in
> use.  IMO doing otherwise can be confusing in a few different ways.
> It's not high on my list to act on it immediately, but if there's
> enough consensus on the idea of renaming (e.g.) Http2SolrClient, I
> could file a ticket to document that as an ideal step and maybe it'll
> hook someone eventually?
> 
> Best,
> 
> Jason
> 
> On Thu, Apr 25, 2024 at 11:34 PM Mark Miller  wrote:
>> 
>> It's too bad HttpSolrServer setup this client philosophy. It's momentum was 
>> directly opposite to what you want: a SolrClient that can optionally stream 
>> or load balance and a SolrCloudClient that wraps it.
>> 
>> [Mark Miller - Chat @ 
>> Spike](https://spikenow.com/r/a/?ref=spike-organic-signature&_ts=2kigx5)  
>> [2kigx5]
>> 
>> On April 25, 2024 at 20:07 GMT, David Smiley  wrote:
>> 
>> Our SolrJ class hierarchy is looking rather confusing right now for
>> the HTTP ones especially. This message is mostly a big FYI, with some
>> reflections and a recommendation or two.
>> 
>> SolrClient
>> - BaseHttpSolrClient (NOT yet deprecated but should be?)
>> - - HttpSolrClient (based on Apache HttpClient; deprecated)
>> - - - DelegationTokenHttpSolrClient
>> - CloudSolrClient
>> - - CloudHttp2SolrClient
>> - - CloudLegacySolrClient (based on Apache HttpClient; deprecated)
>> - ConcurrentUpdateHttp2SolrClient
>> - - ...
>> - ConcurrentUpdateSolrClient (based on Apache HttpClient; deprecated)
>> - - ...
>> - HttpSolrClientBase (this is new)
>> - - Http2SolrClient
>> - - HttpJdkSolrClient (this is new; based on the JDK HttpClient)
>> - LBSolrClient
>> - - LBHttp2SolrClient
>> - - LBHttpSolrClient (based on Apache HttpClient; deprecated)
>> 
>> In retrospect, we can see that some past names weren't so great after
>> all. I think our clients should reflect the vendor/source of the
>> HttpClient. "HttpJdkSolrClient" is the newest client, and it reflects
>> the vendor (JDK provided HttpClient). Personally I don't care enough
>> to rename all the ones with "2" in there to have "Jetty" but that's
>> what they are -- if it has a "2", it's using Jetty (and it supports
>> 1.1; FYI JDK also supports both 1.1 and 2 as well). The clients for
>> Apache HttpClient are all deprecated so perhaps we continue to leave
>> them be, mostly. Removing them will take some time; they are
>> entrenched! BaseHttpSolrClient (the parent of HttpSolrClient) is at
>> the moment even more confusing because HttpSolrClientBase was just
>> added. BaseHttpSolrClient should be removed now; it only holds 2
>> static inner classes for RemoteSolrException and
>> RemoteExecutionException which should find a new home somewhere.
>> Since they are referenced so much, that will happen only in main.
>> HttpSolrClientBase is a tempting home but SolrClient would be fine, I
>> think.
>> 
>> Also, just because we have a nice new HttpJdkSolrClient, doesn't mean
>> we can yet advise anyone to safely remove Apache & Jetty dependencies
>> *yet*! We have no tests that this works, and a quick attempt I did
>> recently showed there are some obscure references still! Modularizing
>> SolrJ further (for Jetty & Apache) will help reveal where we have some
>> references, after which we can finally free users of needing those
>> dependencies.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Re: Tracking contributors uniquely

[Jan Høydahl]

> A script to use git commit data to help create CHANGES entries (or look 
> for CHANGES entries that are missing credit) seems like a good sanity 
> check to ensuring nothing trivial is overlooked in CHANGES.

That's an interesting idea. Not to add CHANGES entries for the smallest 
ref-guide typo.
Most PRs that link to a JIRA should be significant enough to have a CHANGES, so
if we enumerate all commits with JIRA links, and all CHANGES entries wil JIRA 
link,
then highlighting the diff would help the RM complete CHANGES and also find 
missing 
contributors. I like pet projects like this, perhaps I find some spare time.

Jan

> 27. apr. 2024 kl. 03:45 skrev Chris Hostetter :
> 
> 
> : LOL meanwhile I posted https://github.com/apache/solr/pull/2424 for
> : the script I developed and improved today.
> : I think CHANGES.txt is the best source for a release centric view
> : while git log is best for project health metrics.
> 
> Agreed.  People are frequently mentioned in CHANGES because they 
> contributed to the *issue* even when they didn't contribute to the *code* 
> (ie: reported & diagnosed a bug, aided in design discussions, etc..)
> 
> A script to use git commit data to help create CHANGES entries (or look 
> for CHANGES entries that are missing credit) seems like a good sanity 
> check to ensuring nothing trivial is overlooked in CHANGES.
> 
> A script to generate a thank you list of contributors should be based on 
> the list of contributors from CHANGES (regardless of how they got there)
> 
> 
> 
> : On Fri, Apr 26, 2024 at 4:38 PM Jan Høydahl  wrote:
> : >
> : > I think it is a good idea to include a list of contributors in the 
> release note mail.
> : > it is a tiny encouragement for folks to contribute more. The list should 
> perhaps
> : > be excluding committers, so we only list external contributors?
> : >
> : > I already added a script to dev-tools to parse SolrBot contributions from 
> git log and add to CHANGES:
> : > 
> https://github.com/apache/solr/blob/main/dev-tools/scripts/addDepsToChanges.py
> : >
> : > Based on this I did a similar script that parses out Authors and 
> Co-Authored-By from git log
> : > since last release, see https://github.com/apache/solr/pull/2423 for a 
> Draft.
> : >
> : > There's a risk of this method missing the names of some contributors who 
> did not actually commit anything to a PR but still are listed in CHANGES for 
> the release. That can be fixed by us being more careful when merging PRs, and 
> when committing patches from JIRA,
> : >
> : > Jan
> : >
> : > > 26. apr. 2024 kl. 15:39 skrev David Smiley :
> : > >
> : > > On Fri, Apr 26, 2024 at 9:35 AM Gus Heck  wrote:
> : > >>
> : > >> I don't know if it's relevant, but I recall that back in the early 
> 2000's
> : > >> around the time of the adoption of the ASL 2.0 (when I was 
> contributing to
> : > >> Ant) the ASF had us stop using @author tags in code. I was not a fan 
> at the
> : > >> time, but they had some reason I don't fully recall relating to 
> shielding
> : > >> the contributors in the event of someone hitting a bug and then trying 
> to
> : > >> sue folks to recover losses or something. I wonder if that logic still
> : > >> exists, and if this could be seen as related to that. It's also 
> possible
> : > >> that this memory has severely mutated while hanging out in the back of 
> my
> : > >> brain for 20 year :).
> : > >
> : > > The context of the name appearing as I propose in a "thank you" is
> : > > merely to thank them, not to indirectly hold them to stability/quality
> : > > measures.
> : > >
> : > > I don't think it's related.  @author tags can repel a collaborative
> : > > ownership mindset on a specific bit of code.  I used to @author my
> : > > code out of pride but long ago I realized those tags are a bad idea
> : > > and also kind of needless with git-blame anyway.
> : > >
> : > > -
> : > > To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> : > > For additional commands, e-mail: dev-h...@solr.apache.org
> : > >
> : >
> : 
> : -
> : To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> : For additional commands, e-mail: dev-h...@solr.apache.org
> : 
> : 
> 
> -Hoss
> http://www.lucidworks.com/
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org


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

Re: Tracking contributors uniquely

[Jan Høydahl]

I think it is a good idea to include a list of contributors in the release note 
mail.
it is a tiny encouragement for folks to contribute more. The list should perhaps
be excluding committers, so we only list external contributors?

I already added a script to dev-tools to parse SolrBot contributions from git 
log and add to CHANGES:
https://github.com/apache/solr/blob/main/dev-tools/scripts/addDepsToChanges.py

Based on this I did a similar script that parses out Authors and Co-Authored-By 
from git log
since last release, see https://github.com/apache/solr/pull/2423 for a Draft.

There's a risk of this method missing the names of some contributors who did 
not actually commit anything to a PR but still are listed in CHANGES for the 
release. That can be fixed by us being more careful when merging PRs, and when 
committing patches from JIRA, 

Jan

> 26. apr. 2024 kl. 15:39 skrev David Smiley :
> 
> On Fri, Apr 26, 2024 at 9:35 AM Gus Heck  wrote:
>> 
>> I don't know if it's relevant, but I recall that back in the early 2000's
>> around the time of the adoption of the ASL 2.0 (when I was contributing to
>> Ant) the ASF had us stop using @author tags in code. I was not a fan at the
>> time, but they had some reason I don't fully recall relating to shielding
>> the contributors in the event of someone hitting a bug and then trying to
>> sue folks to recover losses or something. I wonder if that logic still
>> exists, and if this could be seen as related to that. It's also possible
>> that this memory has severely mutated while hanging out in the back of my
>> brain for 20 year :).
> 
> The context of the name appearing as I propose in a "thank you" is
> merely to thank them, not to indirectly hold them to stability/quality
> measures.
> 
> I don't think it's related.  @author tags can repel a collaborative
> ownership mindset on a specific bit of code.  I used to @author my
> code out of pride but long ago I realized those tags are a bad idea
> and also kind of needless with git-blame anyway.
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

Re: [VOTE] Release Solr 9.6.0 RC1

[Jan Høydahl]

I got a docker build run working, even if most still fail. I hope this is 
nothing that will cause problems when building official docker image.

Changin my vote to +1 (binding).

Jan

> 23. apr. 2024 kl. 13:09 skrev Jan Høydahl :
> 
> Hi,
> 
> Smoketester succeeds:
> SUCCESS! [0:45:28.467115]
> 
> But I cannot get the docker build to pass:
> It seems to fail during GPG validation of your key during image build:
> 
>> gpg: key 140BC45803B03F7F: public key "Patrick Gustav Heck (CODE SIGNING 
>> KEY) " imported
>> gpg: can't connect to the agent: IPC connect call failed
>> gpg: Total number processed: 1
>> gpg:   imported: 1
>> 
> 
> Not sure if that is the reason, but some command in the RUN line 30- fail.
> 
> +0
> 
> Jan
> 
>> 23. apr. 2024 kl. 07:05 skrev Gus Heck :
>> 
>> Please vote for release candidate 1 for Solr 9.6.0
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57
>> 
>> You can build a release-candidate of the official docker images (full &
>> slim) using the following command:
>> 
>> SOLR_DOWNLOAD_SERVER=
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr
>> && \
>> docker build $SOLR_DOWNLOAD_SERVER/9.6.0/docker/Dockerfile.official-full \
>>  --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>  -t solr-rc:9.6.0-1 && \
>> docker build $SOLR_DOWNLOAD_SERVER/9.6.0/docker/Dockerfile.official-slim \
>>  --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>  -t solr-rc:9.6.0-1-slim
>> 
>> The vote will be open for at least 72 hours i.e. until 2024-04-26 06:00 UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1
>> 
>> 
>> -- 
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)
> 


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

Re: [VOTE] Release Solr 9.6.0 RC1

[Jan Høydahl]

Hi,

Smoketester succeeds:
SUCCESS! [0:45:28.467115]

But I cannot get the docker build to pass:
It seems to fail during GPG validation of your key during image build:

> gpg: key 140BC45803B03F7F: public key "Patrick Gustav Heck (CODE SIGNING KEY) 
> " imported
> gpg: can't connect to the agent: IPC connect call failed
> gpg: Total number processed: 1
> gpg:   imported: 1
> 

Not sure if that is the reason, but some command in the RUN line 30- fail.

+0

Jan

> 23. apr. 2024 kl. 07:05 skrev Gus Heck :
> 
> Please vote for release candidate 1 for Solr 9.6.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.6.0-RC1-rev-f8e5a93c11267e13b7b43005a428bfb910ac6e57/solr
> && \
> docker build $SOLR_DOWNLOAD_SERVER/9.6.0/docker/Dockerfile.official-full \
>   --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>   -t solr-rc:9.6.0-1 && \
> docker build $SOLR_DOWNLOAD_SERVER/9.6.0/docker/Dockerfile.official-slim \
>   --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>   -t solr-rc:9.6.0-1-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-04-26 06:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1
> 
> 
> -- 
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)


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

Re: Release wizard logic issue? Assumptions?

[Jan Høydahl]

Hi,

The error message is perhaps not too helpful for how to proceed.

I believe you have initialized the wizard already for a bugfix release.
See $HOME/.solrrc if there is a version set already. Then it will complain 
since it believes you are to release a bugfix from stable branch.

You can re-initialize the wizard with

dev-tools/scripts/releaseWizard.py --init

Hope that helps. The error message should probably mention that release x.y.z 
is already in progress and the --init option.

Jan

> 22. apr. 2024 kl. 15:28 skrev Gus Heck :
> 
> Except it quit with an error complaining about the version before the
> checkout step in the menus (or any menus)...  so it does look at the local
> checkout for that...
> 
> On Mon, Apr 22, 2024 at 9:11 AM Jan Høydahl  wrote:
> 
>> You don't need to run the wizard from a pristine checkout, or even from
>> the clone in .solr-releases/
>> The only requirement is that you run the wizard from some recent enough
>> checkout of the correct branch.
>> The wizard will not use the "current" git repo for anything else than for
>> reading releaseWizard.py and releaseWizard.yaml.
>> The actual release will always be a fresh clone in .solr-releases/
>> 
>> So if you quit for the day and want to resume the release tomorrow, you
>> just go to some Solr checkout, do a git checkout branch_9x, and then run
>> the wizard.
>> If you need to do bug fixes to the wizard itself during the release, you
>> can do so in your own clone, and then make a PR for any wizard fixes after
>> the release is done.
>> Fixes to the wizard itself is most often put in main then back-ported to
>> stable branch. Then if a RM is to do a bugfix release she should first
>> consider whether the wizard is up to date on that branch.
>> 
>> Likewise, if you do a major release, you'll run the wizard from "main"
>> branch. If you do a bugfix release 9.5.x then you'll run the wizard from
>> branch_9_5.
>> 
>> I'm sure there was some reason for this design back then. I think the
>> reason was that the wizard code and steps could actually differ between
>> versions, since e.g. main branch may include new features that demand
>> special treatment during release. One such is the JDK version requirement
>> that is checked at start. I'm sure you'll find others by diffing wizard
>> between branches.
>> 
>> Jan
>> 
>> 
>>> 22. apr. 2024 kl. 14:03 skrev Gus Heck :
>>> 
>>> Will definitely follow this release with some documentation of  what you
>>> just told and other basic "orientation". For example it refers to a
>> "root"
>>> folder but exactly what it intends for that folder is opaque until much
>>> later in the process (place for code? place for artifacts? root of what?)
>>> ... you have now told me but there's still some disconnect because if
>> it's
>>> creating such a root, prior to checkout how am I supposed to have the
>>> wizard to run in the first place if I haven't checked it out already...
>> so
>>> there's unclarity on "run it from a X and it does work in Y perspective.
>>> (or alternately perhaps it's intended to run it to point Z and then, stop
>>> and, re-run it in the checkout?)"
>>> 
>>> Having run it from within a pristine checkout of my own, it then would
>> not
>>> even get to the menus unless I commented out the highlighted line... And
>> it
>>> runs a bunch of checks and won't even get to the menus unless you fix
>> those
>>> prerequisites ... and then later one of the menu items tells you to
>> verify
>>> the same items.
>>> 
>>> -Gus
>>> 
>>> On Mon, Apr 22, 2024 at 5:30 AM Jan Høydahl 
>> wrote:
>>> 
>>>> Hi Gus
>>>> 
>>>> Could be documentation is weak, but the assumption is that for a minor
>>>> release you run the wizard from branch_9x.
>>>> 
>>>> The wizard will not run commands unless you ask it to, but it will
>>>> generate the command, print it, and once you accept it will be run. If
>> you
>>>> prefer for som reason to run a certain command manually you may do so,
>> and
>>>> when the script asks whether a step is done, you answer Y.
>>>> 
>>>> The script persists a FILE .solrrc on first run (whether dry or no),
>> which
>>>> will remember which folder you use for releases (default
>> ~/.solr-releases).
>>>> 
>>>> If you started the re

Re: Release wizard logic issue? Assumptions?

[Jan Høydahl]

You don't need to run the wizard from a pristine checkout, or even from the 
clone in .solr-releases/
The only requirement is that you run the wizard from some recent enough 
checkout of the correct branch.
The wizard will not use the "current" git repo for anything else than for 
reading releaseWizard.py and releaseWizard.yaml.
The actual release will always be a fresh clone in .solr-releases/

So if you quit for the day and want to resume the release tomorrow, you just go 
to some Solr checkout, do a git checkout branch_9x, and then run the wizard.
If you need to do bug fixes to the wizard itself during the release, you can do 
so in your own clone, and then make a PR for any wizard fixes after the release 
is done.
Fixes to the wizard itself is most often put in main then back-ported to stable 
branch. Then if a RM is to do a bugfix release she should first consider 
whether the wizard is up to date on that branch.

Likewise, if you do a major release, you'll run the wizard from "main" branch. 
If you do a bugfix release 9.5.x then you'll run the wizard from branch_9_5.

I'm sure there was some reason for this design back then. I think the reason 
was that the wizard code and steps could actually differ between versions, 
since e.g. main branch may include new features that demand special treatment 
during release. One such is the JDK version requirement that is checked at 
start. I'm sure you'll find others by diffing wizard between branches.

Jan


> 22. apr. 2024 kl. 14:03 skrev Gus Heck :
> 
> Will definitely follow this release with some documentation of  what you
> just told and other basic "orientation". For example it refers to a "root"
> folder but exactly what it intends for that folder is opaque until much
> later in the process (place for code? place for artifacts? root of what?)
> ... you have now told me but there's still some disconnect because if it's
> creating such a root, prior to checkout how am I supposed to have the
> wizard to run in the first place if I haven't checked it out already... so
> there's unclarity on "run it from a X and it does work in Y perspective.
> (or alternately perhaps it's intended to run it to point Z and then, stop
> and, re-run it in the checkout?)"
> 
> Having run it from within a pristine checkout of my own, it then would not
> even get to the menus unless I commented out the highlighted line... And it
> runs a bunch of checks and won't even get to the menus unless you fix those
> prerequisites ... and then later one of the menu items tells you to verify
> the same items.
> 
> -Gus
> 
> On Mon, Apr 22, 2024 at 5:30 AM Jan Høydahl  wrote:
> 
>> Hi Gus
>> 
>> Could be documentation is weak, but the assumption is that for a minor
>> release you run the wizard from branch_9x.
>> 
>> The wizard will not run commands unless you ask it to, but it will
>> generate the command, print it, and once you accept it will be run. If you
>> prefer for som reason to run a certain command manually you may do so, and
>> when the script asks whether a step is done, you answer Y.
>> 
>> The script persists a FILE .solrrc on first run (whether dry or no), which
>> will remember which folder you use for releases (default ~/.solr-releases).
>> 
>> If you started the release and branch cutting outside of the Wizard, you
>> should still be able to catch up by starting the wizard, and completing
>> each step until you come to the branch cutting part, where you simply skip
>> that command since it is already done. Note that the wizard performs all
>> operations on a pristine git clone inside .solr-releases, so you may have
>> to run a git fetch on that clone.
>> 
>> Feel free to ask for other questions. There are many former RMs here. And
>> also appreciated with PRs for the wizard itself should ther be bugs or
>> unclear documentation.
>> 
>> Jan
>> 
>>> 21. apr. 2024 kl. 22:08 skrev Gus Heck :
>>> 
>>> Also I just realized that despite --dry-run it seems to have written a
>>> .solrrc file in my home dir (it did not write it in ~/.solr-releases that
>>> it suggested as a root?)
>>> 
>>> it seems unexpected for --dry-run to leave persistent changes?
>>> 
>>> On Sun, Apr 21, 2024 at 3:37 PM Gus Heck  wrote:
>>> 
>>>> I had initiated dry runs a few times earlier this week and it stopped on
>>>> various dependencies, and I've not got those checks happy, but now I'm
>>>> getting:
>>>> 
>>>> "You can only release bugfix releases from an existing release branch"
>>>> 
>&g

Re: Is SolrBot too noisy / being ignored...?

[Jan Høydahl]

CHANGES for solrbot PRs is added during release by RM. You simply merge the PR.

Jan Høydahl

> 22. apr. 2024 kl. 12:58 skrev Eric Pugh :
> 
> Ah..   So we don’t quite yet know how to deal with the aws and google 
> libraries being constantly updated?
> 
> It looks like SolrBot opened PR’s get the “dependency” label added.   I 
> looked in Github PR’s, 
> https://github.com/apache/solr/pulls?page=2&q=is%3Apr+is%3Aopen+label%3Adependencies
>  and the list isn’t too long..  
> 
> There are a few candidates that look like they passed tests and are 
> straightforward to merge...
> 
> We are still putting these changes into solr/CHANGES.txt under Dependencies 
> right?
> 
> 
> 
>> On Apr 20, 2024, at 11:56 AM, Jan Høydahl  wrote:
>> 
>> The bot does not have and will not have commit rights. And if it auto merged 
>> it would only be main branch, and a committer would need to handle 9x anyway.
>> 
>> I still think the right medicine for aws and google deps is to open prs less 
>> frequently, if we find the right config spell in renovate.
>> 
>> I use the cherrypick script to backport to 9.x after merge, is very little 
>> overhead.
>> 
>> Jan Høydahl
>> 
>>>> 19. apr. 2024 kl. 22:46 skrev David Smiley :
>>> 
>>> I think it’s satisfactory if we merely have advice to ourselves in the PR
>>> to remind us what little we need to do. Like… if you are a committer and
>>> this is passing, just merge it.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> 
>>>> On Fri, Apr 19, 2024 at 7:51 AM Eric Pugh 
>>>> wrote:
>>>> 
>>>> From the perspective of commits being merged by a bot?
>>>> 
>>>> Assuming the legal side was okay, what are your thoughts about having the
>>>> commits be merged by a bot based on the criteria I suggested?  Crazy?
>>>> Reasonable?
>>>> 
>>>> 
>>>> 
>>>>>> On Apr 18, 2024, at 7:00 PM, Mike Drob  wrote:
>>>>> 
>>>>> That’s probably a question for asf legal
>>>>> 
>>>>> On Thu, Apr 18, 2024 at 5:36 PM Eric Pugh <
>>>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>>
>>>>> wrote:
>>>>> 
>>>>>> Thanks for the work that has been done on some of these.
>>>>>> 
>>>>>> I actually just ran through the process of updating commons-cli based on
>>>>>> what SolrBot provided.   I *did* have to update a Java class, and I did
>>>>>> regenerate the licenses, and that was about it…
>>>>>> 
>>>>>> Which made me wonder..   If SolrBot opens a dependency upgrade, and
>>>>>> recommit and the tests pass, could we have it just commit automatically
>>>> the
>>>>>> update?
>>>>>> 
>>>>>> I looked at one that I constantly see, the update to the awssdk:
>>>>>> https://github.com/apache/solr/pull/2056.   The tests all pass, and it
>>>>>> appears all I need to do to make precommit happy is drop in some new
>>>>>> licenses.   Other than that, I believe that I could merge that PR, and I
>>>>>> wouldn’t need to do any other steps….  So, if there were no new license
>>>> and
>>>>>> precommit had passed, couldn’t SolrBot merge it for us?
>>>>>> 
>>>>>> Basically, do we actually need a human in the loop on this when at least
>>>>>> this human, me, wouldn’t really be doing anything else if all the checks
>>>>>> passed….
>>>>>> 
>>>>>>> On Apr 9, 2024, at 8:01 AM, Eric Pugh >>>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>> The update that I see a lot is for the software.amazon.awssdk and
>>>>>> com.google.cloud packages….  I checked renovate.json and they should
>>>> only
>>>>>> happen once a month.
>>>>>>> 
>>>>>>> I just checked and there has been an update today, yesterday, and the
>>>>>> day before for the software.amazon.awssdk package.
>>>>>>> 
>>>>>>> Looks like they all go to https://github.com/apache/solr/pull/2056
>>>>>> however.  Is this because once it opens the PR, it is just updating the
>>>&g

Re: Fix version 9.6 vs 9.6.0

[Jan Høydahl]

Hi,

The wizard contains a step to create the NEXT version in Jira: 
https://github.com/apache/solr/blob/main/dev-tools/scripts/releaseWizard.yaml#L662
 I believe perhaps that instruction uses the x.y.0 pattern for minor releases. 
If so, that is a wizard bug.

It also contains a Post-Release step to mark a version as Released:
https://github.com/apache/solr/blob/main/dev-tools/scripts/releaseWizard.yaml#L1722-L1733


Reminder to RMs: The release is not done until all post-release checkboxes are 
ticked in the wizard.

Jan

> 22. apr. 2024 kl. 04:33 skrev David Smiley :
> 
> Whoever created the JIRA "release" named "9.6.0" (and 9.5.0 for that
> matter) made a small mistake; it should have been 9.6 (and 9.5) based
> on past conventions.  You should simply re-assign the existing issues
> using 9.6 (there are only 2), *delete* that one, then *rename* "9.6.0"
> to "9.6".  And rename 9.5.0 to 9.5 for that matter.
> 
> I also noticed that we are not updating the status of each release to
> be of state "Released" (via the "Build & Release" action)
> consistently.  Not sure what consequence there is to it but
> nonetheless it ought to be added to the release wizard if it isn't
> there already.
> 
> On Sun, Apr 21, 2024 at 10:08 PM Gus Heck  wrote:
>> 
>> It seems in the last couple of point releases we've tagged stuff as 9.4 and
>> 9.5 in Jira, but this time around 9.6.0 has been used in 59 out of 61
>> issues...
>> 
>> I'm guessing, we want to bulk change all of that to 9.6 to match prior
>> releases...
>> 
>> LMK if this doesn't sound right, or I missed the memo on a change in
>> practice.
>> 
>> -Gus
>> 
>> --
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

Re: Release wizard logic issue? Assumptions?

[Jan Høydahl]

Hi Gus

Could be documentation is weak, but the assumption is that for a minor release 
you run the wizard from branch_9x.

The wizard will not run commands unless you ask it to, but it will generate the 
command, print it, and once you accept it will be run. If you prefer for som 
reason to run a certain command manually you may do so, and when the script 
asks whether a step is done, you answer Y.

The script persists a FILE .solrrc on first run (whether dry or no), which will 
remember which folder you use for releases (default ~/.solr-releases).

If you started the release and branch cutting outside of the Wizard, you should 
still be able to catch up by starting the wizard, and completing each step 
until you come to the branch cutting part, where you simply skip that command 
since it is already done. Note that the wizard performs all operations on a 
pristine git clone inside .solr-releases, so you may have to run a git fetch on 
that clone.

Feel free to ask for other questions. There are many former RMs here. And also 
appreciated with PRs for the wizard itself should ther be bugs or unclear 
documentation.

Jan

> 21. apr. 2024 kl. 22:08 skrev Gus Heck :
> 
> Also I just realized that despite --dry-run it seems to have written a
> .solrrc file in my home dir (it did not write it in ~/.solr-releases that
> it suggested as a root?)
> 
> it seems unexpected for --dry-run to leave persistent changes?
> 
> On Sun, Apr 21, 2024 at 3:37 PM Gus Heck  wrote:
> 
>> I had initiated dry runs a few times earlier this week and it stopped on
>> various dependencies, and I've not got those checks happy, but now I'm
>> getting:
>> 
>> "You can only release bugfix releases from an existing release branch"
>> 
>> The logic I see in the code doesn't make any sense...
>> 
>>def validate_release_version(self, branch_type, branch,
>> release_version):
>>ver = Version.parse(release_version)
>># print("release_version=%s, ver=%s" % (release_version, ver))
>>if branch_type == BranchType.release:
>>if not branch.startswith('branch_'):
>>sys.exit("Incompatible branch and branch_type")
>> 
>> * if not ver.is_bugfix_release():sys.exit("You can only
>> release bugfix releases from an existing release branch")*
>>elif branch_type == BranchType.stable:
>>if not branch.startswith('branch_') and branch.endswith('x'):
>>sys.exit("Incompatible branch and branch_type")
>>if not ver.is_minor_release():
>>sys.exit("You can only release minor releases from an
>> existing stable branch")
>>elif branch_type == BranchType.unstable:
>>if not branch == 'main':
>>sys.exit("Incompatible branch and branch_type")
>>if not ver.is_major_release():
>>sys.exit("You can only release a new major version from
>> main branch")
>>if not getScriptVersion() == release_version:
>>print("WARNING: Expected release version %s when on branch %s,
>> but got %s" % (
>>getScriptVersion(), branch, release_version))
>> 
>> It seems to be looking for something other than a X.Y.0 in order to do a
>> release that is not a bugfix release (is_bugfix_release checks that the
>> final digit is other than 0 )? but x.y.0 is correct for a non bugfix
>> release?
>> 
>> In any case this seems to be 100% blocking and I'll need to comment it
>> out... but I worry that there's some undocumented assumption that this
>> script has to be run before the branch is made and it's unclear what it's
>> going to try to do if the branch exists. Is it expecting to run its own VCS
>> commands? (I think it really should be suggesting commands that touch the
>> repo for human review, not running them if that's the case)
>> 
>> My first initial comment on this process is scripts are nice, but if they
>> are black boxes and there's no documentation of the intended process or
>> where the script comes into the process and what parts of the process the
>> script is handling, it's pretty hard to know how to use the script (or how
>> to know if it goes awry)
>> 
>> -Gus
>> 
>> --
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)
>> 
> 
> 
> -- 
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)


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

Re: Is SolrBot too noisy / being ignored...?

[Jan Høydahl]

The bot does not have and will not have commit rights. And if it auto merged it 
would only be main branch, and a committer would need to handle 9x anyway.

I still think the right medicine for aws and google deps is to open prs less 
frequently, if we find the right config spell in renovate.

I use the cherrypick script to backport to 9.x after merge, is very little 
overhead.

Jan Høydahl

> 19. apr. 2024 kl. 22:46 skrev David Smiley :
> 
> I think it’s satisfactory if we merely have advice to ourselves in the PR
> to remind us what little we need to do. Like… if you are a committer and
> this is passing, just merge it.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Fri, Apr 19, 2024 at 7:51 AM Eric Pugh 
>> wrote:
>> 
>> From the perspective of commits being merged by a bot?
>> 
>> Assuming the legal side was okay, what are your thoughts about having the
>> commits be merged by a bot based on the criteria I suggested?  Crazy?
>> Reasonable?
>> 
>> 
>> 
>>>> On Apr 18, 2024, at 7:00 PM, Mike Drob  wrote:
>>> 
>>> That’s probably a question for asf legal
>>> 
>>> On Thu, Apr 18, 2024 at 5:36 PM Eric Pugh <
>> ep...@opensourceconnections.com <mailto:ep...@opensourceconnections.com>>
>>> wrote:
>>> 
>>>> Thanks for the work that has been done on some of these.
>>>> 
>>>> I actually just ran through the process of updating commons-cli based on
>>>> what SolrBot provided.   I *did* have to update a Java class, and I did
>>>> regenerate the licenses, and that was about it…
>>>> 
>>>> Which made me wonder..   If SolrBot opens a dependency upgrade, and
>>>> recommit and the tests pass, could we have it just commit automatically
>> the
>>>> update?
>>>> 
>>>> I looked at one that I constantly see, the update to the awssdk:
>>>> https://github.com/apache/solr/pull/2056.   The tests all pass, and it
>>>> appears all I need to do to make precommit happy is drop in some new
>>>> licenses.   Other than that, I believe that I could merge that PR, and I
>>>> wouldn’t need to do any other steps….  So, if there were no new license
>> and
>>>> precommit had passed, couldn’t SolrBot merge it for us?
>>>> 
>>>> Basically, do we actually need a human in the loop on this when at least
>>>> this human, me, wouldn’t really be doing anything else if all the checks
>>>> passed….
>>>> 
>>>>> On Apr 9, 2024, at 8:01 AM, Eric Pugh >> 
>>>> wrote:
>>>>> 
>>>>> The update that I see a lot is for the software.amazon.awssdk and
>>>> com.google.cloud packages….  I checked renovate.json and they should
>> only
>>>> happen once a month.
>>>>> 
>>>>> I just checked and there has been an update today, yesterday, and the
>>>> day before for the software.amazon.awssdk package.
>>>>> 
>>>>> Looks like they all go to https://github.com/apache/solr/pull/2056
>>>> however.  Is this because once it opens the PR, it is just updating the
>> PR
>>>> as needed?
>>>>> 
>>>>> How can we get a smoother workflow?   The constant updates are noisy,
>>>> and now I think they are just ignored…!   I saw that Kevin approved this
>>>> back in November 2023.   Do we want to be more on top of these and
>> merge as
>>>> they go?
>>>>> 
>>>>> And maybe for these frequently changing ones, maybe move to a quarterly
>>>> schedule?   Or, do we add it to the release manager process, though I
>> know
>>>> that approach was discussed and then viewed as too burdensome for the
>> RM.
>>>>> 
>>>>> 
>>>>> 
>>>>> Eric
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> ___
>>>>> Eric Pugh | Founder | OpenSource Connections, LLC | 434.466.1467 |
>>>> http://www.opensourceconnections.com <
>>>> http://www.opensourceconnections.com/> | My Free/Busy <
>>>> http://tinyurl.com/eric-cal>
>>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed <
>>>> 
>> https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw
>>> 
>>>>

Re: Welcome Jason Gerlowski as Solr's new PMC Chair

[Jan Høydahl]

Thanks for your efforts David, and congrats Jason with the new hat.

Jan

> 18. apr. 2024 kl. 16:17 skrev David Smiley :
> 
> The PMC has voted Jason Gerlowski as Solr's new PMC Chair.  I am the
> outgoing chair.  The change was approved by the ASF board yesterday,
> April 17th.
> 
> Thanks for stepping up Jason!  I'll be happy to assist as needed.
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Re: enableRemoteStreaming+enableStreamBody-change in Solr 8.11.3

[Jan Høydahl]

Hi,

See my reply in users list as well.

This was a feature written for 9.3. It was then backported to 8.11 (by Ishan).
I had a look at the backport commit: 
https://github.com/apache/lucene-solr/commit/6e2272c4ccc and there are a few 
issues with the backport:

* The backport commit message mentions the env.variables, but the backport does 
not include changes to start scripts
* The backport does not change the ref.guide for 8.11, it still documents the 
old way of enabling remote streaming:
   https://solr.apache.org/guide/8_11/content-streams.html#remote-streaming

Since there is a workaround by setting the system properties directly, I don't 
think a code change is warranted.
However, the Reference Guide should both mention the breaking change in "Major 
Changes" section, and also
edit other places in the guide that mentions the old way of configuring remote 
streaming.

Ishan, will you handle the documentation?

The workaround is to set in solr.in.sh:

SOLR_OPTS="$SOLR_OPTS -Dsolr.enableRemoteStreaming=true 
-Dsolr.enableStreamBody=true"

Jan

> 12. apr. 2024 kl. 11:13 skrev Jan Høydahl :
> 
> Hi,
> 
> User questions like these are intended for the us...@solr.apache.org mailing 
> list. This list is for developing Solr.
> Please send your question to the users list and I'll followup with an answer.
> 
> Jan
> 
>> 12. apr. 2024 kl. 09:51 skrev Adam Sjøgren :
>> 
>> Hi,
>> 
>> 
>> I am looking at upgrading a Solr cluster from 8.11.2 to 8.11.3. Our
>> tests found that this entry in the release notes is relevant to the
>> way we use Solr:
>> 
>>   "SOLR-14853: Security: Converted enableRemoteStreaming and
>>enableStreamBody solrconfig options into system properties and env
>>vars. Attempts to set them the old way are no-op and log a warning."
>> 
>> · 
>> https://solr.apache.org/docs/8_11_3/changes/Changes.html#v8.11.3.other_changes
>> 
>> After looking at the Jira issue -
>> https://issues.apache.org/jira/browse/SOLR-14853 - I tried setting
>> SOLR_ENABLE_REMOTE_STREAMING=true and SOLR_ENABLE_STREAM_BODY=true in
>> solr.in.sh to enable remote streaming and stream body, as indicated by
>> the changes to bin/solr in the accompanying pull request:
>> 
>> · 
>> https://github.com/apache/solr/pull/1615/files#diff-49c29c8f653341f48008c38f5f2cf970fa430cdca29181c819d7bdcfcc722980R1853-R1860
>> 
>> But it didn't make a difference, I still got the error "Stream Body is
>> disabled. See 
>> http://lucene.apache.org/solr/guide/requestdispatcher-in-solrconfig.html
>> for help".
>> 
>> The reason seems to be that the bin/solr script in the binary package
>> solr-8.11.3.tgz doesn't have these changes indicated in the pull
>> request:
>> 
>>   $ wget 
>> https://www.apache.org/dyn/closer.lua/lucene/solr/8.11.3/solr-8.11.3.tgz?action=download
>>  [...]
>>   $ mv -i solr-8.11.3.tgz\?action\=download solr-8.11.3.tgz
>>   $ tar xf solr-8.11.3.tgz 
>>   $ grep STREAM solr-8.11.3/bin/solr
>>   $ 
>> 
>> Adding the changes into the bin/solr script myself works, but I am
>> wondering if I am using the wrong package or if those changes were
>> supposed to be there?
>> 
>> 
>> Best regards,
>> 
>>   Adam
>> 
>> -- 
>> "Some people like cupcakes better. Adam Sjøgren
>> I for one care less for them!"   a...@koldfront.dk
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
> 


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

Re: enableRemoteStreaming+enableStreamBody-change in Solr 8.11.3

[Jan Høydahl]

Hi,

User questions like these are intended for the us...@solr.apache.org mailing 
list. This list is for developing Solr.
Please send your question to the users list and I'll followup with an answer.

Jan

> 12. apr. 2024 kl. 09:51 skrev Adam Sjøgren :
> 
>  Hi,
> 
> 
> I am looking at upgrading a Solr cluster from 8.11.2 to 8.11.3. Our
> tests found that this entry in the release notes is relevant to the
> way we use Solr:
> 
>"SOLR-14853: Security: Converted enableRemoteStreaming and
> enableStreamBody solrconfig options into system properties and env
> vars. Attempts to set them the old way are no-op and log a warning."
> 
>  · 
> https://solr.apache.org/docs/8_11_3/changes/Changes.html#v8.11.3.other_changes
> 
> After looking at the Jira issue -
> https://issues.apache.org/jira/browse/SOLR-14853 - I tried setting
> SOLR_ENABLE_REMOTE_STREAMING=true and SOLR_ENABLE_STREAM_BODY=true in
> solr.in.sh to enable remote streaming and stream body, as indicated by
> the changes to bin/solr in the accompanying pull request:
> 
> · 
> https://github.com/apache/solr/pull/1615/files#diff-49c29c8f653341f48008c38f5f2cf970fa430cdca29181c819d7bdcfcc722980R1853-R1860
> 
> But it didn't make a difference, I still got the error "Stream Body is
> disabled. See 
> http://lucene.apache.org/solr/guide/requestdispatcher-in-solrconfig.html
> for help".
> 
> The reason seems to be that the bin/solr script in the binary package
> solr-8.11.3.tgz doesn't have these changes indicated in the pull
> request:
> 
>$ wget 
> https://www.apache.org/dyn/closer.lua/lucene/solr/8.11.3/solr-8.11.3.tgz?action=download
>   [...]
>$ mv -i solr-8.11.3.tgz\?action\=download solr-8.11.3.tgz
>$ tar xf solr-8.11.3.tgz 
>$ grep STREAM solr-8.11.3/bin/solr
>$ 
> 
> Adding the changes into the bin/solr script myself works, but I am
> wondering if I am using the wrong package or if those changes were
> supposed to be there?
> 
> 
>  Best regards,
> 
>Adam
> 
> -- 
> "Some people like cupcakes better. Adam Sjøgren
>  I for one care less for them!"   a...@koldfront.dk
> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Re: [DISCUSS] Solr 9.6 release

[Jan Høydahl]

In preparation for 9.6, let's upgrade as many of the dependencies that we can. 
I merged and back-ported a bunch today, here are the remaining:

https://github.com/apache/solr/pulls/solrbot

Some of them need some manual editing of licenses etc, so let's distribute this 
among several committers.

Jan

> 8. apr. 2024 kl. 23:09 skrev Jan Høydahl :
> 
> +1 
> 
> Jan Høydahl
> 
>> 8. apr. 2024 kl. 18:55 skrev Gus Heck :
>> 
>> It's been about 3 months since we started our last release discussion, and 
>> Jira
>> shows
>> <https://issues.apache.org/jira/browse/SOLR-17126?jql=project%20%3D%20SOLR%20AND%20fixVersion%20%3D%209.6.0%20ORDER%20BY%20issuetype%20ASC%2C%20status%20DESC>
>> that we have:
>> 
>> 5 bug fixes
>> 1 feature (query time distributed stats disable)
>> 11 improvements
>> 7 sub tasks, several of which represent new features including CPU limited
>> requests
>> 3 tasks, including the upgrade to Lucene 9.10
>> 
>> Only two are not resolved, but one seems to have commits and the other had
>> a PR ready in late Feb...
>> 
>> It seems like there are quite a few things now that should be made more
>> widely available to users.
>> 
>> I'm happy to volunteer as RM, though it will be my first time so I may have
>> questions. I propose that we cut the branch Next Monday April 15 and
>> prepare the first RC.
>> 
>> - Gus
>> 
>> --
>> http://www.needhamsoftware.com (work)
>> https://a.co/d/b2sZLD9 (my fantasy fiction book)

Re: [DISCUSS] Solr 9.6 release

[Jan Høydahl]

+1 

Jan Høydahl

> 8. apr. 2024 kl. 18:55 skrev Gus Heck :
> 
> It's been about 3 months since we started our last release discussion, and 
> Jira
> shows
> <https://issues.apache.org/jira/browse/SOLR-17126?jql=project%20%3D%20SOLR%20AND%20fixVersion%20%3D%209.6.0%20ORDER%20BY%20issuetype%20ASC%2C%20status%20DESC>
> that we have:
> 
> 5 bug fixes
> 1 feature (query time distributed stats disable)
> 11 improvements
> 7 sub tasks, several of which represent new features including CPU limited
> requests
> 3 tasks, including the upgrade to Lucene 9.10
> 
> Only two are not resolved, but one seems to have commits and the other had
> a PR ready in late Feb...
> 
> It seems like there are quite a few things now that should be made more
> widely available to users.
> 
> I'm happy to volunteer as RM, though it will be my first time so I may have
> questions. I propose that we cut the branch Next Monday April 15 and
> prepare the first RC.
> 
> - Gus
> 
> --
> http://www.needhamsoftware.com (work)
> https://a.co/d/b2sZLD9 (my fantasy fiction book)

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

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[Jan Høydahl]

I too refer to it as "standalone".
"User-managed" was mainly invented to have a name for distributed "standalon", 
in which case standalone could be confused with "singlenode"?

Thanks David for the other list reference. Useful context for sure.

Jan

> 26. feb. 2024 kl. 19:05 skrev Eric Pugh :
> 
> Can you re-share that link to the thread "SolrCloud Alone: Deprecate 
> Standalone Mode”. I took a look and didn’t find it.
> 
> We could change to standalone ;-).  We have a nice glossary in our ref guide 
> https://solr.apache.org/guide/solr/latest/getting-started/solr-glossary.html 
> that doesn’t actually include “Standalone” or “User Managed”.
> 
> 
> 
>> On Feb 26, 2024, at 3:59 PM, David Smiley  wrote:
>> 
>> Also reference a bigger discussion of August that same year:
>> "SolrCloud Alone: Deprecate Standalone Mode"
>> https://lists.apache.org/list.html?dev@solr.apache.org
>> 
>> (reading past conversations on a topic should be required reading when
>> introducing again)
>> 
>> RE "user-managed" I recall Cassandra was working on the ref guide and
>> tried to get us to harmonize on some terminology.  Ultimately "user
>> managed" was chosen and thus this term is widespread in the ref guide
>> despite "standalone" clearly being used for many years.  Personally, I
>> *much* prefer "standalone" and continue to use it (sorry?).
>> 
>> On Fri, Feb 23, 2024 at 7:14 PM Jan Høydahl  wrote:
>>> 
>>> Cross referencing earlier discussion "[DISCUSS] Make Cloud mode the default 
>>> option in bin/solr" from May 2021:
>>> https://lists.apache.org/thread/79xp2xfvqwhr9zccmsvjvj0hckgg5m6w
>>> 
>>> Some valid arguments for an against in that thread.
>>> 
>>> Ideally I'd prefer SIP-14 to be done before embedded zk is promoted as the 
>>> best way to run Solr.
>>> 
>>> Jan
>>> 
>>>> 23. feb. 2024 kl. 19:06 skrev Eric Pugh :
>>>> 
>>>> During today’s community discussion the topic of moving to defaulting to 
>>>> SolrCloud mode came up.
>>>> 
>>>> The idea here is that when a user run’s “bin/solr start” it fires up an 
>>>> embedded zookeeper.   Same behavior as “bin/solr -c” in Solr 9.5.If 
>>>> you have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would 
>>>> connect to the external ensemble instead.
>>>> 
>>>> If you want to continue to use the class user managed mode, then bin/solr 
>>>> start —user-managed maybe?   Or bin/solr start —standalone ???
>>>> 
>>>> Other changes would be to go through the Ref Guide and where we have both 
>>>> SolrCloud and non SolrCloud content that we make sure SolrCloud content is 
>>>> at the top instead of at the bottom.
>>>> 
>>>> To me, this feels like a change that would go on main.
>>>> 
>>>> Thoughts?
>>>> 
>>>> Eric
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> ___
>>>> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
>>>> http://www.opensourceconnections.com 
>>>> <http://www.opensourceconnections.com/> | My Free/Busy 
>>>> <http://tinyurl.com/eric-cal>
>>>> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
>>>> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>>>> This e-mail and all contents, including attachments, is considered to be 
>>>> Company Confidential unless explicitly stated otherwise, regardless of 
>>>> whether attachments are marked as such.
>>>> 
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com <http://www.opensourceconnections.com/> 
> | My Free/Busy <http://tinyurl.com/eric-cal>  
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> <https://www.packtpub.com/big-data-and-business-intelligence/apache-solr-enterprise-search-server-third-edition-raw>
>   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 


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

Re: Moving to bin/solr start defaulting to SolrCloud mode?

[Jan Høydahl]

Cross referencing earlier discussion "[DISCUSS] Make Cloud mode the default 
option in bin/solr" from May 2021:
 https://lists.apache.org/thread/79xp2xfvqwhr9zccmsvjvj0hckgg5m6w

Some valid arguments for an against in that thread.

Ideally I'd prefer SIP-14 to be done before embedded zk is promoted as the best 
way to run Solr.

Jan

> 23. feb. 2024 kl. 19:06 skrev Eric Pugh :
> 
> During today’s community discussion the topic of moving to defaulting to 
> SolrCloud mode came up.   
> 
> The idea here is that when a user run’s “bin/solr start” it fires up an 
> embedded zookeeper.   Same behavior as “bin/solr -c” in Solr 9.5.If you 
> have a Zookeeper Ensemble then “bin/solr start -z YOUR_ZK_SETUP” would 
> connect to the external ensemble instead.
> 
> If you want to continue to use the class user managed mode, then bin/solr 
> start —user-managed maybe?   Or bin/solr start —standalone ???
> 
> Other changes would be to go through the Ref Guide and where we have both 
> SolrCloud and non SolrCloud content that we make sure SolrCloud content is at 
> the top instead of at the bottom.   
> 
> To me, this feels like a change that would go on main. 
> 
> Thoughts?
> 
> Eric
> 
> 
> 
> 
> 
> 
> 
> 
> ___
> Eric Pugh | Founder & CEO | OpenSource Connections, LLC | 434.466.1467 | 
> http://www.opensourceconnections.com  
> | My Free/Busy   
> Co-Author: Apache Solr Enterprise Search Server, 3rd Ed 
> 
>   
> This e-mail and all contents, including attachments, is considered to be 
> Company Confidential unless explicitly stated otherwise, regardless of 
> whether attachments are marked as such.
> 

Re: Tracking contributors uniquely

[Jan Høydahl]

We should encourage committers to include Author and Co-Authored-By tags in 
commit message even for patches in Jira. This way contributors are credited in 
git log history too. And it gives us a way to get rid of CHANGES.txt some 
beautiful day ☀️

Jan Høydahl

> 13. feb. 2024 kl. 09:21 skrev Ishan Chattopadhyaya 
> :
> 
> Looking up CHANGES.txt is inevitable. Sometimes reporting a bug in JIRA is
> also a valid contribution. That gets tracked in CHANGES.txt.
> 
>> On Tue, 13 Feb 2024 at 12:41, David Smiley  wrote:
>> 
>> I'm working on a script to track contributors so that (A) we can track
>> project health for ASF board report purposes and (B) we can possibly
>> share a nice "Thank you" listing contributors in release
>> announcements.  Other purposes might crop up.  GitHub's contributors
>> report has serious shortcomings[1] so I'm not using that.
>> 
>> So far I have something like this:
>>  git log main --since="3 months ago" --pretty="Author: %an <%ae>%n%B"
>> | awk -F': ' '/^(Author|Co-authored-by): / {print $2}'  | sort | uniq
>> -c
>> 
>> But needs deduplication because most people have multiple entries.
>> With the complexity of deduplication, I'd convert this to Python and
>> put in dev-tools/scripts and create a "contributors.txt" file
>> somewhere that contains a full name, primary email, and email aliases.
>> 
>> I'm sure it's debatable to go this route vs CHANGES.txt but the latter
>> is harder to parse and ... I dunno; I don't like that it's so custom
>> compared to a generic Git metadata approach.  But maybe the dedupe
>> wouldn't be necessary (just fix CHANGES.txt for dups), and wouldn't
>> include trivial edits (for better/worse).  CHANGES.txt would be more
>> accurate for version-specific contribution attribution (since
>> CHANGES.txt is organized this way but harder to do between arbitrary
>> commits/dates.
>> 
>> [1]
>> https://docs.github.com/en/repositories/viewing-activity-and-data-for-your-repository/viewing-a-projects-contributors#troubleshooting-contributors
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 

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

Re: Nightly Solr Ref Guide; search is out-of-date

[Jan Høydahl]

Have you done a force refresh in your browser? The search index is client side.

Jan Høydahl

> 12. feb. 2024 kl. 23:45 skrev David Smiley :
> 
> I went looking for the latest/nightly ref guide because I wanted to
> check out how something recently added but not yet released looks in
> the documentation.
> 
> https://nightlies.apache.org/solr/draft-guides/solr-reference-guide-nightly/solr/9_6/
> and I observe the UI references "9.6 beta" so seems right.  But I go
> to search for "clusterSingleton" and get a couple results but NOT the
> page "Configuring solr.xml" as I expected.  Clicking either takes me
> to that page in 9.4 (but I'm at 9.6), suggesting the JS search index
> feature here is for 9.4 and isn't the latest that I'm looking at
> (9.6).  Navigating manually (not search) reveals content in 9.6 that I
> expect.
> 
> Does anyone know more about what's going on here?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 

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

Re: [VOTE] Release Solr 9.5.0 RC3

[Jan Høydahl]

+1 (binding)

SUCCESS! [0:42:27.908762]

ALso built and started docker image.

Jan

> 7. feb. 2024 kl. 21:57 skrev Jason Gerlowski :
> 
> Please vote for release candidate 3 for Solr 9.5.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC3-rev-cdd27dd15c3a6574032e9b1b92b148ab4e383599
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC3-rev-cdd27dd15c3a6574032e9b1b92b148ab4e383599
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC3-rev-cdd27dd15c3a6574032e9b1b92b148ab4e383599/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.5.0-3 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.5.0-3-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-02-10 21:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1


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

Re: [VOTE] Release Solr 9.5.0 RC2

[Jan Høydahl]

Actually, credit to Shawn for discovring the bug 
<https://the-asf.slack.com/archives/CEKUCUNE9/p1707259049474289> and to Houston 
for fixing it.

:)

> 7. feb. 2024 kl. 00:50 skrev Jan Høydahl :
> 
> Thanks for catching this before the release Houston! Your PR and bats test 
> looks solid. Let's re-spin..
> 
> Jan
> 
>> 7. feb. 2024 kl. 00:15 skrev Houston Putman :
>> 
>> Sorry everyone, I have to -1 this. Unfortunately certain solr.in.sh
>> functionality has broken due to a bug introduced while trying to improve
>> the envVar handling.
>> 
>> More details provided here: https://github.com/apache/solr/pull/2250 (
>> SOLR-15960 <https://issues.apache.org/jira/browse/SOLR-15960>)
>> 
>> - Houston
>> 
>> On Tue, Feb 6, 2024 at 4:02 PM Kevin Risden  wrote:
>> 
>>> +1 (binding)
>>> 
>>> SUCCESS! [0:33:17.981563]
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Tue, Feb 6, 2024 at 3:35 PM Arrieta, Alejandro <
>>> aarri...@perrinsoftware.com> wrote:
>>> 
>>>> Hello Team,
>>>> 
>>>> SUCCESS! [0:44:46.772429]
>>>> 
>>>> docker full and slim created fine.
>>>> 
>>>> +1 non binding
>>>> 
>>>> Kind Regards,
>>>> Alejandro Arrieta
>>>> 
>>>> 
>>>> On Tue, Feb 6, 2024 at 1:37 PM Houston Putman 
>>> wrote:
>>>> 
>>>>> +1 (binding)
>>>>> 
>>>>> SUCCESS! [0:32:51.658820]
>>>>> 
>>>>> I also built both Docker images and ran the Solr Operator integration
>>>> tests
>>>>> with the full image:
>>>>> 
>>>>> •••
>>>>> 
>>>>> Ran 23 of 23 Specs in 450.649 seconds
>>>>> SUCCESS! -- 23 Passed | 0 Failed | 0 Pending | 0 Skipped
>>>>> 
>>>>> - Houston
>>>>> 
>>>>> On Tue, Feb 6, 2024 at 11:43 AM Jason Gerlowski >>> 
>>>>> wrote:
>>>>> 
>>>>>> Please vote for release candidate 2 for Solr 9.5.0
>>>>>> 
>>>>>> The artifacts can be downloaded from:
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b
>>>>>> 
>>>>>> You can run the smoke tester directly with this command:
>>>>>> 
>>>>>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b
>>>>>> 
>>>>>> You can build a release-candidate of the official docker images
>>> (full &
>>>>>> slim) using the following command:
>>>>>> 
>>>>>> SOLR_DOWNLOAD_SERVER=
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b/solr
>>>>>> &&
>>>>>> <
>>>>> 
>>>> 
>>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b/solr&&;
>>>>>> 
>>>>>> \
>>>>>> docker build
>>>>> $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-full
>>>>>> \
>>>>>>   --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>>>>>   -t solr-rc:9.5.0-2 && \
>>>>>> docker build
>>>>> $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-slim
>>>>>> \
>>>>>>   --build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>>>>>   -t solr-rc:9.5.0-2-slim
>>>>>> 
>>>>>> The vote will be open for at least 72 hours i.e. until 2024-02-09
>>> 18:00
>>>>>> UTC.
>>>>>> 
>>>>>> [ ] +1  approve
>>>>>> [ ] +0  no opinion
>>>>>> [ ] -1  disapprove (and reason why)
>>>>>> 
>>>>>> Here is my +1 (binding)
>>>>>> 
>>>>> 
>>>> 
>>> 
> 

Re: [VOTE] Release Solr 9.5.0 RC2

[Jan Høydahl]

Thanks for catching this before the release Houston! Your PR and bats test 
looks solid. Let's re-spin..

Jan

> 7. feb. 2024 kl. 00:15 skrev Houston Putman :
> 
> Sorry everyone, I have to -1 this. Unfortunately certain solr.in.sh
> functionality has broken due to a bug introduced while trying to improve
> the envVar handling.
> 
> More details provided here: https://github.com/apache/solr/pull/2250 (
> SOLR-15960 )
> 
> - Houston
> 
> On Tue, Feb 6, 2024 at 4:02 PM Kevin Risden  wrote:
> 
>> +1 (binding)
>> 
>> SUCCESS! [0:33:17.981563]
>> 
>> Kevin Risden
>> 
>> 
>> On Tue, Feb 6, 2024 at 3:35 PM Arrieta, Alejandro <
>> aarri...@perrinsoftware.com> wrote:
>> 
>>> Hello Team,
>>> 
>>> SUCCESS! [0:44:46.772429]
>>> 
>>> docker full and slim created fine.
>>> 
>>> +1 non binding
>>> 
>>> Kind Regards,
>>> Alejandro Arrieta
>>> 
>>> 
>>> On Tue, Feb 6, 2024 at 1:37 PM Houston Putman 
>> wrote:
>>> 
 +1 (binding)
 
 SUCCESS! [0:32:51.658820]
 
 I also built both Docker images and ran the Solr Operator integration
>>> tests
 with the full image:
 
 •••
 
 Ran 23 of 23 Specs in 450.649 seconds
 SUCCESS! -- 23 Passed | 0 Failed | 0 Pending | 0 Skipped
 
 - Houston
 
 On Tue, Feb 6, 2024 at 11:43 AM Jason Gerlowski >> 
 wrote:
 
> Please vote for release candidate 2 for Solr 9.5.0
> 
> The artifacts can be downloaded from:
> 
> 
 
>>> 
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> 
> 
 
>>> 
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b
> 
> You can build a release-candidate of the official docker images
>> (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> 
> 
 
>>> 
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b/solr
> &&
> <
 
>>> 
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.5.0-RC2-rev-b03df01e89e64bc897a6be93de00af9ded2ee99b/solr&&;
> 
> \
>  docker build
 $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-full
> \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.5.0-2 && \
>  docker build
 $SOLR_DOWNLOAD_SERVER/9.5.0/docker/Dockerfile.official-slim
> \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.5.0-2-slim
> 
> The vote will be open for at least 72 hours i.e. until 2024-02-09
>> 18:00
> UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (binding)
> 
 
>>> 
>> 


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

Re: Regarding Solr issue(HTTP 502; : Bad Gateway Curl error)

[Jan Høydahl]

Hi,

This sounds like a question for the Drupal community. I see nothing we can help 
with here.

Good luck with debugging.

PS: If you in the future have direct questions aboout Apache Solr, such as if 
you identify error messages in Solr's server log, please use the 
us...@solr.apache.org <mailto:us...@solr.apache.org> mailing list instead of 
this developers list.


Jan Høydahl

> 31. jan. 2024 kl. 11:24 skrev Lokulwar, Amit Kamalakar (external - Project) 
> :
> 
> Hello Team,
> 
> I am working on one of big project. There I am using Apache Solr with Drupal 
> CMS. So far that project we used Solr Indexer and Solr Attachment and Solr 
> Search as well.
> Below are thing that we used in our Project:
> Solr: 7.7.3
> JDK: 17
> Drupal: 7
> PHP: 7.4.30
> 
> So When we upgrade JDK to 17 then we are getting "HTTP 502; : Bad Gateway 
> Curl error". So We tried to resolve this issue done below changes and 
> increase timeout.
> 1.Increase the PHP execution time, when we see in the networking tab it is 
> taking a long time to receive the response.
> /ariba/community/main_jdk17/config/php.ini.cfg
> 2.apache config added below lines:
> Timeout 2400  ProxyTimeout 2400 ProxyBadHeader Igonore
> //ariba/community/main_jdk17/config/httpd.conf.cfg
> 
> 
> 3. I had changed below file to increase Max Indexing time.
>  $max_indexing_time = variable_get('ariba_search_index_max_time_seconds', 
> 12600);
> File path: 
> /drupal/sites/all/modules/ariba/ariba_search/drush/ariba_search.drush.inc
> 
> But Still above issue is present. So please let us know what we need to do 
> for resolve this issue.
> 
> I am waiting for your reply. Let me know if you need any more details.
> 
> Regards,
> Amit Lokulwar
> (+91-9028291825)
> 

Re: PR labeling

[Jan Høydahl]

The StaleBot is now active, running once a day at midnight.
I started in a conservative way, only labeling 10 PRs a day, and setting the 
threshold at 60 days.
This gives us some time to evaluate without labeling the entire backlog.
Will be interesting to see whether the Bot results in some fogotten PRs being 
completed.

Jan

> 8. jan. 2024 kl. 23:10 skrev Jan Høydahl :
> 
> Hi,
> 
> Got some initial (positive) feedback on the auto-categorization PR and plan 
> to merge on Thursday, giving you some more time to review. I feel I have not 
> 100% nailed perfect labels. Obviously we can't auto label things like 
> feature/bug, or versions, so this is only a "category". Ideally there would 
> be a a 1:1 between these "category" labels and the "Components" defined in 
> JIRA. But here are 96 different "Components" there, most of them are 
> old/irrelevant and not always very good IMO. So I'd rather attempt to align 
> JIRA components with whatever we come up with here...
> 
> Lucene has just put their StaleBot to work, and I created 
> https://github.com/apache/solr/pull/2184 to do the same for Solr. Have a look.
> 
> Jan
> 
>> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
>> 
>> Hi,
>> 
>> We tend to not use the GitHub's PR labels we have defined.
>> So I whipped up https://github.com/apache/solr/pull/2180 which is configured 
>> to auto-label PRs based on what files are changed. Feedback welcome.
>> 
>> Also, I hope we can implement StaleBot for labeling PRs as stale. Lucene is 
>> going to test it, see https://github.com/apache/lucene/pull/12813. If that 
>> goes well, let's copy their config :)
>> 
>> - Jan
>> 
>> 
> 


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

Re: [DISCUSS] SIP-21 Standardizing sysprop naming

[Jan Høydahl]

This effort was discussed in today's Community meeting and is now SIP-21
https://cwiki.apache.org/confluence/display/SOLR/SIP-21%3A+Standardize+system+property+naming

Please have a look and help out carving out what categories to place properties 
in to drive the effort closer to implementation, which will be a series of PRs 
renaming groups of properties).

Jan

> 16. jan. 2024 kl. 10:52 skrev Jan Høydahl :
> 
>>> collection.configName
>> Where is this used as a system property override?  I looked and don't see
>> it.
> 
> Yea, this should not have been in the list. Removed
> 
>> "enabled" vs "disabled": can we standardize on "enabled"?
> 
> That would have been nice. I think typically .enabled is used when default is 
> disabled and .disabled is used when default is enabled.
> 
>>> managed.schema.mutable
>> 
>> In this case (and likely others if I found one), there is no production
>> code containing this string.  It is only a test config file containing
>> ${managed.schema.mutable} and probably test code that sets it.  I don't
>> think we should put these in the list; the list is long enough as it is.
> 
> Yep, I moved that line down to the "Test code" section of the table.
> I should have filtered my regex scan on non-test code..
> 
>>> disable.configEdit. => solr.configset.edit.disabled
>> We should then broaden its use to cover the configset broadly, thus block
>> the schema edit API and maybe more.  Right now it only covers mutability of
>> solrconfig.xml (via a JSON overlay).  I'm good with that, but it increases
>> the scope.
> 
> Yes, self descriptive naming is a goal. Rather change the names in this 
> effort than change the functionality.
> 
> Jan

Re: [DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

>> collection.configName
> Where is this used as a system property override?  I looked and don't see
> it.

Yea, this should not have been in the list. Removed

> "enabled" vs "disabled": can we standardize on "enabled"?

That would have been nice. I think typically .enabled is used when default is 
disabled and .disabled is used when default is enabled.

>> managed.schema.mutable
> 
> In this case (and likely others if I found one), there is no production
> code containing this string.  It is only a test config file containing
> ${managed.schema.mutable} and probably test code that sets it.  I don't
> think we should put these in the list; the list is long enough as it is.

Yep, I moved that line down to the "Test code" section of the table.
I should have filtered my regex scan on non-test code..

>> disable.configEdit. => solr.configset.edit.disabled
> We should then broaden its use to cover the configset broadly, thus block
> the schema edit API and maybe more.  Right now it only covers mutability of
> solrconfig.xml (via a JSON overlay).  I'm good with that, but it increases
> the scope.

Yes, self descriptive naming is a goal. Rather change the names in this effort 
than change the functionality.

Jan

Re: [VOTE] Release Solr 9.4.1 RC1

[Jan Høydahl]

+1 (binding)

SUCCESS! [0:42:51.792486]

Also built docker container and spun up the server locally.


PS: Need to remove extra newline between the two lines of command when 
copy/pasting:

python3 -u dev-tools/scripts/smokeTestRelease.py \
https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476

Jan

> 13. jan. 2024 kl. 17:14 skrev David Smiley :
> 
> Please vote for release candidate 1 for Solr 9.4.1
> 
> The artifacts can be downloaded from:
> 
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> 
> 
> You can run the smoke tester directly with this command:
> 
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> 
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476
> 
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.1-RC1-rev-57762a5b52a9d40a6f15441c4adeb76f0b045476/solr
> && \
> 
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-full \
> 
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> 
>-t solr-rc:9.4.1-1 && \
> 
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.1/docker/Dockerfile.official-slim \
> 
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
> 
>-t solr-rc:9.4.1-1-slim
> 
> 
> The vote will be open for at least 72 hours i.e. until 2024-01-16 17:00 UTC.
> 
> 
> [ ] +1  approve
> 
> [ ] +0  no opinion
> 
> [ ] -1  disapprove (and reason why)
> 
> 
> Here is my +1
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley


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

Re: [DISCUSS] Solr 9.5 Release

[Jan Høydahl]

+1 — but let 9.4.1 get out the door first..

Jan Høydahl

> 12. jan. 2024 kl. 21:56 skrev Jason Gerlowski :
> 
> Hey all,
> 
> branch_9x has accumulated 3 new features, 19 improvements, 2 optimizations,
> 11 bug fixes, and 7 "other changes" - I'd love to get these in front of
> users with a Solr 9.5.0 release.
> 
> I'm happy to volunteer as RM, and propose that we target next Thursday
> January 18th to cut the branch and prepare the first RC.
> 
> Best,
> 
> Jason

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

Re: [DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

I like the simplicity of lowercasing and changing underscore for dot, so if we 
can avoid camelCase that would be best.


I started a WIKI page for easier collaboration on this topic: 
https://cwiki.apache.org/confluence/display/SOLR/System+property+naming+structure

There I enumerated each source folder and tried to deduce some commonality and 
structure.

I also enumerated all current sysProps used in the codebase (by scanning src 
for various System.getProperty, Boolean.getBoolean, EnvUtils.getProp 
variations). That is the second table on the page. Looking at all those system 
property names we have today is depressing, they are all over the place and 157 
in number (although some are zk, hadoop or java owned and some relate to tests).

I did a small stab on mapping those old props to a new proposed name, but the 
list is looong, so good with some collaboration on this. I experience that the 
shape of the hiearchy molds as I encounter more real-life examples. And there 
are tons of decisions, e.g. wether we should force solr.security as a prefix 
for all things security or to keep the shorter solr.auth.*. Same with 
solr.search.*

It is also encouraging to see the list of existing solr.xxx keys in use that 
are already well structured (solr.jetty.keystore.password, 
solr.kerberos.keystore.password, solr.log.level etc).

Jan


> 11. jan. 2024 kl. 03:36 skrev David Smiley :
> 
> On Tue, Jan 9, 2024 at 9:49 AM Jan Høydahl  <mailto:jan@cominvent.com>> wrote:
> 
>> Hi,
>> 
>>> Using this one as an example; what would you propose?:
>>> * solr.shardSplit.checkDiskSpace.enabled
>> 
>> The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better.
>> But say we standardized the first component layer to be one of "query",
>> "index", "collection", "schema", "cluster", "node" or whatever set of
>> top-level components make sense. Then I guess shard split would be
>> "solr.collection.shard.split.checkDiskSpace.enabled" or similar. However, I
>> find it hard to find good generic top-level categories for Solr that are
>> consise and no overlapping.
>> 
> 
> So the module can't be camel-case but checkDiskSpace can?  What about
> hyphens in a sys prop, mapped to an underscore in an env var?
> 
>> "solr.collection.shard.split.checkDiskSpace.enabled"
> 
> Not bad.
> I bet it's hard to find good generic top-level categories.Feel free to
> take a stab at this and share for review.  It doesn't need to be perfect,
> just not nausea inducing :-)
> 
> 
>>> Are you saying the camel case is a problem?
>> 
>> No necessarily. The concern was that there should be a well-defined way to
>> translate an SOLR_ENV_VAR into system property, so we don't need to touch
>> bin/solr[.cmd] every single time. And it would be hard for an algorithm to
>> know that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED
>> env.var into the exact combination of dot separation and camelCase used
>> above. An alternative could be using a combination of underscore and dash,
>> such as "SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate
>> underscore with dot and dash with Camelcase. We'd need to disallow dash in
>> property names then...
>> 
> 
> Alternatively simply normalize both sys props and env vars using the same
> scheme.  In theory it would allow crazy variation but if we only document
> each named toggle a certain way then it doesn't matter.

All official Git branches are now protected

[Jan Høydahl]

Hi devs,

For your information, we just protected branches main, branch_9x and branch_9_N 
to disallow deletion or force-push.
Also, all releases/* tags are now protected.

A nice feature also added is that referenciing SOLR-NNN in PR comments will now 
add a clickable link to JIRA.

All this was enabled by an update to .asf.yaml, see commit 
https://github.com/apache/solr/commit/0b1d6649e09220f81806fd3e4b254f629df960e7

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

Re: [DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

Hi,

> Using this one as an example; what would you propose?:
> * solr.shardSplit.checkDiskSpace.enabled

The "solr.shardSplit.checkDiskSpace.enabled" prop is one of the better. But say 
we standardized the first component layer to be one of "query", "index", 
"collection", "schema", "cluster", "node" or whatever set of top-level 
components make sense. Then I guess shard split would be 
"solr.collection.shard.split.checkDiskSpace.enabled" or similar. However, I 
find it hard to find good generic top-level categories for Solr that are 
consise and no overlapping.

> On a related note, I've been thinking it'd be wonderful if Solr
> automatically had sys-prop/env-var overrides for any configuration element
> without requiring a dollar-curley-bracket use.


That would be wonderful, and would likely require similar centralization and 
standardization.

> Are you saying the camel case is a problem?

No necessarily. The concern was that there should be a well-defined way to 
translate an SOLR_ENV_VAR into system property, so we don't need to touch 
bin/solr[.cmd] every single time. And it would be hard for an algorithm to know 
that it should translate SOLR_SHARD_SPLIT_CHECK_DISK_SPACE_ENABLED env.var into 
the exact combination of dot separation and camelCase used above. An 
alternative could be using a combination of underscore and dash, such as 
"SOLR_SHARD-SPLIT_CHECK-DISK-SPACE_ENABLED", where we translate underscore with 
dot and dash with Camelcase. We'd need to disallow dash in property names 
then...

Jan

> 7. jan. 2024 kl. 17:49 skrev David Smiley :
> 
> Thanks for working on this and raising the topic of config naming
> standardization!
> 
> Using this one as an example; what would you propose?:
> * solr.shardSplit.checkDiskSpace.enabled
> 
> Thankfully, it already uses two best practices (A) starting with "solr."
> and (B) a module/category "shardSplit".  What follows is
> "checkDiskSpace.enabled.  I dislike ".enabled" in general but not a big
> deal.  Are you saying the camel case is a problem?  Is it a problem in the
> module part "shardSplit"?  The current structure is clear (separation of
> the module/category from the individual toggle name); disallowing camel
> case in a system property and converting to periods would look worse, but
> alas, I guess we can't have everything.
> 
> On a related note, I've been thinking it'd be wonderful if Solr
> automatically had sys-prop/env-var overrides for any configuration element
> without requiring a dollar-curley-bracket use.  This would result in
> standardization and more easily allow near empty configurations by default;
> something we don't quite have.  An example:
> in solrconfig.xml,  parent element, we have this today:
> 
> class="${solr.directoryFactory:solr.NRTCachingDirectoryFactory}"/>
> Imagine instead not specifying this at all.  The default logic would
> instead read the class from the sys prop: "solr.config.directoryFactory".
> The "config" part is because that's the root element of this file.
> 
> Here's another example:
> 
>   
> ${solr.commitwithin.softcommit:true}
>   
> 
> 
> Again, imagine not specifying this at all.  Instead, the default would be
> read from "solr.config.updateHandler.commitWithin.softCommit".
> 
> 
> On Fri, Jan 5, 2024 at 11:15 AM Jan Høydahl  wrote:
> 
>> Hi,
>> 
>> Happy New Year to all!
>> 
>> Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of
>> system properties and environment variables is now merged!
>> It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr
>> Java process and maps them to sys.prop without need for explicit maping in
>> bin/solr[.cmd].
>> 
>> Please take it for a spin, and if you find simplifications that can be
>> done in bin/solr[.cmd] scripts or docs, feel free to grab those.
>> 
>> 
>> I'm planning a followup related to sysprop naming convention in
>> https://issues.apache.org/jira/browse/SOLR-17111
>> Proposing a strict solr.foo.bar naming, aligning with env name
>> SOLR_FOO_BAR instead of our current solr.fooBar camelCase props.
>> The plan is to support both old and new keys in in 9.x (e.g. both
>> "disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
>> Q: Wil this be such a big change that both variants should work throughout
>> the 10.x series as well?
>> 
>> 
>> Next, I'd love to consider semantic property names. Now we have a mix of
>> randomly chosen property name

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Jan Høydahl]

Bringing attention to this thread again.

Now that Lucene has some experience after the migration and with using Issues, 
labels etc, I'd like to discuss whether we'd want to copy the Lucene approach 
or do something different.

I'm not frequenting the Lucene issue tracker much, and am not either aware of a 
formal evaluation of their issue migration. So appreciate feedback from 
committers who have more exposure from Lucene.

In my mind, we, Solr, have four options
A) Migrate everything, like Lucene did
B) Migrate only OPEN JIRA issues, refer to JIRA for ancient history
C) Fresh-start empty GH issues, use JIRA as archive before -mm-dd
D) Continue with g'old JIRA

I was getting used to the thought of copying Lucene's approach, but re-thinking 
now, I have once again shifted my preference towards C), a fresh start. I'll 
summarize my reasons below with some numbers and experience from Lucene's GH 
issues. Forgive my last rant on this subject :)


I'm a fan of NOT migrating the entire JIRA history to GH. Instead let the R/O 
SOLR-JIRA be the system of record for historic issues forever. I.e. start a 
fresh, empty GH issue tracker for all NEW issues. The main con, two systems of 
record, can imo be mitigated with SearchEngineTechnoloty™. Nothing is lost and 
the duplication of 16k issues in two systems is more confusing imo. We could 
time-box the overlap period where both systems are writable to, say 3 months, 
and at the end of that period, CLOSE all still-open JIRA issues with a label 
and a suitable message.

My arguments for this approach: 1) Solr has 16993 JIRA issues! 2) There are 
4030 OPEN issues, of which 3681 has not been touched for a year! Why would we 
want 3681 OPEN & stale GitHub issues? Instead I'd like to use StaleBot to tag 
stale issues+PRs and auto close+tag if still stale for N days. This is a 
much-used, proven approach. 3) The Lucene migration caused a whopping 642 
issue/PR labels <https://github.com/apache/lucene/issues/labels>, impossible to 
browse manually. Most labels are trying to record legacy JIRA fields. I checked 
e.g. the "affects-version" 
<https://github.com/apache/lucene/labels?q=affects-version:9>, label in Lucene. 
New labels have not been maintained for recent releases (8.11.2, 9.4..9), and 
those labels are ~NEVER even used when people create new GH issues, so why even 
bother? Same for Priority etc.


Let the discussion continue...

Jan


> 3. nov. 2023 kl. 12:33 skrev Jan Høydahl :
> 
> Bringing this to our attention again. Lucene seems to have survived well 
> after the migration to Github issues. They have established a way to work 
> with milestones (https://github.com/apache/lucene/milestones) and labels 
> (https://github.com/apache/lucene/labels?q=type), and they have updated 
> release-wizard with corresponding steps.
> 
> So are we ready to follow their lead?
> 
> Jan
> 
>> 18. okt. 2022 kl. 12:58 skrev Jan Høydahl :
>> 
>> +1 from me too.
>> 
>> I'm still not sold on bringing all history from JIRA into GH but that's what 
>> Lucene did, so perhaps just doing the same (+ lessons learnt) is the 
>> smoothest path.
>> Solr would in addition need to find a new process for security issues. But 
>> we could just fall back on plain security@solr mailing list until a new 
>> solution is ready.
>> 
>> Jan
>> 
>>> 17. okt. 2022 kl. 16:20 skrev David Smiley :
>>> 
>>> +1 to migrate.
>>> 
>>> Yeah.  Maybe Tomoko could validate the steps required?  (CC'ed)  Jeb listed
>>> them in JIRA; the steps/mechanics can be discussed there while we leave
>>> this thread as voting on the major decision.
>>> 
>>> ~ David Smiley
>>> Apache Lucene/Solr Search Developer
>>> http://www.linkedin.com/in/davidwsmiley
>>> 
>>> 
>>> On Mon, Oct 17, 2022 at 10:12 AM Houston Putman  wrote:
>>> 
>>>> I'm a big +1 on this idea, just like I was for Lucene's migration.
>>>> 
>>>> Also I think that we could very much mooch off of the monumental amounts of
>>>> hard work that Tomoko and Mike did for Lucene.
>>>> 
>>>> There would certainly still be manual work, and changes to their script
>>>> needed, but I don't think it would be as back-breaking of a task.
>>>> 
>>>> - Houston
>>>> 
>>>> On Fri, Oct 14, 2022 at 1:07 AM Noble Paul  wrote:
>>>> 
>>>>> I agree that JIRA is one extra step that is not adding a lot of value.
>>>>> Github issues are definitely better
>>>>> 
>>>>> On Fri, 

Re: PR labeling

[Jan Høydahl]

Hi,

Got some initial (positive) feedback on the auto-categorization PR and plan to 
merge on Thursday, giving you some more time to review. I feel I have not 100% 
nailed perfect labels. Obviously we can't auto label things like feature/bug, 
or versions, so this is only a "category". Ideally there would be a a 1:1 
between these "category" labels and the "Components" defined in JIRA. But here 
are 96 different "Components" there, most of them are old/irrelevant and not 
always very good IMO. So I'd rather attempt to align JIRA components with 
whatever we come up with here...

Lucene has just put their StaleBot to work, and I created 
https://github.com/apache/solr/pull/2184 to do the same for Solr. Have a look.

Jan

> 6. jan. 2024 kl. 01:21 skrev Jan Høydahl :
> 
> Hi,
> 
> We tend to not use the GitHub's PR labels we have defined.
> So I whipped up https://github.com/apache/solr/pull/2180 which is configured 
> to auto-label PRs based on what files are changed. Feedback welcome.
> 
> Also, I hope we can implement StaleBot for labeling PRs as stale. Lucene is 
> going to test it, see https://github.com/apache/lucene/pull/12813. If that 
> goes well, let's copy their config :)
> 
> - Jan
> 
> 


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

Re: Nifi error after Solrj Upgrade

[Jan Høydahl]

This is really a discussion for the users@ list, but you have to check all your 
transivite dependencies for conflicts.
Here is a helpful article: 
https://www.javaadvent.com/2020/12/how-to-debug-dependency-conflicts-in-maven-and-gradle.html

Jan

> 8. jan. 2024 kl. 18:08 skrev Subhasis Patra 
> :
> 
> Thank you for your response.
> We don’t have any issue when Solrj is part of other services. The issue is 
> specific to nifi. Is nifi using some different version of jetty that is 
> conflicting with the jetty Solrj is using?
> I don’t have any jetty in my pom, the jeety jars are getting pulled as part 
> of Solrj or nifi.
> 
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com<mailto:subhasis.pa...@e2open.com>
> 
> From: Jan Høydahl 
> Sent: Monday, January 8, 2024 8:41 AM
> To: dev@solr.apache.org
> Subject: Re: Nifi error after Solrj Upgrade
> 
> PHISH ALERT! CHECK VALIDITY IF CLICKING, SHARING, RESPONDING
> 
> Check the class path of your application, whether it already has a dependency 
> on Jetty. If so, you need to pick one version so you don’t get multiple 
> versions of jetty on the class path.
> 
> If you use maven you can run “mvn dependency:tree” or similar to see them all.
> 
> Jan Høydahl
> 
>> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
>> mailto:subhasis.pa...@e2open.com.invalid>>:
>> 
>> Hi Everyone,
>> 
>> Appreciate any help on following.
>> 
>> I am using nifi-1.23.2 and Solr version is 9.2.0.
>> In my nifi processor I have logic to create Solr client. It was working as 
>> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After 
>> that I started getting following error while creating Solr client in my nifi 
>> processor.
>> 
>> java.lang.IncompatibleClassChangeError: class 
>> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
>> org.eclipse.jetty.http.HttpFields, because it is not an interface 
>> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
>> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
>> at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>> at java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
>> at 
>> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>> at java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
>> at java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
>> at 
>> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>> at java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
>> at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>> at 
>> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(http://Http2SolrClient.java:1066<http://Http2SolrClient.java:1066>)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(http://CloudHttp2SolrClient.java:61<http://CloudHttp2SolrClient.java:61>)
>> at 
>> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
>> 
>> I am using following method to create solr Client.
>> 
>> CloudSolrClient.Builder(urlList, 
>> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
>> .withZkClientTimeout(6, TimeUnit.MILLISECONDS).build()
>> 
>> Thanks
>> Subhasis Patra
>> 240-755-2601
>> subhasis.pa...@e2open.com<mailto:subhasis.pa...@e2open.com<mailto:subhasis.pa...@e2open.com%3cmailto:subhasis.pa...@e2open.com>>
>> 
> 
> -
> To unsubscribe, e-mail: 
> dev-unsubscr...@solr.apache.org<mailto:dev-unsubscr...@solr.apache.org>
> For additional commands, e-mail: 
> dev-h...@solr.apache.org<mailto:dev-h...@solr.apache.org>


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

Re: Nifi error after Solrj Upgrade

[Jan Høydahl]

Check the class path of your application, whether it already has a dependency 
on Jetty. If so, you need to pick one version so you don’t get multiple 
versions of jetty on the class path.

If you use maven you can run “mvn dependency:tree” or similar to see them all.

Jan Høydahl

> 8. jan. 2024 kl. 01:14 skrev Subhasis Patra 
> :
> 
> Hi Everyone,
> 
> Appreciate any help on following.
> 
> I am using nifi-1.23.2 and Solr version is 9.2.0.
> In my nifi processor I have logic to create Solr client. It was working as 
> expected till Solrj8.11.2. Last week I upgraded my Solrj to 9.4.0. After that 
> I started getting following error while creating Solr client in my nifi 
> processor.
> 
> java.lang.IncompatibleClassChangeError: class 
> org.eclipse.jetty.http.HttpFields$Mutable can not implement 
> org.eclipse.jetty.http.HttpFields, because it is not an interface 
> (org.eclipse.jetty.http.HttpFields is in unnamed module of loader 
> org.apache.nifi.nar.NarClassLoader @4a8df3e2)
>at java.base/java.lang.ClassLoader.defineClass1(Native Method)
>at 
> java.base/java.lang.ClassLoader.defineClass(ClassLoader.java:1012)
>at 
> java.base/java.security.SecureClassLoader.defineClass(SecureClassLoader.java:150)
>at 
> java.base/java.net.URLClassLoader.defineClass(URLClassLoader.java:524)
>at 
> java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:427)
>at 
> java.base/java.net.URLClassLoader$1.run(URLClassLoader.java:421)
>at 
> java.base/java.security.AccessController.doPrivileged(AccessController.java:712)
>at 
> java.base/java.net.URLClassLoader.findClass(URLClassLoader.java:420)
>at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:587)
>at 
> java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:520)
>at 
> org.apache.solr.client.solrj.impl.Http2SolrClient$Builder.(Http2SolrClient.java:1066)
>at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient.(CloudHttp2SolrClient.java:61)
>at 
> org.apache.solr.client.solrj.impl.CloudHttp2SolrClient$Builder.build(CloudHttp2SolrClient.java:429)
> 
> I am using following method to create solr Client.
> 
> CloudSolrClient.Builder(urlList, 
> Optional.empty()).withZkConnectTimeout(1, TimeUnit.MILLISECONDS)
> .withZkClientTimeout(6, 
> TimeUnit.MILLISECONDS).build()
> 
> Thanks
> Subhasis Patra
> 240-755-2601
> subhasis.pa...@e2open.com<mailto:subhasis.pa...@e2open.com>
> 

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

Re: Solr 9.4.1

[Jan Høydahl]

Done

Jan

> 7. jan. 2024 kl. 07:03 skrev David Smiley :
> 
> Sure; thanks.
> 
>> On Fri, Jan 5, 2024 at 3:29 PM Jan Høydahl  wrote:
>> 
>> Should we include this bugfix?
>> https://issues.apache.org/jira/browse/SOLR-16203
>> I'm merging to branch_9x now...
>> 
>> Jan
>> 
>>>> 5. jan. 2024 kl. 17:14 skrev David Smiley :
>>> 
>>> 9.4.1 is unblocked; bug fixes are now on the release branch.  I plan to
>>> pursue a RC soon (today/tomorrow).  This is my first time.
>>> 
>>> On Fri, Dec 8, 2023 at 9:53 AM Jan Høydahl 
>> wrote:
>>> 
>>>> SolrBot had been failing for a long time (>1month), but I got it on
>> track
>>>> again. Normally it only files new PRs on Sundays, but I'm triggering
>> that
>>>> manually now to consider what other upgrades from the past month that we
>>>> should put into 9.4.1.
>>>> 
>>>> Please have a look at https://github.com/apache/solr/pulls/solrbot and
>>>> consider which ones should be merged and backported.
>>>> 
>>>> Jan
>>>> 
>>>>> 8. des. 2023 kl. 14:59 skrev David Smiley :
>>>>> 
>>>>> I renamed that job to add "(Crave)"
>>>>> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x%20(Crave)/
>> and
>>>>> disabled it.  I then I created a new job copied from the
>>>> "Solr-check-main"
>>>>> but branch_9x.  Builds are hourly so we'll see how it goes.
>>>>> 
>>>>> ~ David
>>>>> 
>>>>> 
>>>>> On Thu, Dec 7, 2023 at 10:08 AM Jan Høydahl 
>>>> wrote:
>>>>> 
>>>>>> PS: https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/ is also
>>>> not
>>>>>> running since 25 days as it was converted to Crave..
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 7. des. 2023 kl. 15:06 skrev David Smiley >> :
>>>>>>> 
>>>>>>> I've been working with Uv on these glitches.
>>>>>>> ~ David
>>>>>>> 
>>>>>>> 
>>>>>>> On Thu, Dec 7, 2023 at 2:47 AM Jan Høydahl 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> I backported ALL SolrBot PRs to branch_9_4, which brings the number
>> of
>>>>>>>> known CVEs down.
>>>>>>>> 
>>>>>>>> I also have a few other dependency upgrades baking in PRs but
>>>>>>>> unfortunately Crave has died so no PRs pass tests:
>>>>>>>> 
>>>>>>>>> Run cd
>>>>>>>> 
>>>>>> 
>>>> 
>> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
>>>>>>>>> Selecting project Solr (id:39)
>>>>>>>>> Error: Process completed with exit code 1.
>>>>>>>> 
>>>>>>>> Jan
>>>>>>>> 
>>>>>>>>> 7. des. 2023 kl. 02:44 skrev David Smiley <
>> david.w.smi...@gmail.com
>>>>> :
>>>>>>>>> 
>>>>>>>>> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will
>> happen
>>>>>> as
>>>>>>>>> there are a couple security matters we're looking at.
>>>>>>>>> ~ David
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh <
>>>>>>>> ep...@opensourceconnections.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Something that I’d like to get released ASAP is a fix to the
>>>> bin/solr
>>>>>>>> post
>>>>>>>>>> command.
>>>>>>>>>> 
>>>>>>>>>> Our Ref Guide has a lot of mentions of using “bin/solr post -c
>> tech
>>>>>>>>>> products”, however I removed the -c parameter in favour of -url
>>>>>>>> parameter.
>>>>>>>>>> I think that was a mistake, and would like to restore the old -c
>>>>>>>> parameter,
>>>>>>>>>> and then make sure t

PR labeling

[Jan Høydahl]

Hi,

We tend to not use the GitHub's PR labels we have defined.
So I whipped up https://github.com/apache/solr/pull/2180 which is configured to 
auto-label PRs based on what files are changed. Feedback welcome.

Also, I hope we can implement StaleBot for labeling PRs as stale. Lucene is 
going to test it, see https://github.com/apache/lucene/pull/12813. If that goes 
well, let's copy their config :)

- Jan



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

Re: Solr 9.4.1

[Jan Høydahl]

Should we include this bugfix? https://issues.apache.org/jira/browse/SOLR-16203
I'm merging to branch_9x now...

Jan

> 5. jan. 2024 kl. 17:14 skrev David Smiley :
> 
> 9.4.1 is unblocked; bug fixes are now on the release branch.  I plan to
> pursue a RC soon (today/tomorrow).  This is my first time.
> 
> On Fri, Dec 8, 2023 at 9:53 AM Jan Høydahl  wrote:
> 
>> SolrBot had been failing for a long time (>1month), but I got it on track
>> again. Normally it only files new PRs on Sundays, but I'm triggering that
>> manually now to consider what other upgrades from the past month that we
>> should put into 9.4.1.
>> 
>> Please have a look at https://github.com/apache/solr/pulls/solrbot and
>> consider which ones should be merged and backported.
>> 
>> Jan
>> 
>>> 8. des. 2023 kl. 14:59 skrev David Smiley :
>>> 
>>> I renamed that job to add "(Crave)"
>>> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x%20(Crave)/ and
>>> disabled it.  I then I created a new job copied from the
>> "Solr-check-main"
>>> but branch_9x.  Builds are hourly so we'll see how it goes.
>>> 
>>> ~ David
>>> 
>>> 
>>> On Thu, Dec 7, 2023 at 10:08 AM Jan Høydahl 
>> wrote:
>>> 
>>>> PS: https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/ is also
>> not
>>>> running since 25 days as it was converted to Crave..
>>>> 
>>>> Jan
>>>> 
>>>>> 7. des. 2023 kl. 15:06 skrev David Smiley :
>>>>> 
>>>>> I've been working with Uv on these glitches.
>>>>> ~ David
>>>>> 
>>>>> 
>>>>> On Thu, Dec 7, 2023 at 2:47 AM Jan Høydahl 
>>>> wrote:
>>>>> 
>>>>>> I backported ALL SolrBot PRs to branch_9_4, which brings the number of
>>>>>> known CVEs down.
>>>>>> 
>>>>>> I also have a few other dependency upgrades baking in PRs but
>>>>>> unfortunately Crave has died so no PRs pass tests:
>>>>>> 
>>>>>>> Run cd
>>>>>> 
>>>> 
>> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
>>>>>>> Selecting project Solr (id:39)
>>>>>>> Error: Process completed with exit code 1.
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 7. des. 2023 kl. 02:44 skrev David Smiley >> :
>>>>>>> 
>>>>>>> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will happen
>>>> as
>>>>>>> there are a couple security matters we're looking at.
>>>>>>> ~ David
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh <
>>>>>> ep...@opensourceconnections.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Something that I’d like to get released ASAP is a fix to the
>> bin/solr
>>>>>> post
>>>>>>>> command.
>>>>>>>> 
>>>>>>>> Our Ref Guide has a lot of mentions of using “bin/solr post -c tech
>>>>>>>> products”, however I removed the -c parameter in favour of -url
>>>>>> parameter.
>>>>>>>> I think that was a mistake, and would like to restore the old -c
>>>>>> parameter,
>>>>>>>> and then make sure the Ref Guide is up to date.
>>>>>>>> 
>>>>>>>> This could be a 9.4.1 or 9.5 change.
>>>>>>>> 
>>>>>>>>> On Dec 6, 2023, at 10:31 AM, Jason Gerlowski <
>> gerlowsk...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Good question - I'm still thinking through what makes the most
>> sense
>>>>>>>>> there.  Let's continue discussion on SOLR-17100 if you've got
>>>> thoughts!
>>>>>>>>> 
>>>>>>>>> On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Jason, what do you mean by "publishing" the clients?
>>>>>>>>>> I suppose you don't mean pip and npm, but in

[DISCUSS] Standardizing sysprop naming

[Jan Høydahl]

Hi,

Happy New Year to all!

Finally https://issues.apache.org/jira/browse/SOLR-15960 Unified use of system 
properties and environment variables is now merged!
It exports all SOLR_FOO and ZK_FOO env.vars to be available to the Solr Java 
process and maps them to sys.prop without need for explicit maping in 
bin/solr[.cmd].

Please take it for a spin, and if you find simplifications that can be done in 
bin/solr[.cmd] scripts or docs, feel free to grab those.


I'm planning a followup related to sysprop naming convention in 
https://issues.apache.org/jira/browse/SOLR-17111 
Proposing a strict solr.foo.bar naming, aligning with env name SOLR_FOO_BAR 
instead of our current solr.fooBar camelCase props.
The plan is to support both old and new keys in in 9.x (e.g. both 
"disableAdminUI" and "solr.admin.ui.disabled") and only new from 10.0.
Q: Wil this be such a big change that both variants should work throughout the 
10.x series as well?


Next, I'd love to consider semantic property names. Now we have a mix of 
randomly chosen property names. Some examples:
metricsEnabled 
solr.enableStreamBody 
enable.packages 
solr.clustering.enabled 
solr.shardSplit.checkDiskSpace.enabled 
solr.log.requestlog.enabled
I'd love for us to qualify these with module/submodule, so we get some semantic 
naming structure like

solr...=foo
E.g. enable.packages would then be solr.packages.enabled (instead of simply 
solr.enable.packages)

To do this across the entire set of solr properties is a much bigger change 
than SOLR-17111. So I propose to tackle only the non-standard ones first, and 
select new names case by case.

If you like the proposal of some standardized naming hierarchy across all 
properties, that is probably something that deserves a design document or a 
SIP..

-Jan

Re: (solr) branch main updated: SOLR-16949: Restrict certain file types from being uploaded to or downloaded from Config Sets

[Jan Høydahl]

Sorry 'bout that, I'm on it.

Jan

> 15. des. 2023 kl. 23:32 skrev Chris Hostetter :
> 
> 
> This change, and it's associated backports, seem to have broken 
> TestConfigSetService (regardless of seed?) due to leaked files.
> 
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/8576/consoleText
> https://jenkins.thetaphi.de/view/Solr/job/Solr-main-Windows/3706/consoleText
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/39/consoleText
> https://ci-builds.apache.org/job/Solr/job/Solr-check-9.4/1208/consoleText
> 
> 
> 
> : Date: Wed, 13 Dec 2023 22:08:04 +
> : From: jan...@apache.org
> : Reply-To: dev@solr.apache.org
> : To: "comm...@solr.apache.org" 
> : Subject: (solr) branch main updated: SOLR-16949: Restrict certain file types
> : from being uploaded to or downloaded from Config Sets
> : 
> : This is an automated email from the ASF dual-hosted git repository.
> : 
> : janhoy pushed a commit to branch main
> : in repository https://gitbox.apache.org/repos/asf/solr.git
> : 
> : 
> : The following commit(s) were added to refs/heads/main by this push:
> :  new 15534754f49 SOLR-16949: Restrict certain file types from being 
> uploaded to or downloaded from Config Sets
> : 15534754f49 is described below
> : 
> : commit 15534754f492079e52288dd11abaf1c4261b3ea4
> : Author: Jan Høydahl 
> : AuthorDate: Wed Dec 13 22:49:23 2023 +0100
> : 
> : SOLR-16949: Restrict certain file types from being uploaded to or 
> downloaded from Config Sets
> : ---
> :  solr/CHANGES.txt   |   2 +
> :  solr/core/build.gradle |   2 +
> :  .../org/apache/solr/cli/ConfigSetUploadTool.java   |   2 +
> :  .../org/apache/solr/cloud/ZkConfigSetService.java  |  21 ++-
> :  .../solr/core/FileSystemConfigSetService.java  |  28 +++-
> :  .../org/apache/solr/core/backup/BackupManager.java |  23 ++-
> :  .../handler/configsets/UploadConfigSetFileAPI.java |   8 +-
> :  .../org/apache/solr/util/FileTypeMagicUtil.java| 166 
> +
> :  solr/core/src/resources/magic/executables  |  74 +
> :  solr/core/src/test-files/magic/HelloWorld.java.txt |   5 +
> :  .../test-files/magic/HelloWorldJavaClass.class.bin | Bin 0 -> 426 bytes
> :  solr/core/src/test-files/magic/README.md   |  29 
> :  solr/core/src/test-files/magic/hello.tar.bin   | Bin 0 -> 4096 bytes
> :  solr/core/src/test-files/magic/plain.txt   |   1 +
> :  solr/core/src/test-files/magic/shell.sh.txt|   2 +
> :  .../org/apache/solr/cloud/TestConfigSetsAPI.java   | 141 +++--
> :  .../apache/solr/util/FileTypeMagicUtilTest.java|  54 +++
> :  solr/licenses/simplemagic-1.17.jar.sha1|   1 +
> :  solr/licenses/simplemagic-LICENSE-BSD_LIKE.txt |  15 ++
> :  solr/licenses/simplemagic-NOTICE.txt   |   0
> :  .../solr/common/cloud/ZkMaintenanceUtils.java  |   2 +
> :  versions.lock  |   1 +
> :  versions.props |   1 +
> :  23 files changed, 522 insertions(+), 56 deletions(-)
> : 
> : diff --git a/solr/CHANGES.txt b/solr/CHANGES.txt
> : index 40da8c435ac..2fd94304a24 100644
> : --- a/solr/CHANGES.txt
> : +++ b/solr/CHANGES.txt
> : @@ -169,6 +169,8 @@ Other Changes
> :  * SOLR-17091: dev tools script cloud.sh became broken after changes in 9.3 
> added a new -slim.tgz file it was not expecting
> :cloud.sh has been updated to ignore the -slim.tgz version of the tarball.
> :  
> : +* SOLR-16949: Restrict certain file types from being uploaded to or 
> downloaded from Config Sets (janhoy, Houston Putman)
> : +
> :  ==  9.4.0 ==
> :  New Features
> :  -
> : diff --git a/solr/core/build.gradle b/solr/core/build.gradle
> : index 61ecd1713af..ed2c8a370ae 100644
> : --- a/solr/core/build.gradle
> : +++ b/solr/core/build.gradle
> : @@ -159,6 +159,8 @@ dependencies {
> :  
> :compileOnly 'com.github.stephenc.jcip:jcip-annotations'
> :  
> : +  implementation 'com.j256.simplemagic:simplemagic'
> : +
> :// -- Test Dependencies
> :  
> :testRuntimeOnly 'org.slf4j:jcl-over-slf4j'
> : diff --git 
> a/solr/core/src/java/org/apache/solr/cli/ConfigSetUploadTool.java 
> b/solr/core/src/java/org/apache/solr/cli/ConfigSetUploadTool.java
> : index 5fd4a538bd7..6576742a195 100644
> : --- a/solr/core/src/java/org/apache/solr/cli/ConfigSetUploadTool.java
> : +++ b/solr/core/src/java/org/apache/solr/cli/ConfigSetUploadTool.java
> : @@ -27,6 +27,7 @@ import 
> org.apache.solr.client.solrj.impl.SolrZkClientTimeout;
>

Re: Solr 9.4.1

[Jan Høydahl]

SolrBot had been failing for a long time (>1month), but I got it on track 
again. Normally it only files new PRs on Sundays, but I'm triggering that 
manually now to consider what other upgrades from the past month that we should 
put into 9.4.1.

Please have a look at https://github.com/apache/solr/pulls/solrbot and consider 
which ones should be merged and backported.

Jan

> 8. des. 2023 kl. 14:59 skrev David Smiley :
> 
> I renamed that job to add "(Crave)"
> https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x%20(Crave)/ and
> disabled it.  I then I created a new job copied from the "Solr-check-main"
> but branch_9x.  Builds are hourly so we'll see how it goes.
> 
> ~ David
> 
> 
> On Thu, Dec 7, 2023 at 10:08 AM Jan Høydahl  wrote:
> 
>> PS: https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/ is also not
>> running since 25 days as it was converted to Crave..
>> 
>> Jan
>> 
>>> 7. des. 2023 kl. 15:06 skrev David Smiley :
>>> 
>>> I've been working with Uv on these glitches.
>>> ~ David
>>> 
>>> 
>>> On Thu, Dec 7, 2023 at 2:47 AM Jan Høydahl 
>> wrote:
>>> 
>>>> I backported ALL SolrBot PRs to branch_9_4, which brings the number of
>>>> known CVEs down.
>>>> 
>>>> I also have a few other dependency upgrades baking in PRs but
>>>> unfortunately Crave has died so no PRs pass tests:
>>>> 
>>>>> Run cd
>>>> 
>> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
>>>>> Selecting project Solr (id:39)
>>>>> Error: Process completed with exit code 1.
>>>> 
>>>> Jan
>>>> 
>>>>> 7. des. 2023 kl. 02:44 skrev David Smiley :
>>>>> 
>>>>> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will happen
>> as
>>>>> there are a couple security matters we're looking at.
>>>>> ~ David
>>>>> 
>>>>> 
>>>>> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh <
>>>> ep...@opensourceconnections.com>
>>>>> wrote:
>>>>> 
>>>>>> Something that I’d like to get released ASAP is a fix to the bin/solr
>>>> post
>>>>>> command.
>>>>>> 
>>>>>> Our Ref Guide has a lot of mentions of using “bin/solr post -c tech
>>>>>> products”, however I removed the -c parameter in favour of -url
>>>> parameter.
>>>>>> I think that was a mistake, and would like to restore the old -c
>>>> parameter,
>>>>>> and then make sure the Ref Guide is up to date.
>>>>>> 
>>>>>> This could be a 9.4.1 or 9.5 change.
>>>>>> 
>>>>>>> On Dec 6, 2023, at 10:31 AM, Jason Gerlowski 
>>>>>> wrote:
>>>>>>> 
>>>>>>> Good question - I'm still thinking through what makes the most sense
>>>>>>> there.  Let's continue discussion on SOLR-17100 if you've got
>> thoughts!
>>>>>>> 
>>>>>>> On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Jason, what do you mean by "publishing" the clients?
>>>>>>>> I suppose you don't mean pip and npm, but including them in the
>> binary
>>>>>>>> tarball for users to consume? Or can we perhaps keep them "internal"
>>>>>> only
>>>>>>>> for a few releases with no docs and no guarantees, only dog-fooding?
>>>>>>>> 
>>>>>>>> Jan
>>>>>>>> 
>>>>>>>>> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski <
>> gerlowsk...@gmail.com
>>>>> :
>>>>>>>>> 
>>>>>>>>> I'd love to see a 9.5 go out sometime in January to get our new
>>>> Python
>>>>>>>> and
>>>>>>>>> Javascript clients in front of users.  I'm willing to RM the
>> release,
>>>>>> or
>>>>>>>>> share duties with you if you're interested David?  Publishing the
>> new
>>>>>>>>> clients will require some changes to the release process, and I'd
>>>> hate
>>>>>> to
>>>>>>>>> saddle s

Re: [PR] Update org.apache.logging.log4j:* to v2.22.0 [solr]

[Jan Høydahl]

Hi,

I tried fixing this error while running 'gradle updateLicenses', but cannot see 
why it fails. We already explicitly include the biz.aQute.bnd.annotation 
dependency...

Jan

> 8. des. 2023 kl. 10:58 skrev solrbot (via GitHub) :
> 
> 
> solrbot commented on PR #2047:
> URL: https://github.com/apache/solr/pull/2047#issuecomment-1846887507
> 
>   ### ⚠ Artifact update problem
> 
>   Renovate failed to update an artifact related to this branch. You probably 
> do not want to merge this PR as-is.
> 
>   ♻ Renovate will retry this branch, including artifacts, only when one of 
> the following happens:
> 
>- any of the package files in this branch needs updating, or 
>- the branch becomes conflicted, or
>- you click the rebase/retry checkbox if found above, or
>- you rename this PR's title to start with "rebase!" to trigger it manually
> 
>   The artifact failure details are included below:
> 
>   # File name: undefined
> 
>   ```
>   Command failed: ./gradlew updateLicenses
>   Note: Some input files use or override a deprecated API.
>   Note: Recompile with -Xlint:deprecation for details.
>   Note: Some input files use or override a deprecated API.
>   Note: Recompile with -Xlint:deprecation for details.
>   
> /tmp/renovate/repos/github/apache/solr/?/.gradle/caches/modules-2/files-2.1/org.apache.logging.log4j/log4j-api/2.22.0/2c7d82708efd430e722562be1993defd9fb2426b/log4j-api-2.22.0.jar(/org/apache/logging/log4j/Level.class):
>  warning: Cannot find annotation method 'value()' in type 'BaselineIgnore': 
> class file for aQute.bnd.annotation.baseline.BaselineIgnore not found
>   error: warnings found and -Werror specified
>   Note: Some input files use or override a deprecated API.
>   Note: Recompile with -Xlint:deprecation for details.
>   1 error
>   1 warning
> 
>   FAILURE: Build failed with an exception.
> 
>   * What went wrong:
>   Execution failed for task ':solr:test-framework:compileJava'.
>> Compilation failed; see the compiler error output for details.
> 
>   * Try:
>> Run with --info option to get more log output.
> 
>   BUILD FAILED in 20s
> 
>   ```
> 
> 
> 
> 
> -- 
> This is an automated message from the Apache Git Service.
> To respond to the message, please log on to GitHub and use the
> URL above to go to the specific comment.
> 
> To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
> 
> For queries about this service, please contact Infrastructure at:
> us...@infra.apache.org
> 
> 
> -
> To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
> For additional commands, e-mail: issues-h...@solr.apache.org
> 

Re: Solr 9.4.1

[Jan Høydahl]

PS: https://ci-builds.apache.org/job/Solr/job/Solr-Check-9.x/ is also not 
running since 25 days as it was converted to Crave..

Jan

> 7. des. 2023 kl. 15:06 skrev David Smiley :
> 
> I've been working with Uv on these glitches.
> ~ David
> 
> 
> On Thu, Dec 7, 2023 at 2:47 AM Jan Høydahl  wrote:
> 
>> I backported ALL SolrBot PRs to branch_9_4, which brings the number of
>> known CVEs down.
>> 
>> I also have a few other dependency upgrades baking in PRs but
>> unfortunately Crave has died so no PRs pass tests:
>> 
>>> Run cd
>> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
>>> Selecting project Solr (id:39)
>>> Error: Process completed with exit code 1.
>> 
>> Jan
>> 
>>> 7. des. 2023 kl. 02:44 skrev David Smiley :
>>> 
>>> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will happen as
>>> there are a couple security matters we're looking at.
>>> ~ David
>>> 
>>> 
>>> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh <
>> ep...@opensourceconnections.com>
>>> wrote:
>>> 
>>>> Something that I’d like to get released ASAP is a fix to the bin/solr
>> post
>>>> command.
>>>> 
>>>> Our Ref Guide has a lot of mentions of using “bin/solr post -c tech
>>>> products”, however I removed the -c parameter in favour of -url
>> parameter.
>>>> I think that was a mistake, and would like to restore the old -c
>> parameter,
>>>> and then make sure the Ref Guide is up to date.
>>>> 
>>>> This could be a 9.4.1 or 9.5 change.
>>>> 
>>>>> On Dec 6, 2023, at 10:31 AM, Jason Gerlowski 
>>>> wrote:
>>>>> 
>>>>> Good question - I'm still thinking through what makes the most sense
>>>>> there.  Let's continue discussion on SOLR-17100 if you've got thoughts!
>>>>> 
>>>>> On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl 
>>>> wrote:
>>>>> 
>>>>>> Jason, what do you mean by "publishing" the clients?
>>>>>> I suppose you don't mean pip and npm, but including them in the binary
>>>>>> tarball for users to consume? Or can we perhaps keep them "internal"
>>>> only
>>>>>> for a few releases with no docs and no guarantees, only dog-fooding?
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski >> :
>>>>>>> 
>>>>>>> I'd love to see a 9.5 go out sometime in January to get our new
>> Python
>>>>>> and
>>>>>>> Javascript clients in front of users.  I'm willing to RM the release,
>>>> or
>>>>>>> share duties with you if you're interested David?  Publishing the new
>>>>>>> clients will require some changes to the release process, and I'd
>> hate
>>>> to
>>>>>>> saddle someone else with ironing out whatever hiccups are likely to
>>>> crop
>>>>>> up.
>>>>>>> 
>>>>>>> What do you guys think about doing 9.5 on a January-ish timeframe?
>>>>>>> 
>>>>>>> That said, if someone else wants a 9.4.1 I don't want to get in the
>> way
>>>>>> of
>>>>>>> that either.  Jan's right that there'd still be value in a 9.4.1 even
>>>>>> with
>>>>>>> a 9.5.  I imagine the driving factor would be whether there's a
>> willing
>>>>>> RM
>>>>>>> for 9.4.1
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On Wed, Dec 6, 2023 at 5:42 AM Jan Høydahl 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> The benefit of doing 9.4.1 now is that it won't have that unknown
>>>>>>>> regression that may be lurking in branch_9x now, so it's a much
>> easier
>>>>>>>> upgrade path for 9.4.0 users.
>>>>>>>> However, I feel a 9.5 should follow quickly after. There is always
>>>> room
>>>>>>>> for a 9.6, 9.7 etc if someone wants to promote newer features, we
>>>> don't
>>>>>>>> need to wait for a certain number of new featu

Re: Solr 9.4.1

[Jan Høydahl]

I backported ALL SolrBot PRs to branch_9_4, which brings the number of known 
CVEs down. 

I also have a few other dependency upgrades baking in PRs but unfortunately 
Crave has died so no PRs pass tests:

> Run cd 
> /crave-devspaces/pipeline/runs/${GITHUB_RUN_ID}_${GITHUB_RUN_NUMBER}/solr
> Selecting project Solr (id:39)
> Error: Process completed with exit code 1.

Jan

> 7. des. 2023 kl. 02:44 skrev David Smiley :
> 
> Sounds good Eric.  It's not clear when exactly a 9.4.1 RC will happen as
> there are a couple security matters we're looking at.
> ~ David
> 
> 
> On Wed, Dec 6, 2023 at 12:31 PM Eric Pugh 
> wrote:
> 
>> Something that I’d like to get released ASAP is a fix to the bin/solr post
>> command.
>> 
>> Our Ref Guide has a lot of mentions of using “bin/solr post -c tech
>> products”, however I removed the -c parameter in favour of -url parameter.
>> I think that was a mistake, and would like to restore the old -c parameter,
>> and then make sure the Ref Guide is up to date.
>> 
>> This could be a 9.4.1 or 9.5 change.
>> 
>>> On Dec 6, 2023, at 10:31 AM, Jason Gerlowski 
>> wrote:
>>> 
>>> Good question - I'm still thinking through what makes the most sense
>>> there.  Let's continue discussion on SOLR-17100 if you've got thoughts!
>>> 
>>> On Wed, Dec 6, 2023 at 9:58 AM Jan Høydahl 
>> wrote:
>>> 
>>>> Jason, what do you mean by "publishing" the clients?
>>>> I suppose you don't mean pip and npm, but including them in the binary
>>>> tarball for users to consume? Or can we perhaps keep them "internal"
>> only
>>>> for a few releases with no docs and no guarantees, only dog-fooding?
>>>> 
>>>> Jan
>>>> 
>>>>> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski :
>>>>> 
>>>>> I'd love to see a 9.5 go out sometime in January to get our new Python
>>>> and
>>>>> Javascript clients in front of users.  I'm willing to RM the release,
>> or
>>>>> share duties with you if you're interested David?  Publishing the new
>>>>> clients will require some changes to the release process, and I'd hate
>> to
>>>>> saddle someone else with ironing out whatever hiccups are likely to
>> crop
>>>> up.
>>>>> 
>>>>> What do you guys think about doing 9.5 on a January-ish timeframe?
>>>>> 
>>>>> That said, if someone else wants a 9.4.1 I don't want to get in the way
>>>> of
>>>>> that either.  Jan's right that there'd still be value in a 9.4.1 even
>>>> with
>>>>> a 9.5.  I imagine the driving factor would be whether there's a willing
>>>> RM
>>>>> for 9.4.1
>>>>> 
>>>>> 
>>>>> 
>>>>> On Wed, Dec 6, 2023 at 5:42 AM Jan Høydahl 
>>>> wrote:
>>>>> 
>>>>>> The benefit of doing 9.4.1 now is that it won't have that unknown
>>>>>> regression that may be lurking in branch_9x now, so it's a much easier
>>>>>> upgrade path for 9.4.0 users.
>>>>>> However, I feel a 9.5 should follow quickly after. There is always
>> room
>>>>>> for a 9.6, 9.7 etc if someone wants to promote newer features, we
>> don't
>>>>>> need to wait for a certain number of new features to release, in my
>>>> mind it
>>>>>> is enought that we have one very interesting feature, or that >2
>> months
>>>> has
>>>>>> passed.
>>>>>> 
>>>>>> I can help backport dependency upgrades.
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 6. des. 2023 kl. 05:50 skrev David Smiley >> :
>>>>>>> 
>>>>>>> Ideally I would have done a 9.4.1 earlier for that one issue... but I
>>>>>>> didn't and kept feeling more and more guilty... so here we are.  But
>>>>>> really
>>>>>>> I shouldn't feel too guilty; open-source is volunteering; doing a
>> patch
>>>>>>> release shouldn't be a required punishment for an unfortunate bug.
>> It
>>>>>>> wasn't even a feature I was using in my day-to-day; I was just
>> helping
>>>>>>> someone fix their problem.
>>>&g

Re: Solr 9.4.1

[Jan Høydahl]

Jason, what do you mean by "publishing" the clients?
I suppose you don't mean pip and npm, but including them in the binary tarball 
for users to consume? Or can we perhaps keep them "internal" only for a few 
releases with no docs and no guarantees, only dog-fooding?

Jan

> 6. des. 2023 kl. 15:38 skrev Jason Gerlowski :
> 
> I'd love to see a 9.5 go out sometime in January to get our new Python and
> Javascript clients in front of users.  I'm willing to RM the release, or
> share duties with you if you're interested David?  Publishing the new
> clients will require some changes to the release process, and I'd hate to
> saddle someone else with ironing out whatever hiccups are likely to crop up.
> 
> What do you guys think about doing 9.5 on a January-ish timeframe?
> 
> That said, if someone else wants a 9.4.1 I don't want to get in the way of
> that either.  Jan's right that there'd still be value in a 9.4.1 even with
> a 9.5.  I imagine the driving factor would be whether there's a willing RM
> for 9.4.1
> 
> 
> 
> On Wed, Dec 6, 2023 at 5:42 AM Jan Høydahl  wrote:
> 
>> The benefit of doing 9.4.1 now is that it won't have that unknown
>> regression that may be lurking in branch_9x now, so it's a much easier
>> upgrade path for 9.4.0 users.
>> However, I feel a 9.5 should follow quickly after. There is always room
>> for a 9.6, 9.7 etc if someone wants to promote newer features, we don't
>> need to wait for a certain number of new features to release, in my mind it
>> is enought that we have one very interesting feature, or that >2 months has
>> passed.
>> 
>> I can help backport dependency upgrades.
>> 
>> Jan
>> 
>>> 6. des. 2023 kl. 05:50 skrev David Smiley :
>>> 
>>> Ideally I would have done a 9.4.1 earlier for that one issue... but I
>>> didn't and kept feeling more and more guilty... so here we are.  But
>> really
>>> I shouldn't feel too guilty; open-source is volunteering; doing a patch
>>> release shouldn't be a required punishment for an unfortunate bug.  It
>>> wasn't even a feature I was using in my day-to-day; I was just helping
>>> someone fix their problem.
>>> 
>>> BTW a new Lucene release is close so we might to wait a bit on Solr 9.5,
>> so
>>> maybe we do this 9.4.1.  That Lucene release also touches the index
>> format
>>> BTW.
>>> 
>>> ~ David
>>> 
>>> 
>>> On Tue, Dec 5, 2023 at 8:50 PM Shawn Heisey >> 
>>> wrote:
>>> 
>>>> On 12/5/23 16:28, David Smiley wrote:
>>>>> I didn't know doing 9.5 was an option.  If it still is, I would prefer
>> to
>>>>> do 9.5.  What do people think?
>>>> 
>>>> The 9.5.0 section of CHANGES.txt in main is not as big as that for
>>>> 9.4.0, but it's not small either.
>>>> 
>>>> I do not know whether any of those changes are something that the author
>>>> thinks needs to bake for a little while longer.
>>>> 
>>>> I run a branch_9x snapshot on my little tiny Solr install that gets its
>>>> index from dovecot, and I update it frequently.  It hasn't given me any
>>>> trouble.
>>>> 
>>>> I say go for it.  Someday I will do a release myself.
>>>> 
>>>> Thanks,
>>>> Shawn
>>>> 
>>>> 
>>>> -
>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>>> 
>>>> 
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 


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

Re: Solr 9.4.1

[Jan Høydahl]

The benefit of doing 9.4.1 now is that it won't have that unknown regression 
that may be lurking in branch_9x now, so it's a much easier upgrade path for 
9.4.0 users.
However, I feel a 9.5 should follow quickly after. There is always room for a 
9.6, 9.7 etc if someone wants to promote newer features, we don't need to wait 
for a certain number of new features to release, in my mind it is enought that 
we have one very interesting feature, or that >2 months has passed.

I can help backport dependency upgrades.

Jan

> 6. des. 2023 kl. 05:50 skrev David Smiley :
> 
> Ideally I would have done a 9.4.1 earlier for that one issue... but I
> didn't and kept feeling more and more guilty... so here we are.  But really
> I shouldn't feel too guilty; open-source is volunteering; doing a patch
> release shouldn't be a required punishment for an unfortunate bug.  It
> wasn't even a feature I was using in my day-to-day; I was just helping
> someone fix their problem.
> 
> BTW a new Lucene release is close so we might to wait a bit on Solr 9.5, so
> maybe we do this 9.4.1.  That Lucene release also touches the index format
> BTW.
> 
> ~ David
> 
> 
> On Tue, Dec 5, 2023 at 8:50 PM Shawn Heisey 
> wrote:
> 
>> On 12/5/23 16:28, David Smiley wrote:
>>> I didn't know doing 9.5 was an option.  If it still is, I would prefer to
>>> do 9.5.  What do people think?
>> 
>> The 9.5.0 section of CHANGES.txt in main is not as big as that for
>> 9.4.0, but it's not small either.
>> 
>> I do not know whether any of those changes are something that the author
>> thinks needs to bake for a little while longer.
>> 
>> I run a branch_9x snapshot on my little tiny Solr install that gets its
>> index from dovecot, and I update it frequently.  It hasn't given me any
>> trouble.
>> 
>> I say go for it.  Someday I will do a release myself.
>> 
>> Thanks,
>> Shawn
>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 


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

Upgrade to Lucene 9.9

[Jan Høydahl]

Hi,

I made a JIRA for upgrading to Lucene 9.9, see 
https://issues.apache.org/jira/browse/SOLR-17097

This can be a good first task for someone who wants to contribute for the first 
time.
If that's you, feel free to reply to this mail and then start working on the 
task. We'll hold your hand as much as you need!

Jan

Re: Solr 9.4.1

[Jan Høydahl]

+1

I backported these bugfixes:

SOLR-17039: Entropy calculation in bin/solr script fails in Docker due to 
missing 'bc' cmd (janhoy)
SOLR-6853: Allow '/' characters in the text managed by Managed Resources API. 
(Nikita Rusetskii via Eric Pugh) (PR )

We should also backport all or some of the dependency upgrades currently in 
branch_9x which are not in branch_9_4. This list of commits after October 3rd 
was copied from my git log:

Update dependency com.google.errorprone:error_prone_annotations to v2.23.0 
(#2035) Solr Bot* 24/10/2023, 20:45
Update io.netty:* to v4.1.100.Final (#2013) Solr Bot* 23/10/2023, 22:16
Update io.grpc:grpc-* to v1.59.0 (#2036) Solr Bot* 23/10/2023, 22:04
Update org.apache.logging.log4j:* to v2.21.0 (#2037) Solr Bot* 23/10/2023, 21:40
Update io.dropwizard.metrics:* to v4.2.21 (#2033) Solr Bot* 23/10/2023, 18:46
Update dependency io.swagger.core.v3:swagger-annotations to v2.2.17 (#2032) 
Solr Bot* 23/10/2023, 18:46
Update dependency org.codehaus.woodstox:stax2-api to v4.2.2 (#2015) Solr Bot* 
23/10/2023, 17:19
Update dependency com.fasterxml.jackson:jackson-bom to v2.15.3 (#2031) Solr 
Bot* 23/10/2023, 17:08
Update dependency com.github.spotbugs:spotbugs-annotations to v4.8.0 (#2034) 
Solr Bot* 23/10/2023, 17:08
Update dependency com.google.guava:guava to v32.1.3-jre (#2014) Solr Bot* 
23/10/2023, 17:07
Update dependency org.immutables:value-annotations to v2.10.0 (#2010) Solr Bot* 
23/10/2023, 17:07
Update dependency io.opentelemetry:opentelemetry-bom to v1.31.0 (#2009) Solr 
Bot* 23/10/2023, 17:07
Update dependency org.semver4j:semver4j to v5.2.2 (#2008) Solr Bot* 23/10/2023, 
17:07
Update org.apache.zookeeper:* to v3.9.1 (#1989) Solr Bot* 10/10/2023, 22:03
SOLR-17012: Update Apache Hadoop to 3.3.6 and Apache Curator to 5.5.0 (#1743) 
Solr Bot* 05/10/2023, 01:25
Update dependency com.google.cloud:google-cloud-bom to v0.204.0 (#1745) Solr 
Bot* 03/10/2023, 22:02
Update io.grpc:grpc-* to v1.58.0 (#1769) Solr Bot* 03/10/2023, 20:46

PS: Did you consider doing the 9.5.0 release instead of 9.4.1? It's been almost 
2 months.

Jan

> 4. des. 2023 kl. 21:46 skrev David Smiley :
> 
> I plan to do a 9.4.1 release, especially based on this regression:
> SOLR-17057 -- JSON Query regression; defType doesn't work in "params"
> 
> Proposed RC:  in 48 hours.  So now's the time to do some back-porting.  I
> need to merge that one above, for example.
> 
> Believe it or not, I have never done a release before!  LOL it's true.
> Well here goes nothing.
> 
> ~ David

Re: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues and Github Projects, and migrate mailing lists to Github Discussions

[Jan Høydahl]

Bringing this to our attention again. Lucene seems to have survived well after 
the migration to Github issues. They have established a way to work with 
milestones (https://github.com/apache/lucene/milestones) and labels 
(https://github.com/apache/lucene/labels?q=type), and they have updated 
release-wizard with corresponding steps.

So are we ready to follow their lead?

Jan

> 18. okt. 2022 kl. 12:58 skrev Jan Høydahl :
> 
> +1 from me too.
> 
> I'm still not sold on bringing all history from JIRA into GH but that's what 
> Lucene did, so perhaps just doing the same (+ lessons learnt) is the 
> smoothest path.
> Solr would in addition need to find a new process for security issues. But we 
> could just fall back on plain security@solr mailing list until a new solution 
> is ready.
> 
> Jan
> 
>> 17. okt. 2022 kl. 16:20 skrev David Smiley :
>> 
>> +1 to migrate.
>> 
>> Yeah.  Maybe Tomoko could validate the steps required?  (CC'ed)  Jeb listed
>> them in JIRA; the steps/mechanics can be discussed there while we leave
>> this thread as voting on the major decision.
>> 
>> ~ David Smiley
>> Apache Lucene/Solr Search Developer
>> http://www.linkedin.com/in/davidwsmiley
>> 
>> 
>> On Mon, Oct 17, 2022 at 10:12 AM Houston Putman  wrote:
>> 
>>> I'm a big +1 on this idea, just like I was for Lucene's migration.
>>> 
>>> Also I think that we could very much mooch off of the monumental amounts of
>>> hard work that Tomoko and Mike did for Lucene.
>>> 
>>> There would certainly still be manual work, and changes to their script
>>> needed, but I don't think it would be as back-breaking of a task.
>>> 
>>> - Houston
>>> 
>>> On Fri, Oct 14, 2022 at 1:07 AM Noble Paul  wrote:
>>> 
>>>> I agree that JIRA is one extra step that is not adding a lot of value.
>>>> Github issues are definitely better
>>>> 
>>>> On Fri, Oct 14, 2022 at 3:04 PM David Smiley  wrote:
>>>> 
>>>>> Sharing for visibility.
>>>>> 
>>>>> ~ David Smiley
>>>>> Apache Lucene/Solr Search Developer
>>>>> http://www.linkedin.com/in/davidwsmiley
>>>>> 
>>>>> 
>>>>> -- Forwarded message -
>>>>> From: Jeb Nix (Jira) 
>>>>> Date: Mon, Oct 10, 2022 at 7:11 PM
>>>>> Subject: [jira] [Created] (SOLR-16455) Migrate Jira to Github Issues
>>> and
>>>>> Github Projects, and migrate mailing lists to Github Discussions
>>>>> To: 
>>>>> 
>>>>> 
>>>>> Jeb Nix created SOLR-16455:
>>>>> --
>>>>> 
>>>>>Summary: Migrate Jira to Github Issues and Github
>>> Projects,
>>>>> and migrate mailing lists to Github Discussions
>>>>>Key: SOLR-16455
>>>>>URL: https://issues.apache.org/jira/browse/SOLR-16455
>>>>>Project: Solr
>>>>> Issue Type: Wish
>>>>> Security Level: Public (Default Security Level. Issues are
>>> Public)
>>>>> Components: github
>>>>>   Reporter: Jeb Nix
>>>>> 
>>>>> 
>>>>> GitHub is where people are at when they lookup for Solr (or basically
>>> any
>>>>> project). Most of the modern projects that have been started with Jira
>>>> and
>>>>> mailing lists have migrated to Github in the last few years. Lucene did
>>>>> that just now for the Issues which has allowed me to explore much more
>>> of
>>>>> their issues. GitHub works great and many think that it works even
>>> better
>>>>> (I think that there is no doubt that it is working better for the
>>>>> Discussions vs. Mailing lists).
>>>>> 
>>>>> I suggest here a pretty heavy move, that personally will allow me to
>>>> start
>>>>> anticipating within Solr's community (since I really don't like the
>>>> mailing
>>>>> lists nor Jira), and I think that there are much more like me out
>>> there.
>>>> In
>>>>> my opinion, when the issues are managed on Github, it is much simpler
>>> to
>>>>> collaborate and they will get wider exposure since de

Re: Solr Backup API Queries

[Jan Høydahl]

Hi

You may want to re-send this question to the users list. This dev list is for 
developing the solr codebase itself, not for user questions.

Jan Høydahl

> 2. nov. 2023 kl. 15:03 skrev Anusha R9 :
> 
> Hi Team,
> 
> We are trying to backup indexes in Prod. It created backup snapshots in 
> mentioned location. But it didn't create backup.properties, zk_backup files 
> in that location.
> So, when we use restore api, we are not able to restore, It failed with 
> exception that "No backup.properties file"
> We need help to know why backup.properties file is not created when backup we 
> ran backup api. Below is the api we are using for backup.
> http://username:password@hostname:port/solr/admin/collections?action=BACKUP&name=$newBackupName&collection=$myCollectionName&location=/opt/epricer-solr-backup/DR
> 
> We are using Solr version is 9.0.0 and solr cluster configuration.
> Also, I need clarification on whether we need to run solr backup api in 
> leader or follower solr server node?
> We need to run this backup api in Production. Can someone please answer our 
> queries.
> 
> Thanks and Regards,
> Anusha R
> 

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

Re: [VOTE] Release Lucene/Solr 8.11.3 RC1

[Jan Høydahl]

Hi,

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

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

Jan

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

Re: 8.11.3 release

[Jan Høydahl]

I also enabled the smoketest job, and it passes: 
https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-SmokeRelease-8.11/lastSuccessfulBuild/
 !

The Lucene-Solr-Tests-8.11 has failed a few times, but on different tests, so 
things are looking good.

Jan

> 27. okt. 2023 kl. 13:55 skrev Ishan Chattopadhyaya 
> :
> 
> Thanks Jan. Some tests are failing; Noble and I are looking into them. If
> all goes well, I'm planning to spin the RC1 by this weekend.
> 
> On Fri, 27 Oct, 2023, 2:45 pm Jan Høydahl,  wrote:
> 
>> Thanks Kevin, Ishan for doing the prep work here.
>> 
>> I re-enabled the jenkins job
>> https://ci-builds.apache.org/job/Lucene/job/Lucene-Solr-Tests-8.11/ to
>> get a feel for the current status. We also have a smokeTest job that should
>> be enabled when release is approaching.
>> 
>> Jan
>> 
>>> 12. okt. 2023 kl. 19:38 skrev Kevin Risden :
>>> 
>>> I've pushed a few things to branch_8_11 recently
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/e491400d961b771f146c6e12a7f8ed89eafe128f
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/8e545e8f2154698e9bfeee92c40f8541fd7d0152
>>> *
>>> 
>> https://github.com/apache/lucene-solr/commit/e7560cd2ab024d4315933cd3965aab2961bba994
>>> 
>>> https://github.com/apache/lucene-solr/pull/2681 is in draft and updated
>> a
>>> bunch of relatively low risk dependencies. There might be others we want
>> to
>>> upgrade, but figured it was a decent start.
>>> 
>>> Kevin Risden
>>> 
>>> 
>>> On Thu, Oct 5, 2023 at 4:27 AM Pierre Salagnac <
>> pierre.salag...@gmail.com>
>>> wrote:
>>> 
>>>> I just opened a pull request.
>>>> https://github.com/apache/lucene-solr/pull/2679
>>>> Details are in the PR.
>>>> 
>>>> Thanks !
>>>> 
>>>> Le lun. 2 oct. 2023 à 20:25, Ishan Chattopadhyaya <
>>>> ichattopadhy...@gmail.com>
>>>> a écrit :
>>>> 
>>>>> Thanks Pierre, I'll have it included in 8.11 once you are able to have
>> a
>>>> PR
>>>>> for this. Thanks!
>>>>> 
>>>>> On Mon, 2 Oct 2023 at 22:22, Pierre Salagnac <
>> pierre.salag...@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Hi Ishan,
>>>>>> Sorry for the late chime in.
>>>>>> 
>>>>>> Some time ago I filled a Jira for a Solr 8 specific bug:
>>>>>> https://issues.apache.org/jira/browse/SOLR-16843
>>>>>> 
>>>>>> At that time, I wasn't expecting more 8.x releases, so I did not open
>> a
>>>>> PR
>>>>>> for it.
>>>>>> I can work on a fix if we have a few days more before the release. I
>>>>> think
>>>>>> it is worth to have it in solr 8 (that's not a backport)
>>>>>> 
>>>>>> Thanks
>>>>>> 
>>>>>> 
>>>>>> Le ven. 29 sept. 2023 à 23:24, Ishan Chattopadhyaya <
>>>>>> ichattopadhy...@gmail.com> a écrit :
>>>>>> 
>>>>>>> I'm going to track items from 9x releases in the following sheet.
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>> https://docs.google.com/spreadsheets/d/1FADkjDS0yfXpaUi3fbwsa7Izy5HOxE9AR_NKiss1sIo/edit#gid=0
>>>>>>> 
>>>>>>> Please let me know if there's any item there that you think would be
>>>>>> useful
>>>>>>> to backport (if easy) to 8.11, and want me to take a look at
>>>>> backporting
>>>>>>> it.
>>>>>>> Regards,
>>>>>>> Ishan
>>>>>>> 
>>>>>>> On Tue, 19 Sept 2023 at 01:15, Ishan Chattopadhyaya <
>>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Just a reminder to backport any issues one sees fit for a 8.11.3
>>>>>> release.
>>>>>>>> I'll try to get an RC out by the end of September, so still more
>>>>> than a
>>>>>>>> week away.
>>>>>>>> 
>>>>>>>> On Wed, 23 Aug 2023 at 17:09, Ishan Chattopadhyaya <
>>>>>>>> ichattopadhy...@gmail.com

Re: 8.11.3 release

[Jan Høydahl]

Thanks Kevin, Ishan for doing the prep work here.

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

Jan

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

Re: How about using JDK 21 in the official docker image?

[Jan Høydahl]

I agree on being conservative here. But if it turns out to work well, we could 
consider publishing an additional solr:9.4.0-jre21 tag. That way early adopters 
have a choice. If I remember correctly, Java 21 has some improvements that can 
benefit some vector workloads or something, so I see a benefit in getting it 
out there. We could alternatively opt to push temporary images like this to our 
own apache/solr docker namespace for folks to try out.

Jan 

> 24. okt. 2023 kl. 18:17 skrev Shawn Heisey :
> 
> On 10/18/2023 10:11 AM, Tomasz Elendt wrote:
>> I noticed that JDK 21 LTS was released some time ago. Is there any reason 
>> why official docker images still use JDK 17?
>> I'm asking because I know there are some preview JDK features that Lucene 
>> utilizes and Solr enables them when it detects a newer version (e.g. 
>> SOLR-16500).
>> Does it make sense to switch now that there is a new LTS version?
> 
> I have no desire to stand in the way of progress, but Java 21 has only been 
> out for a month.  I don't think it's a good idea to rely on a new major 
> version of *anything* that soon after its release.  Test with it, but don't 
> switch to it.
> 
> I do not think we should be planning on such a major upgrade to the docker 
> image until Java 21 has been out for a while.  I was going to upgrade my Solr 
> server to Java 21 to try it out since it's not a mission critical install, 
> but Ubuntu doesn't yet have OpenJDK packages for it. The 
> eclipse-temurin:21-jre-jammy docker image was pushed 11 days ago.
> 
> My thought on it is to wait until at least the release of Java 22, which will 
> happen six months after Java 21 was released.
> 
> Thanks,
> Shawn
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

Re: Apache Projects and Discussion Forums

[Jan Høydahl]

> GitHub is developer-centric and as such would likely, exclude most, non-dev, 
> users.

Last time I checked, (direct) users of Solr were developers. Not necessarily 
solr or java devs but tech people integrating or operating solr.

So I’d not exclude GH discussions. The barrier to joining the solr-user list 
discussions is higher than visiting our GH page and browsing discussions. How 
many already have a GH account vs a discourse account? But I agree we could 
have several channels.

Jan Høydahl

> 17. okt. 2023 kl. 07:27 skrev David Smiley :
> 
> GitHub is developer-centric and as such would likely,
> exclude most, non-dev, users.

Re: [VOTE] Release Solr 9.4.0 RC2

[Jan Høydahl]

+1 (binding)

SUCCESS! [0:40:48.041729]

Jan

> 11. okt. 2023 kl. 04:58 skrev Alex Deparvu :
> 
> Please vote for release candidate 2 for Solr 9.4.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC2-rev-71e101bb37497f730078d9afe1991b60d10bfe96
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC2-rev-71e101bb37497f730078d9afe1991b60d10bfe96
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC2-rev-71e101bb37497f730078d9afe1991b60d10bfe96/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-2 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-2-slim
> 
> The vote will be open for at least 72 hours i.e. until 2023-10-14 03:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (non binding)
> 
> best,
> alex


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

Re: [VOTE] Release Solr 9.4.0 RC1

[Jan Høydahl]

Fix: https://github.com/apache/solr/pull/2000

Feel free to argue why this bug should not warrant a re-spin.

Jan

> 10. okt. 2023 kl. 13:08 skrev Jan Høydahl :
> 
> Smoke tester: SUCCESS! [0:47:58.342068]
> 
> Manual testing:
> Started Solr locally on my mac outputs three lines of error mesages about 
> entropy:
> 
>> *** [WARN] *** Your open file limit is currently 256.
>>  It should be set to 65000 to avoid operational disruption.
>>  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false 
>> in your profile or solr.in.sh
>> *** [WARN] ***  Your Max Processes Limit is currently 5333.
>>  It should be set to 65000 to avoid operational disruption.
>>  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false 
>> in your profile or solr.in.sh
>> cat: /proc/sys/kernel/random/entropy_avail: No such file or directory
>> cat: /proc/sys/kernel/random/poolsize: No such file or directory
>> Error: Either no entropy is available or the pool size is zero.
>> Waiting up to 180 seconds to see Solr running on port 8983 [|]
>> Started Solr server on port 8983 (pid=42390). Happy searching!
> 
> This is introduced in SOLR-16644 
> <https://issues.apache.org/jira/browse/SOLR-16644>, and obviously assumes a 
> Linux system. 
> It will be quite confusing for Mac users or users of other non-linux systems 
> (AIX/FreeBSD?).
> The entopy probing using /proc/ should only be attempted on linux, and 
> probably skipped silently on other OSes.
> 
> For this reason I'll vote -1
> 
> Jan
> 
> 
>> 5. okt. 2023 kl. 21:51 skrev Alex Deparvu :
>> 
>> Please vote for release candidate 1 for Solr 9.4.0
>> 
>> The artifacts can be downloaded from:
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
>> 
>> You can run the smoke tester directly with this command:
>> 
>> python3 -u dev-tools/scripts/smokeTestRelease.py \
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
>> 
>> You can build a release-candidate of the official docker images (full &
>> slim) using the following command:
>> 
>> SOLR_DOWNLOAD_SERVER=
>> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b/solr
>> && \
>>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
>>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>-t solr-rc:9.4.0-1 && \
>>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
>>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>>-t solr-rc:9.4.0-1-slim
>> 
>> The vote will be open for at least 72 hours i.e. until 2023-10-08 20:00 UTC.
>> 
>> [ ] +1  approve
>> [ ] +0  no opinion
>> [ ] -1  disapprove (and reason why)
>> 
>> Here is my +1 (which I am not completely sure, but I think it is
>> non-binding)
>> 
>> best,
>> alex
> 

Re: [VOTE] Release Solr 9.4.0 RC1

[Jan Høydahl]

Smoke tester: SUCCESS! [0:47:58.342068]

Manual testing:
Started Solr locally on my mac outputs three lines of error mesages about 
entropy:

> *** [WARN] *** Your open file limit is currently 256.
>  It should be set to 65000 to avoid operational disruption.
>  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false 
> in your profile or solr.in.sh
> *** [WARN] ***  Your Max Processes Limit is currently 5333.
>  It should be set to 65000 to avoid operational disruption.
>  If you no longer wish to see this warning, set SOLR_ULIMIT_CHECKS to false 
> in your profile or solr.in.sh
> cat: /proc/sys/kernel/random/entropy_avail: No such file or directory
> cat: /proc/sys/kernel/random/poolsize: No such file or directory
> Error: Either no entropy is available or the pool size is zero.
> Waiting up to 180 seconds to see Solr running on port 8983 [|]
> Started Solr server on port 8983 (pid=42390). Happy searching!

This is introduced in SOLR-16644 
, and obviously assumes a 
Linux system. 
It will be quite confusing for Mac users or users of other non-linux systems 
(AIX/FreeBSD?).
The entopy probing using /proc/ should only be attempted on linux, and probably 
skipped silently on other OSes.

For this reason I'll vote -1

Jan


> 5. okt. 2023 kl. 21:51 skrev Alex Deparvu :
> 
> Please vote for release candidate 1 for Solr 9.4.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-1 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-1-slim
> 
> The vote will be open for at least 72 hours i.e. until 2023-10-08 20:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (which I am not completely sure, but I think it is
> non-binding)
> 
> best,
> alex

Re: Apache Projects and Discussion Forums

[Jan Høydahl]

Perhaps stack overflow is willing to collaborate with infra for an SSO 
integration and provide an api for the asf to sync an archive copy of 
everything? Then it’d be an official alternative.

I know ml feels quite antiquated for newcomers.

Have you considered GitHub’s new “Discussion” tab? It’d perhaps be a more low 
hanging fruit given the pre-existing integration?

Jan Høydahl

> 10. okt. 2023 kl. 06:17 skrev David Smiley :
> 
> At the ASF Community-over-Code conference today, I brought up this topic
> with ASF Directors and members at a session about project communication.
> Yes, a project could host something if a project (PMC) wants to, provided
> that the "dev list" remains where official project decisions are made.
> Also, there was advice against over-use of Slack for many reasons.  I feel
> if we had a modern forum in place, we would not have been so tempted to
> setup Slack for users.
> 
> My main concern for *adding* a forum is fragmentation for users/everyone
> with us...@solr.apache.org.  I would much prefer bidirectional integration
> (i.e. a bridge or gateway) so that a user can choose the
> UX/interaction-model they prefer.  I don't want to cut the user community
> into silos that don't talk to each other.  I looked at Discourse
> https://meta.discourse.org and tried to find if it's possible to
> bridge/gateway to existing mailing lists.  I didn't see it but hopefully it
> exists?  If not / in addition, the Solr user list can be imported into
> Discourse, but that's a one-time thing intended to transition in full.
> FWIW I support a complete transition to avoid fragmentation.
> 
> BTW fragmentation is already the case via stack-overflow today.  Granted I
> don't think there's been much traction there for Solr (yes some, but not
> much).  I heard some projects out there completely embrace stack-overflow
> and perhaps don't have a user list or similar.  A bold move but I get
> the appeal.  It's so radical to my norms that I'm hesitant to suggest it
> for us but I can't think of a good reason I'd oppose it.  Maybe some of you
> have opinions to share on that?
> 
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
> 
> 
>> On Thu, May 18, 2023 at 2:53 PM David Mackey  wrote:
>> 
>> Hi Everyone,
>> 
>> I apologize for the delay in responding, I wanted to give some time for
>> others to share their thoughts and due to the mention of a dedicated
>> solr.apache.org URL (I wanted to verify if this was something Discourse
>> offered in their free plan for open source projects, unfortunately it is
>> not).
>> 
>> I appreciate Alessandro's generous offer of hosting the forums on the
>> ir-relevant.net site however I'd lean towards having its forums fully
>> owned
>> by Apache/Solr. I am approaching this primarily from a visibility/marketing
>> perspective and I think having dedicated, official forums would be more
>> "impressive" to those considering Elastic <https://discuss.elastic.co/>,
>> OpenSearch <https://forum.opensearch.org/>, Solr, etc.
>> 
>> I would love to see the forums hosted on the official Solr domain as Ishan
>> suggested. The Apache TVM project's discussion URL is
>> https://discuss.tvm.apache.org/, so Solr could potentially have one like:
>> https://discuss.solr.apache.org/
>> 
>> I'd recommend using Discourse <https://discourse.org/> as the forum
>> software (it is what both Elastic and OpenSearch appear to be using). A
>> free
>> instance <https://free.discourse.group/> is available from Discourse for
>> open source projects. By default this instance would be hosted at
>> solr.discourse.group and unfortunately the free plan does not support
>> custom domains (though we could do a redirect from
>> https://discuss.solr.apache.org/ or similar the final url would still be
>> solr.discourse.group).
>> 
>> If Solr exceeds the 50k/views/mo. (sustained traffic, not occasional
>> spikes) the free plan offers we'd need to upgrade to the Standard Plan
>> which is available at a 50% discount for nonprofits (regular price:
>> $100/mo.; discounted price: $50/mo.). Alternatively we could using a VPS
>> host with a ~$20/mo. instance. In any case, I wouldn't anticipate us
>> exceeding the free plans capabilities for quite some time.
>> 
>> I'd suggest having two categories to start - End Users
>> (businesses/individuals who utilize the application) and Development (for
>> more code related topics). Two additional possible categories would be
>> Begin

Re: [VOTE] Release Solr 9.4.0 RC1

[Jan Høydahl]

Note that a vote running over a weekend is normally extended with a day or two. 
I plan to test the RC on Monday.

Jan Høydahl

> 5. okt. 2023 kl. 21:53 skrev Alex Deparvu :
> 
> Please vote for release candidate 1 for Solr 9.4.0
> 
> The artifacts can be downloaded from:
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> 
> You can run the smoke tester directly with this command:
> 
> python3 -u dev-tools/scripts/smokeTestRelease.py \
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b
> 
> You can build a release-candidate of the official docker images (full &
> slim) using the following command:
> 
> SOLR_DOWNLOAD_SERVER=
> https://dist.apache.org/repos/dist/dev/solr/solr-9.4.0-RC1-rev-ee474b7db483c2242ce1d75074258236ca22103b/solr
> && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-full \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-1 && \
>  docker build $SOLR_DOWNLOAD_SERVER/9.4.0/docker/Dockerfile.official-slim \
>--build-arg SOLR_DOWNLOAD_SERVER=$SOLR_DOWNLOAD_SERVER \
>-t solr-rc:9.4.0-1-slim
> 
> The vote will be open for at least 72 hours i.e. until 2023-10-08 20:00 UTC.
> 
> [ ] +1  approve
> [ ] +0  no opinion
> [ ] -1  disapprove (and reason why)
> 
> Here is my +1 (which I am not completely sure, but I think it is
> non-binding)
> 
> best,
> alex

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

Re: [DISCUSS] 9.4 release

[Jan Høydahl]

I added a blocker Jira for one solrbot upgrade for a CVE. Please check. Good 
luck with the release, I’ll not be available for the next few days.

Jan Høydahl

> 30. sep. 2023 kl. 00:02 skrev Eric Pugh :
> 
> If SOLR-14496, https://github.com/apache/solr/pull/1954 ends up getting 
> reviewed with no issues, I’m hoping to get it into 9.4….   Since we have 
> basic auth added to prometheus as well!
> 
> 
> 
>> On Sep 29, 2023, at 1:45 PM, Alex Deparvu  wrote:
>> 
>> Hi,
>> 
>> Just a quick status update
>> - SOLR-16994 looks almost complete: PR was reviewed, I'm not sure if there
>> is more work pending
>> - SOLR-16644 was merged and backported
>> - SOLR-16985 - lucene upgrade is almost complete. there are no more
>> failures (still running one single test a few more times just to make sure
>> if there is any flakiness here I will not include the upgrade in the
>> release). Thank you Christine Poerschke for helping out! If anyone else
>> wants to review, now would be a very good time.
>> 
>> Looks to me like we are in good shape for a release very soon!
>> I volunteered for this one, so I will dig up the docs to see what I need to
>> do Monday morning.
>> 
>> best,
>> alex
>> 
>> 
>>> On Fri, Sep 29, 2023 at 11:23 AM David Smiley 
>>> wrote:
>>> 
>>> There is no feature freeze yet (there is no branch_9_4), thus no necessity
>>> to ask permission.
>>> 
>>> ~ David
>>> 
>>> 
>>> On Fri, Sep 29, 2023 at 10:34 AM Ishan Chattopadhyaya <
>>> ichattopadhy...@gmail.com> wrote:
>>> 
>>>> I'd like to merge SOLR-16644, please. I think it is low risk, since it
>>>> affects only the start script and fixes the way a low entropy warning is
>>>> generated.
>>>> 
>>>> On Fri, 29 Sept 2023 at 03:19, Alex Deparvu 
>>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> It would be unfortunate to get this close and miss out on the Lucene
>>>>> release. I would want to give it one more day, if things do not work
>>>> out, I
>>>>> will go ahead with the release.
>>>>> 
>>>>> best,
>>>>> alex
>>>>> 
>>>>> 
>>>>> 
>>>>> On Thu, Sep 28, 2023 at 2:25 PM Jan Høydahl 
>>>> wrote:
>>>>> 
>>>>>> I see there is energy and traction into finalizing the Lucene 9.8
>>>>>> integration, so that's fine as long as we believe the risk to be
>>>> low-ish.
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 28. sep. 2023 kl. 21:53 skrev Anshum Gupta >>> :
>>>>>>> 
>>>>>>> I don't like holding up releases, but it's nice to not have too
>>> many
>>>>>>> releases from an operational standpoint. If fixing Solr for the
>>>> Lucene
>>>>>>> upgrade will take time, I think it's worth the trade-off and moving
>>>>>> forward
>>>>>>> with the older version of Lucene.
>>>>>>> 
>>>>>>> On Thu, Sep 28, 2023 at 6:05 AM Jan Høydahl >>> 
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Can I propose we do NOT hold the 9.4 release to add the (too
>>> fresh)
>>>>>> Lucene
>>>>>>>> 9.8? We can do a rapid 9.5 with any benefits reaped from the new
>>>>> Lucene
>>>>>>>> version.
>>>>>>>> 
>>>>>>>> Jan
>>>>>>>> 
>>>>>>>>> 28. sep. 2023 kl. 00:36 skrev Alex Deparvu >>> :
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Some updates to share on the upgrade.
>>>>>>>>> I have identified a cause for most of the failures and pushed a
>>>> fix.
>>>>>> this
>>>>>>>>> comment has all the details if anyone is interested in taking a
>>>> look
>>>>>>>>> https://github.com/apache/solr/pull/1958#issuecomment-1736170176
>>>>>>>>> I have also sent an email to lucene dev list to explain my
>>> findings
>>>>> and
>>>>>>>>> validate with them some of the

Re: [DISCUSS] 9.4 release

[Jan Høydahl]

I see there is energy and traction into finalizing the Lucene 9.8 integration, 
so that's fine as long as we believe the risk to be low-ish.

Jan

> 28. sep. 2023 kl. 21:53 skrev Anshum Gupta :
> 
> I don't like holding up releases, but it's nice to not have too many
> releases from an operational standpoint. If fixing Solr for the Lucene
> upgrade will take time, I think it's worth the trade-off and moving forward
> with the older version of Lucene.
> 
> On Thu, Sep 28, 2023 at 6:05 AM Jan Høydahl  wrote:
> 
>> Can I propose we do NOT hold the 9.4 release to add the (too fresh) Lucene
>> 9.8? We can do a rapid 9.5 with any benefits reaped from the new Lucene
>> version.
>> 
>> Jan
>> 
>>> 28. sep. 2023 kl. 00:36 skrev Alex Deparvu :
>>> 
>>> Hi,
>>> 
>>> Some updates to share on the upgrade.
>>> I have identified a cause for most of the failures and pushed a fix. this
>>> comment has all the details if anyone is interested in taking a look
>>> https://github.com/apache/solr/pull/1958#issuecomment-1736170176
>>> I have also sent an email to lucene dev list to explain my findings and
>>> validate with them some of the observations I had
>>> https://lists.apache.org/thread/1gs3nsv1mcns1czdtdnqyz84f31tqm2x
>>> 
>>> There are still some tests failing all in the vector search area I will
>>> look at next.
>>> 
>>> best,
>>> alex
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Sep 26, 2023 at 6:58 AM Alex Deparvu 
>> wrote:
>>> 
>>>> Hi,
>>>> 
>>>> It seems a lot of the upgrade failures are somehow related to
>>>> the CollapsingQParser (
>>>> 
>> https://solr.apache.org/guide/solr/latest/query-guide/collapse-and-expand-results.html
>>>> ).
>>>> If anyone is familiar with this code, I would appreciate a look at the
>> PR,
>>>> maybe something pops up.
>>>> 
>>>> best
>>>> alex
>>>> 
>>>> 
>>>> 
>>>> 
>>>> On Mon, Sep 25, 2023 at 3:18 PM Alex Deparvu 
>> wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> To prepare for the release I opened an 'early' Lucene 9.8.0 upgrade PR
>>>>> for review. There is a large number of tests failing, if anyone has
>> some
>>>>> time I would appreciate a hand.
>>>>> Tracking failures here
>>>>> https://github.com/apache/solr/pull/1958#issuecomment-1734473783
>>>>> 
>>>>> 
>>>>> best,
>>>>> alex
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> On Mon, Sep 18, 2023 at 1:23 PM Alex Deparvu 
>>>>> wrote:
>>>>> 
>>>>>> Good call Houston. I have created a Jira for the Lucene 9.8 upgrade
>> and
>>>>>> marked it as blocker for Solr 9.4
>>>>>> I will take a look once the Lucene release is out, if no one else
>> picks
>>>>>> it up first.
>>>>>> 
>>>>>> https://issues.apache.org/jira/browse/SOLR-16985
>>>>>> 
>>>>>> best
>>>>>> alex
>>>>>> 
>>>>>> 
>>>>>> On Mon, Sep 18, 2023 at 7:42 AM Houston Putman 
>>>>>> wrote:
>>>>>> 
>>>>>>> It looks like the next Lucene version might be released soon, so we
>> may
>>>>>>> want to wait for that. It will come with Java 21 support for the
>>>>>>> vector/memory map stuff.
>>>>>>> 
>>>>>>> - Houston
>>>>>>> 
>>>>>>> On Thu, Sep 14, 2023 at 10:53 PM Ishan Chattopadhyaya <
>>>>>>> ichattopadhy...@gmail.com> wrote:
>>>>>>> 
>>>>>>>> Thanks Alex and Jan!
>>>>>>>> 
>>>>>>>> On Fri, 15 Sept, 2023, 2:10 am Jan Høydahl, 
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Sure, it's all yours..
>>>>>>>>> You'll find what you need in the Release Wizard. Just run this
>>>>>>> script to
>>>>>>>>> get going.
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>

Re: [DISCUSS] 9.4 release

[Jan Høydahl]

Can I propose we do NOT hold the 9.4 release to add the (too fresh) Lucene 9.8? 
We can do a rapid 9.5 with any benefits reaped from the new Lucene version.

Jan

> 28. sep. 2023 kl. 00:36 skrev Alex Deparvu :
> 
> Hi,
> 
> Some updates to share on the upgrade.
> I have identified a cause for most of the failures and pushed a fix. this
> comment has all the details if anyone is interested in taking a look
> https://github.com/apache/solr/pull/1958#issuecomment-1736170176
> I have also sent an email to lucene dev list to explain my findings and
> validate with them some of the observations I had
> https://lists.apache.org/thread/1gs3nsv1mcns1czdtdnqyz84f31tqm2x
> 
> There are still some tests failing all in the vector search area I will
> look at next.
> 
> best,
> alex
> 
> 
> 
> 
> On Tue, Sep 26, 2023 at 6:58 AM Alex Deparvu  wrote:
> 
>> Hi,
>> 
>> It seems a lot of the upgrade failures are somehow related to
>> the CollapsingQParser (
>> https://solr.apache.org/guide/solr/latest/query-guide/collapse-and-expand-results.html
>> ).
>> If anyone is familiar with this code, I would appreciate a look at the PR,
>> maybe something pops up.
>> 
>> best
>> alex
>> 
>> 
>> 
>> 
>> On Mon, Sep 25, 2023 at 3:18 PM Alex Deparvu  wrote:
>> 
>>> Hi,
>>> 
>>> To prepare for the release I opened an 'early' Lucene 9.8.0 upgrade PR
>>> for review. There is a large number of tests failing, if anyone has some
>>> time I would appreciate a hand.
>>> Tracking failures here
>>> https://github.com/apache/solr/pull/1958#issuecomment-1734473783
>>> 
>>> 
>>> best,
>>> alex
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Mon, Sep 18, 2023 at 1:23 PM Alex Deparvu 
>>> wrote:
>>> 
>>>> Good call Houston. I have created a Jira for the Lucene 9.8 upgrade and
>>>> marked it as blocker for Solr 9.4
>>>> I will take a look once the Lucene release is out, if no one else picks
>>>> it up first.
>>>> 
>>>> https://issues.apache.org/jira/browse/SOLR-16985
>>>> 
>>>> best
>>>> alex
>>>> 
>>>> 
>>>> On Mon, Sep 18, 2023 at 7:42 AM Houston Putman 
>>>> wrote:
>>>> 
>>>>> It looks like the next Lucene version might be released soon, so we may
>>>>> want to wait for that. It will come with Java 21 support for the
>>>>> vector/memory map stuff.
>>>>> 
>>>>> - Houston
>>>>> 
>>>>> On Thu, Sep 14, 2023 at 10:53 PM Ishan Chattopadhyaya <
>>>>> ichattopadhy...@gmail.com> wrote:
>>>>> 
>>>>>> Thanks Alex and Jan!
>>>>>> 
>>>>>> On Fri, 15 Sept, 2023, 2:10 am Jan Høydahl, 
>>>>> wrote:
>>>>>> 
>>>>>>> Sure, it's all yours..
>>>>>>> You'll find what you need in the Release Wizard. Just run this
>>>>> script to
>>>>>>> get going.
>>>>>>> 
>>>>>> 
>>>>> https://github.com/apache/solr/blob/main/dev-tools/scripts/releaseWizard.py
>>>>>>> 
>>>>>>> Jan
>>>>>>> 
>>>>>>>> 14. sep. 2023 kl. 21:53 skrev Alex Deparvu >>>>> :
>>>>>>>> 
>>>>>>>> Hi,
>>>>>>>> 
>>>>>>>> I would be happy to give this a go (if provided ample hand
>>>>> holding).
>>>>>>>> 
>>>>>>>> 
>>>>>>>> best,
>>>>>>>> alex
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Thu, Sep 14, 2023 at 9:32 AM Jan Høydahl <
>>>>> jan@cominvent.com>
>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Branch_9x has accumulated 4 features, 18 improvements, 2
>>>>>> optimizations,
>>>>>>> 21
>>>>>>>>> bug fixes, 7 "other", and a bunch of dependency updates. It's
>>>>> been
>>>>>>> almost 2
>>>>>>>>> months since 9.3.
>>>>>>>>> 
>>>>>>>>> I propose cutting the branch and preparing first RC on Tuesday
>>>>> Sept
>>>>>>> 26th,
>>>>>>>>> twelve days from today.
>>>>>>>>> 
>>>>>>>>> I volunteer as RM, but will yield if one of our new committers
>>>>> wants
>>>>>> to
>>>>>>>>> try the Release Manager role!
>>>>>>>>> 
>>>>>>>>> Jan
>>>>>>>>> 
>>>>> -
>>>>>>>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>>>>>>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>>>>>>>> 
>>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 


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

Re: [DISCUSS] SIP-19 Adopt JSR-330 dependency injection

[Jan Høydahl]

Thanks. This is for sure a reason to consider HK2 which we already use.

I struggle a bit with un-winding the current class-dependency graph of Solr to 
figure out where it makes most sense to start a POC. I think perhaps injecting 
singleton CoreContainer could be a nice start. Do you know of a tool that 
generates some sort of class diagram one could use to find hotspots, cyclic 
references etc?

Jan


> 26. sep. 2023 kl. 22:00 skrev Jason Gerlowski :
> 
> +1 to experimenting with DI!
> 
> One thing that should probably be incorporated into the SIP and
> resolved at some level is that Solr does have some "non-homegrown" DI
> currently.  Jersey, the JAX-RS framework we're using to serve our v2
> APIs, allows some minimal DI in the resource classes that it
> instantiates by its use of a library called "HK2" (which implements
> JSR330). [1]. We don't do too much fancy with this - mostly just
> injecting already-existing "SolrCore" and "CoreContainer" objects into
> API classes.
> 
> That's about as far as my knowledge goes, unfortunately.  I imagine
> we'd want to use a single JSR330 implementation throughout Solr if we
> want to expand our use of DI, but I can't weigh in much on the
> tradeoffs of picking HK2 vs Dagger vs . Hopefully Jersey allows
> users to swap out other JSR330 implementations, but I can't say for
> certain.
> 
> Best,
> 
> Jason
> 
> [1] https://javaee.github.io/hk2/
> 
> On Tue, Sep 26, 2023 at 9:08 AM Justin Sweeney
>  wrote:
>> 
>> +1 on this SIP and a POC would make sense. I think it could be
>> valuable to update the Motivation section with the anticipated value
>> provided by this SIP, i.e. reduced code maintenance, removing brittle
>> home-grown interfaces, etc. Most of my IOC/DI experience is with
>> Spring and Dagger seems like a better choice here given the size and
>> complexity of the Spring libraries.
>> 
>> On Tue, Sep 26, 2023 at 8:30 AM Jan Høydahl  wrote:
>>> 
>>> This is the discuss thread for SIP-19
>>> 
>>> JIRA: https://issues.apache.org/jira/browse/SOLR-16998
>>> SIP link: 
>>> https://cwiki.apache.org/confluence/display/SOLR/SIP-19+Adopt+JSR-330+dependency+injection
>>> 
>>> Use a standardized dependency injection in Solr instead of our home grown 
>>> @SolrCoreAware, @ResourceLoaderAware, @SchemaAware etc.
>>> Proposal is to do a trial with Dagger2 (https://github.com/google/dagger) 
>>> which is a compile-time depenency injection framework.
>>> 
>>> Let's keep discussion here on the list.
>>> SIP document will be kept up to date with feedback from this discussion
>>> Code discussion on the JIRA (if/when we get there)
>>> 
>>> 
>>> I do not have any expereince with Dagger myself, and have not done any 
>>> deeper analysis of feasibility, or whether another framework is more 
>>> suitable for our use. I think first step would be a POC with a limited 
>>> scope.
>>> 
>>> Jan
>>> -
>>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>>> For additional commands, e-mail: dev-h...@solr.apache.org
>>> 
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
> 
> -
> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
> For additional commands, e-mail: dev-h...@solr.apache.org
> 


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

[DISCUSS] SIP-19 Adopt JSR-330 dependency injection

[Jan Høydahl]

This is the discuss thread for SIP-19

JIRA: https://issues.apache.org/jira/browse/SOLR-16998
SIP link: 
https://cwiki.apache.org/confluence/display/SOLR/SIP-19+Adopt+JSR-330+dependency+injection

Use a standardized dependency injection in Solr instead of our home grown 
@SolrCoreAware, @ResourceLoaderAware, @SchemaAware etc.
Proposal is to do a trial with Dagger2 (https://github.com/google/dagger) which 
is a compile-time depenency injection framework.

Let's keep discussion here on the list.
SIP document will be kept up to date with feedback from this discussion
Code discussion on the JIRA (if/when we get there)


I do not have any expereince with Dagger myself, and have not done any deeper 
analysis of feasibility, or whether another framework is more suitable for our 
use. I think first step would be a POC with a limited scope.

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

Re: [JENKINS] Solr » Solr-Check-main - Build # 7785 - Still Failing!

[Jan Høydahl]

Do we have Docker available on lucene-solr-1/2 runners? If we had I suppose we 
could
take advantage of that for bats? Maybe even the BATS tests could depend on the 
docker build and use the image?

Jan

> 22. sep. 2023 kl. 00:07 skrev David Smiley :
> 
> Alternatively we simply migrate these to Crave.io based on containerized
> (thus isolated) builds?  I can do this.
> ~ David
> 
> 
> On Wed, Sep 20, 2023 at 11:27 AM Houston Putman  wrote:
> 
>> Made a new ticket instead,
>> https://issues.apache.org/jira/browse/INFRA-25002
>> 
>> On Wed, Sep 20, 2023 at 10:31 AM Houston Putman 
>> wrote:
>> 
>>> Thanks for all the work here, Jan.
>>> 
>>> I think there are still some stray processes somehow. But in general I'm
>>> seeing other issues on lucene-solr-2.
>>> 
>>> I think there's an issue with the JDK installation, because the mTLS
>> tests
>>> are failing consistently on that box, while they succeed on
>> lucene-solr-1.
>>> There are also issues with the docker tests, as some folders need to be
>>> manually cleaned up.
>>> 
>>> I'll re-open that ticket.
>>> 
>>> - Houston
>>> 
>>> On Thu, Sep 14, 2023 at 7:13 AM Jan Høydahl 
>> wrote:
>>> 
>>>> Also filed SOLR ticket https://issues.apache.org/jira/browse/SOLR-16979
>>>> for improving the tests.
>>>> 
>>>> Jan
>>>> 
>>>>> 14. sep. 2023 kl. 12:58 skrev Jan Høydahl :
>>>>> 
>>>>> FYI: I filed an INFRA ticket
>>>> https://issues.apache.org/jira/browse/INFRA-24987 to kill the stray
>>>> process.
>>>>> 
>>>>> So how to do we harden the BATS tests? Can there be some
>>>> cleanup-all-forcefully-kill script ran at the end of the tests, whether
>>>> they pass or fail?
>>>>> 
>>>>> Jan
>>>>> 
>>>>>> 14. sep. 2023 kl. 11:16 skrev Jan Høydahl :
>>>>>> 
>>>>>> I'm seeing this all the time now since yesterday. Probably a former
>>>> Solr instance is hung, occupying port 8983.
>>>>>> Should the BATS tests pick a random port between 1 and 65000,
>> that
>>>> are used throughout all tests?
>>>>>> Then, a test run could clean up with some force killing at the end,
>>>> just for processes on that port?
>>>>>> 
>>>>>> Jan
>>>>>> 
>>>>>>> 25. aug. 2023 kl. 15:39 skrev David Smiley <
>> david.w.smi...@gmail.com
>>>>> :
>>>>>>> 
>>>>>>> A "rogue process on the machine" wouldn't happen if this build were
>>>>>>> converted to use docker/container technology, which is what Crave
>>>> uses.
>>>>>>> The Solr 9x CI build is converted, maybe I'll convert the "main" one
>>>> next
>>>>>>> week.
>>>>>>> 
>>>>>>> ~ David
>>>>>>> 
>>>>>>> 
>>>>>>> On Fri, Aug 25, 2023 at 12:21 AM Houston Putman >> 
>>>> wrote:
>>>>>>> 
>>>>>>>> It happens on the first test sometimes, so I think it may be a
>> rogue
>>>>>>>> process on the machine.
>>>>>>>> 
>>>>>>>> On Thu, Aug 24, 2023 at 11:27 PM David Smiley <
>>>> david.w.smi...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Many Bats tests seem to be failing on main branch; can't start
>> Solr:
>>>>>>>>>> Port 8983 is already being used by another process (pid: 31806)
>>>>>>>>> 
>>>>>>>>> https://ci-builds.apache.org/job/Solr/job/Solr-Check-main/
>>>>>>>>> 
>>>>>>>>> Eric, you've been looking at Bats lately; do you know about this?
>>>>>>>>> 
>>>>>>>>> ~ David
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> -- Forwarded message -
>>>>>>>>> From: Apache Jenkins Server 
>>>>>>>>> Date: Thu, Aug 24, 2023 at 7:35 PM
>>>>>>>>> Subject: [JENKINS] Solr » Solr-Check-main - Build # 7785 - Still
>>>&

Re: Sitemap to get latest reference manual to rank in Google/Bing?

[Jan Høydahl]

Yea, it's a pain.

Have you asked Infra whether mod_headers is activated and allowed from 
.htaccess?
Can we ask them to check error logs?

Jan

> 21. sep. 2023 kl. 18:08 skrev Houston Putman :
> 
> I've been trying to get this working for the last year. Basically our issue
> is that the htaccess files do not add the right X-Robots-Tag header for old
> ref guide pages.
> 
> https://github.com/apache/solr-site/blob/main/themes/solr/templates/htaccess.ref-guide-old#L1
> 
> This works locally, but in the actual Solr site, the headers are not
> returned. I have no idea why. Would love some help though, as I also hate
> seeing the old ref guide in the google results.
> 
> - Houston
> 
> On Thu, Sep 21, 2023 at 11:30 AM Walter Underwood 
> wrote:
> 
>> When I get web search results that include the Solr Reference Guide, I
>> often get older versions (6.6, 7.4) in the results. I would prefer to
>> always get the latest reference (
>> https://solr.apache.org/guide/solr/latest/index.html).
>> 
>> I think we can list the URLs for that in a sitemap.xml file with a higher
>> priority to suggest to the crawlers that these are the preferred pages.
>> 
>> I don’t see a sitemap.xml or sitemap.xml.gz at https://solr.apached.org <
>> https://solr.apached.org/>.
>> 
>> Should we prefer the latest manual? How do we build/deploy a sitemap? See:
>> https://www.sitemaps.org/
>> 
>> wunder
>> Walter Underwood
>> wun...@wunderwood.org
>> http://observer.wunderwood.org/  (my blog)
>> 
>> 


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

Re: [DISCUSS] Community Virtual Meetup, September 2023

[Jan Høydahl]

(1) or (2)

> 21. sep. 2023 kl. 14:35 skrev raghavan m :
> 
> Hello everyone,
> I am following up on this thread.
> We have approximately 9 more days in september 2023. What is a good time
> for all (or most) of us to meet?
> Please reply to this email by voting for one of the following options :
> 
> (1) 9 am Pacific time September 26, 2023
> (2) 9 am Pacific time September 27, 2023
> (3) 9 am Pacific time September 28, 2023
> (4) Other (please provide a suggestion of none of the above works)
> 
> *Voting ends on September 24 2023, 11:59 PM Pacific time*. My vote is for
> (1) 9 am Pacific time september 26, 2023
> 
> 
> thanks,
> *Raghavan*
> 
> 
> 
> 
> On Mon, Sep 11, 2023 at 11:03 AM Jason Gerlowski 
> wrote:
> 
>> Hey all,
>> 
>> It's time once again to start thinking ahead to our Virtual Meetup for
>> September.  As always, there's two main questions to answer in terms of
>> planning:
>> 
>> 1. Any volunteers to organize?  Organizer duties are pretty light and
>> are summarized here:
>> https://cwiki.apache.org/confluence/display/SOLR/Meeting+notes.
>> Volunteers get some discretion in terms of picking a meeting time/day
>> that works for them.  If there are no volunteers by mid-week or so, I'm
>> more than happy to set things up for this month.
>> 
>> 2. When should we meet?  It's already a good bit into September, so
>> we'll have to plan for the latter half of the month.  If you have any
>> opinions, please discuss.
>> 
>> Best,
>> 
>> Jason
>> 
>> -
>> To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org
>> For additional commands, e-mail: dev-h...@solr.apache.org
>> 
>> 


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