Hi Anshum,
I'm still working on unblocking SOLR-13350. Can we please push the date
back by a week, say 30 July?
Thanks and regards,
Ishan
On Wed, 24 Jul, 2024, 10:52 pm Anshum Gupta, wrote:
> As there are still a few dependency upgrade PRs open, I'll give it a few
> days and try and help review
https://issues.apache.org/jira/browse/SOLR-17379
: Date: Wed, 24 Jul 2024 11:50:55 -0700 (MST)
: From: Chris Hostetter
: To: dev@solr.apache.org
: Subject: Re: [JENKINS-EA] Solr-main-Linux (64bit/hotspot/jdk-23-ea+33) - Build
: # 19448 - Unstable!
:
:
: : the reason for this looks like i
I am not sure if this is 100% true,
Yes, JDK 9 changed the default provider to be the compat one, but Java
21 should already default to the CLDR. But maybe theres a difference in
parsing. Maybe in JDK21 based on this system property it accepts both
locales during parsing, but formats to string
: the reason for this looks like it is because of the legacy timezone database
: was removed and only CLDR was left over. It looks like this test uses a
Right, ok -- yes thank you for the links. Most of that info is over my
head, but my main take aways are...
0) jdk8 (and earlier) had a sing
Fair on the “make work” side of things. I know I skim through it at various
times, but we also have our Migration guide in the Ref Guide too….
I do look forward to a future with a simpler less confusing CHANGES.txt!
> On Jul 24, 2024, at 2:21 PM, David Smiley wrote:
>
> I like the idea yet I
I like the idea yet I also wonder if most folks simply won't care to
provide any input anyway, and then it becomes just yet another release
task. Also, I wouldn't want to recommend any process that would need
to be rethought if we streamline CHANGES.txt management (e.g. we spoke
of using separate
I think it's a case-by-case matter. I don't think there's something
wrong with the Executor.submit method generally.
Looking at callers of CoreContainer.runAsync, I didn't find the core
reload use-case you speak of. I did find DistribFileStore.delete and
looked closer. I do see there's an issu
As there are still a few dependency upgrade PRs open, I'll give it a few
days and try and help review + merge those in before starting the process
later this week.
On Wed, Jul 17, 2024 at 10:04 AM Eric Pugh
wrote:
> I would like to see the back port of solr cli changes make it…
> https://github.
I was thinking that as part of our release process we should have a “review
CHANGES.txt” step? I don’t know if that is already in there, but it might be
a good step for us as a community to have a single point in time to review that
to make sure it’s clear and accurate….
We have lots of fol
Hi,
the reason for this looks like it is because of the legacy timezone
database was removed and only CLDR was left over. It looks like this
test uses a timezone identifier which is no longer a supported label. It
looks like the AKST has a special test. See also
https://openjdk.org/jeps/252 <
Hi Andrey,
It's hard to say how much this affects users in practice, but I agree
that it sounds concerning. Definitely worth auditing our existing
uses of 'submit' IMO.
Some cases might be tough to handle. If an API call is intentionally
queueing up an operation to run asynchronously and then r
Neat, thanks David!
On Wed, Jul 17, 2024 at 2:05 PM David Smiley wrote:
>
> Our JIRA issues, according to .asf.yaml configuration, *should have*
> been getting a label "pull-request-available". This wasn't working
> because an ASF bot needed committer permissions in JIRA, in accordance
> with AS
12 matches
Mail list logo
