Re: Solr 9.4.1
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 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 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 <
> jan@cominvent.com>
> 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
> >>>
[DISCUSS] Standardizing sysprop naming
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
[REMINDER] CFP Open for Search Track at Community Over Code EU (Formerly ApacheCon)
Hello everyone, The CFP for *Community Over Code Europe* (Formerly ApacheCon) is open until 12 Jan 2024 and wanted to remind you that we have a *Search track*. Please submit your talks and share your stories here: https://sessionize.com/coceu-2024/ A bit about the Search track: Search is at the core of almost all data driven systems. Apache Lucene and Solr have been the leaders in defining this space for over a decade. Since their incubation, they have grown to redefine 'search' from being just full text search to also incorporating spatial search, analytics, and a lot more. For this track we welcome all talks that are related to search, even those not related to Lucene and Solr. Your submission may involve talking about information retrieval, analytics, the Lucene and Solr community, Machine Learning in search, deployment and management of large scale search systems, etc. Like always, what we are really interested in is your search story - what worked, what didn't, and what you are trying to build. The event will take place in *Bratislava, Slovakia* from* 3-5 Jun 2024.* Please feel free to reach out if you have any questions or ideas! Hope to see you all there. -- Anshum Gupta
Re: Solr 9.4.1
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 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 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 <
>> jan@cominvent.com>
>> 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
PR labeling
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
