Re: Solr 9.4.1
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 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 <
> david.w.smi...@gmail.com
> >>> :
> >>>
> >>> 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 o
Re: Solr 9.4.1
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 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 <
>> david.w.smi...@gmail.com
> :
>
> 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
V2 API migration
While looking at our jett.xml, I noticed some rewrite rules including a "/v2/*" mapping. https://github.com/apache/solr/blob/b14505c19a76e833734dc0c75febc3601f633e37/solr/server/etc/jetty.xml#L142C35-L142C35 Is this considered a deprecated URL pattern for V2 which is now at "/api" if I recall correctly? If so, should we remove this in main (Solr 10)? A quick look in JIRA and I couldn't find the umbrella issue to try and answer this. I looked at https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation and it doesn't mention "/v2" or "/api". I searched the ref guide and see only one page referencing "/v2" -- task-management.adoc ~ David
Re: Unreferenced license file detection
Thanks Kevin. Maybe one of us will look into this further someday. ~ David On Wed, Dec 6, 2023 at 11:00 AM Kevin Risden wrote: > I think it came in as part of https://github.com/apache/solr/pull/1319 > > It has been this way for a while if you don't do a clean/full build. > > At first I thought we could remove the licenses, but they are still needed > just because they aren't referenced with whatever steps were run. > > Kevin Risden > > > On Tue, Dec 5, 2023 at 6:54 PM David Smiley wrote: > > > I often find that after running "gradle check", I get the following > warning > > at the very end, right after the slow tests are printed: > > > > WARNING: there were unreferenced files under license folder: > > - > > /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/HdrHistogram-LICENSE-PD.txt > > - /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/HdrHistogram-NOTICE.txt > > - > > /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/LatencyUtils-LICENSE-PD.txt > > - /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/LatencyUtils-NOTICE.txt > > - > > /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/SparseBitSet-LICENSE-ASL.txt > > - /Users/dsmiley/SFDCDev/solr_9x/solr/licenses/SparseBitSet-NOTICE.txt > > etc. > > > > Basically every *.txt file that exists in this folder, which is ~567 of > > them. Each is dumped to the console. Is this happening for others? Has > > anyone dug into why this is occurring? > > > > ~ David Smiley > > Apache Lucene/Solr Search Developer > > http://www.linkedin.com/in/davidwsmiley > > >
Re: V2 API migration
I think you will find that this is necessary to avoid /solr/api since all the code lives under the /solr web app (and has to go throuh SolrDispatchFilter). This sort of thing is why I would someday like to pick apart our uber-swiss-army-kinfe-filter (SolrDispatchFilter) and make a series of filters. Then the appropriate ones could be re-used around a servlet deployed next to /solr called /api... https://github.com/apache/solr/blob/b14505c19a76e833734dc0c75febc3601f633e37/solr/core/src/java/org/apache/solr/servlet/SolrDispatchFilter.java#L427 On Thu, Dec 7, 2023 at 10:06 PM David Smiley wrote: > While looking at our jett.xml, I noticed some rewrite rules including a > "/v2/*" mapping. > > https://github.com/apache/solr/blob/b14505c19a76e833734dc0c75febc3601f633e37/solr/server/etc/jetty.xml#L142C35-L142C35 > > Is this considered a deprecated URL pattern for V2 which is now at "/api" > if I recall correctly? If so, should we remove this in main (Solr 10)? A > quick look in JIRA and I couldn't find the umbrella issue to try and answer > this. I looked at > > https://cwiki.apache.org/confluence/display/SOLR/SIP-16%3A+Polish+and+Prepare+v2+APIs+for+v1+Deprecation > and it doesn't mention "/v2" or "/api". > > I searched the ref guide and see only one page referencing "/v2" -- > task-management.adoc > > ~ David > -- http://www.needhamsoftware.com (work) https://a.co/d/b2sZLD9 (my fantasy fiction book)
