Honestly, I would prefer to do away with it entirely. Dubious logic that
has been made to only output a warning will continue to be a part of the
code weight of our sprawling build. It will need to be maintained[1]. It
needs to do it's calculations on every check/precommit. I don't even want
to
Something like this could work?:
https://github.com/apache/solr/blob/eaaabbfa33456639613a7a6aecc37cd2d89e5dfa/gradle/globals.gradle#L168-L171
On Wed, Sep 6, 2023 at 5:26 PM David Smiley wrote:
>
> Is there a property or something used to detect that the build is being run
> in a CI or CI-like en
Hi,
Eric Pugh and I discussed this SIP the other day, as a stepping stone for
making cloud mode the default. Perhaps there is new energy for this two years
down the road?
We don't need to tackle the full dynamic scaling of ZK on day one.
Just adding a 'zookeeper' node-role so we could have tre
Is there a property or something used to detect that the build is being run
in a CI or CI-like env?
~ David
On Wed, Sep 6, 2023 at 4:50 PM Shawn Heisey wrote:
> On 9/6/23 13:21, Uwe Schindler wrote:
> > The idea is that jenkins runs it after the builds to figure out if
> > something changed in
It’s bit me plenty of times as well…. I like the idea of it not being enabled
by default.
> On Sep 6, 2023, at 4:49 PM, Shawn Heisey wrote:
>
> On 9/6/23 13:21, Uwe Schindler wrote:
>> The idea is that jenkins runs it after the builds to figure out if something
>> changed in the working copy
On 9/6/23 13:21, Uwe Schindler wrote:
The idea is that jenkins runs it after the builds to figure out if
something changed in the working copy. At ANT times this was implemented
exactly like this, we failed build on Jenkins when the working copy
changed. This was especially important before we
On 9/6/23 10:43, David Smiley wrote:
Our build, inherited from Lucene, contains a custom validation check
"checkWorkingCopyClean" which can be disabled with
"validation.git.failOnModified=false" in your gradle.properties. I always
set this; the concept of failOnModifies seems dubious to me; it a
+1 to flipping the default for 'failOnModified'.
On Wed, Sep 6, 2023 at 3:21 PM Uwe Schindler wrote:
>
> The idea is that jenkins runs it after the builds to figure out if
> something changed in the working copy. At ANT times this was implemented
> exactly like this, we failed build on Jenkins wh
The idea is that jenkins runs it after the builds to figure out if
something changed in the working copy. At ANT times this was implemented
exactly like this, we failed build on Jenkins when the working copy
changed. This was especially important before we used SecurityManager to
prevent tests
Our build, inherited from Lucene, contains a custom validation check
"checkWorkingCopyClean" which can be disabled with
"validation.git.failOnModified=false" in your gradle.properties. I always
set this; the concept of failOnModifies seems dubious to me; it annoys me.
Can an advocate of this setti
On 9/5/23 23:10, ramkrishna vasudevan wrote:
Clearly says this vulnerability is not affected in 7.4 to 8.11.1 but the
affected components are 'log4j-core-2.14.1.jar, log4j-core-2.16.0.jar'.
So does that mean that if we are with log4j-core-2.17.0.jar then this
vulnerability needs to be fixed? Or
I opened a pull request[1] that fixes the case reported. The issue was
subqueries with grouped fields like "field:(term1 term2 term3), only the
first term was skipped when generating the boost query with fields
specified in pf parameter.
Unfortunately, this pre-parsing (method splitIntoClauses())
12 matches
Mail list logo
