40 years is enough. OK, it's only been 39 1/2 years. Dear Lord, has it really
been that long? Programming's been fun, I've gotten to solve puzzles every day.
The art and science of programming has changed over that time. Let me tell you
about the joys of debugging with a Z80 stack emulator that
It’ll really be nice to not have to switch between gradle and ant when
verifying changes ;).
Not to mention that we’ll be able to stop having to deal with Java 8
.vs. Java 11.
I don’t expect this to be a short release, so yeah, I think it’s time to
start the process.
Erick
> On Dec 28, 2020,
I like braces too. For this kind of mass edit though, I’m not about to
start changing anything that isn’t already touched by the formatter,
that’s a never-ending rat-hole and rife with possibilities to screw
up.
What that means in this case is that the formatter changes
if (something)
blah
I took a quick look at lucene/queries just to get my feet wet. Before working
on it seriously. I did a fast scan through about half of the changes and have
only one question.
The formatter tightens up non-block comments, i.e.
if (this == obj)
return true;
becomes
if (this == obj) return
Still noisy, waiting for the reference impl to untangle.
Short form:
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0 had 136 failures
Week: 1 had 185 failures
Week: 2 had 210 failures
Week: 3 had 112 failures
Failures in Hoss' reports in
Anshum:
I know I’ve been recommending something like this to clients for a while,
do you think a call to the community for people who’ve already put
something in the middle might net us some good info on the lurking
gremlins? Mind you “recommend” hasn’t actually involved me _doing_ it
so I don’t
Also FWIW, the Gradle “check” task does it all and is preferred rather than
“gradlew precommit” according to Dawid….
> On Dec 5, 2020, at 1:43 PM, Mikhail Khludnev wrote:
>
> Uwe, thank you for your response. I remember that yetus run tests via JIRA's
> precommit before, but github checks
Welcome Houston!
> On Dec 2, 2020, at 1:34 AM, Shalin Shekhar Mangar
> wrote:
>
> Congratulations Houston!
>
> On Wed, Dec 2, 2020 at 2:50 AM Mike Drob wrote:
> I am pleased to announce that Houston Putman has accepted the PMC's
> invitation to join.
>
> Congratulations and welcome,
un, 29 Nov 2020, 22:07 Erick Erickson, wrote:
> How far can we get in replacing DIH with streams? I can write a simple DIH
> implementation by wrapping a jdbc stream in an update stream for instance (I
> think).
>
> It falls down with some of the more complex DIH constructs, but
How far can we get in replacing DIH with streams? I can write a simple DIH
implementation by wrapping a jdbc stream in an update stream for instance (I
think).
It falls down with some of the more complex DIH constructs, but the simple
“pull data from the DB and insert it into Solr” case seems
Unfortunately, the reference impl is creating quite a bit of noise in Hoss’
rollups. That said, I have a mail filter for test failures that puts the
reference impl tests in a different mail folder and my sense is that the
regular branch is getting an increasing number of failures.
If I have
So yet another iteration on the users list of going from X to X+2 got me to
thinking (dangerous I know). I wanted to run this by folks to see if it’s worth
a JIRA.
It _seems_ reasonable from a user’s perspective to create an index with, say,
6x, then upgrade to 7x and reindex all documents
Welcome Julie!
> On Nov 18, 2020, at 1:21 PM, Alexandre Rafalovitch wrote:
>
> Juliet from the house of Elasticsearch meets a interesting, relevancy-aware
> committer from the house of Solr.
>
> Such a romantic beginning. Not sure I want to know the end of that heroine's
> journey.
>
> :-)
Well, Solr has grown “organically” so some things just _are_, like sunrises and
plagues ;)
On a serious note, AFAIC rearrange as you see fit. I wonder how much of this is
left over from the war days? Anything that’s lasted through all the
transformations Solr has is bound to need cleaning up
Still seeing quite a bit of noise due to the reference impl. That said, we do
have a reproducible error for TestRandomDVFaceting both 8x and master, see
SOLR-14990.
Meanwhile, here’s the report for this week.
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0
Tlogs are essential for peer sync, so just because the local commit
was successful doesn’t mean the tlog can be safely removed in
SolrCloud because some other replica can get the docs replayed
from this replica’s tlog and not have to sync the entire index.
They’re also essential to replaying the
Not much change this week, still getting considerable noise from the reference
impl.
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0 had 110 failures
Week: 1 had 150 failures
Week: 2 had 174 failures
Week: 3 had 142 failures
Failures in
I’m always reluctant to change something like this for a point release.
I’ve been supposing that we’d release Solr 9 for a while, I always thought
that moving to Java 11 would be a driver for the 9.0 release but I wasn’t
correct in that.
That expectation has been complicated by the whole
ing that needless checkout, this also means you needn't create a
> local branch of it only to then need to delete it later. Simpler.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Sun, Oct 25, 2020 at 11:43
Still working through the failures on the reference impl, so AFAIK, the tests
failing large percentages of the time are on that branch.
Processing file (History bit 3): HOSS-2020-10-26.csv
Processing file (History bit 2): HOSS-2020-10-19.csv
Processing file (History bit 1): HOSS-2020-10-12.csv
We have two 8x branches,
origin/branch_8_x
origin/branch_8x
Can someone remove/rename branch_8_x? I’ve managed to completely screw up my
fork when trying to delete branches, so I’m not feeling confident when it comes
to deleting branches on master...
I played around a bit in my repo and this sequence seems to do what I want now
that Dawid suggested tagging before removing: tag a branch then remove it from
the drop-down.
We have a branch jira/SOLR-13452_gradle_2 for example:
// First track the branch
git checkout --track
I found myself yet again trying to explain on the user’s list that if you
change your schema, you almost cvertainly have to delete your index and start
over. Then a lightbulb went off and I said “Wow! Hasn’t someone written this up
somewhere?” The ref guide page “Reindexing.adoc” seems like the
+1, this is what I’ve been doing for a while, and it gives me a warm fuzzy
feeling to know that no mater what, until the final merge into the master repo
I can’t inadvertently screw up said master repo….
> On Oct 19, 2020, at 1:53 PM, David Smiley wrote:
>
> +100 to Uwe's total message -- my
The BadApple report remains skewed as the results include the reference impl so
this is mostly in case people are curious….
I expect next week to see an uptick in the number of tests that have failed
each of the last 4 weeks, that’ll be when the reference-impl parts of the
report kick in.
Mostly for historical context for a while, It includes the reference impl so
the stats will be skewed from now until we integrate it all.
Short form:
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0 had 142 failures
Week: 1 had 153 failures
Week: 2 had
igin archived/gradle-master
> git push :gradle-master
>
> Dawid
>
> On Sat, Oct 10, 2020 at 4:28 PM Erick Erickson
> wrote:
> Do we have any convention that would prevent removing branches that are
> associated with JIRAs that have been fixed?
>
> The
Do we have any convention that would prevent removing branches that are
associated with JIRAs that have been fixed?
There are something like 8 gradle branches that are leftovers from the initial
attempts to move to Gradle, I’ll remove them in a day or two absent objections.
Several issues:
1> I think Hoss’ rollups pull in those errors. In that case, the BadApple
report is essentially useless. I’ll keep sending it out since it only takes a
few minutes to create and send. I’m not complaining about this, I expected it.
I think it’s worthwhile to keep sending out to
We’re kind of in limbo at this point. Mark, Ishan and Noble are pushing (along
with others) to make a much faster test suite, the “reference_impl”. Once
that’s done, and assuming it live up to expectations, it should then be more
reasonable to run all the test for each PR. We’ll have to wait a
I suppose failures would be returned to the client one the async response?
How would one keep the tlog from growing forever if the actual indexing
took a long time?
I'm guessing that this would be optional..
On Thu, Oct 8, 2020, 11:14 Ishan Chattopadhyaya
wrote:
> Can there be a situation
Gone.
> On Oct 4, 2020, at 3:39 PM, Erick Erickson wrote:
>
> The "How to contribute" page here:
>
> https://cwiki.apache.org/confluence/display/solr/HowToContribute
>
> contains links to two obsolete pages for configuring Eclipse and IntelliJ:
>
> https:
We have a 12 tests failing 100% of the time over the last 24 hours. I urge
folks to take a look at
http://fucit.org/solr-jenkins-reports/failure-report.html and see if anything
rings some bells.
Short form:
Raw fail count by week totals, most recent week first (corresponds to bits):
Week: 0
Uwe:
I think it’s reference_impl_dev...
> On Oct 4, 2020, at 6:00 PM, Uwe Schindler wrote:
>
> Hi,
> I enabled the „gradlew check” runs on ASF Jenkins and Policeman Jenkins
> (Linux, Windows, MacOS).
>
> I used branch (“reference_impl”). Is this correct, because it’s about a month
> old?
>
The "How to contribute" page here:
https://cwiki.apache.org/confluence/display/solr/HowToContribute
contains links to two obsolete pages for configuring Eclipse and IntelliJ:
https://cwiki.apache.org/confluence/display/solr/HowToConfigureEclipse
I put these two e-mails on the JIRA for posterity...
> On Oct 3, 2020, at 2:59 PM, David Smiley wrote:
>
> Definitely makes sense to me -- those 3 phases of shutdown. That is what I
> think CoreContainer.shutdown() should itself do. Flag that shutdown has been
> requested, then wait
I agree with Ilan, let’s call it something else. “super special the future of
Solr” maybe ;) “Marks baby”. “batshit crazy better Solr”.
What I’d like to avoid is confusion about where to fix things. Say I’m working
on an issue. Should I fix it in this impl then backport to 9.0 and 8x? Do like
See: SOLR-14888
> On Sep 28, 2020, at 2:08 PM, Chris Hostetter wrote:
>
>
> : Question: What is the replacement for "cd solr ; ant dist server" usage?
>
> AFAICT the the most straightwoard "adaptation" of...
>
> $ cd solr && ant server && bin/solr -e SOMETHING
>
> ...seems to be (using
For me, there’s a sharp distinction between changing a dependency in a point
release just because there’s a new version, and changing the dependency because
there’s a bug in it. That said, if someone can use 8.6.3, what’s stopping them
from going to 8.7 when it’e released? Would it make more
Christine:
Quite possibly you had some remnants of an ant build hanging around from
bin/solr. If I start with a fresh clone and try to start from bin/solr I
usually get no class def errors.
git clean -dxf if my friend to be absolutely sure that I have nothing laying
around when switching back
>
> On Tue, Sep 22, 2020 at 11:11 AM Erick Erickson
> wrote:
> We’re probably talking about different things. I have access to all the
> folders, I think our gradle build has changed recently and we stopped
> printing out a message for where the results of a specific ta
sing-gradle
>
> m-
>
> From: Erick Erickson
> Sent: Tuesday, September 22, 2020 10:48 AM
> To: dev@lucene.apache.org
> Subject: Gradle build, where's the output?
>
> The Gradle build used to print out where to find the artifacts for the
> “assemble” and “dev” tasks, but t
The Gradle build used to print out where to find the artifacts for the
“assemble” and “dev” tasks, but that disappeared sometime. Is this intentional?
It really helped me the first time I tried to run Solr after building with
Gradle…
Currently, “gradlew tasks” does print the location of the
and it passed 100 times. I hate
these...
> On Sep 19, 2020, at 9:24 PM, Noble Paul wrote:
>
> I beated this test for 100 repetitions . No failures. it's frustrating
>
> On Sun, Sep 20, 2020 at 12:33 AM Erick Erickson
> wrote:
>>
>> Yeah, I can't seem to get it to fai
Can’t seem to get that to fail on master. Note the reproducible bit was 8x.
> On Sep 19, 2020, at 5:13 PM, Erick Erickson wrote:
>
> ant test -Dtestcase=TestPackages -Dtests.seed=C29471044D369FD3
> -Dtests.multiplier=2 -Dtests.slow=true -Dtests.locale=et-EE
> -Dtests.
ed to
>> >> >> > https://issues.apache.org/jira/browse/SOLR-14151
>> >>
>> >> >> >
>> >>
>> >> >> > • FAILED: org.apache.solr.pkg.TestPackages.classMethod
>> >>
>> >> >> >
> I'm wondering if we should just disable the
> TestPackages@testSchemaPlugins() or revert the changes wholesale
>
> On Sat, Sep 19, 2020 at 10:44 PM Erick Erickson
> wrote:
> >
> > I have to take it back a little. Hoss’ rollups show these tests failing
> 100% of t
I have to take it back a little. Hoss’ rollups show these tests failing 100% of
the time, but they pass on my machine locally at least some of the time…. IDK
quite why there’s a difference.
Noble:
Let me know if I can help, I can at least beast any fix.
Erick
> On Sep 18, 2020, at 2:13 PM,
time.
> >
> > On Fri, Sep 18, 2020 at 8:48 AM Atri Sharma wrote:
> >>
> >> When I said temporary, I meant 3-4 hours. Definitely not more than that.
> >>
> >> IMO we should just roll back offending commits if they are easily
> >> identifia
stability is to be introduced deliberately, it should be
> published on the list. If it’s inadvertently added, we either fix it within
> an hour or so or revert the offending commit.
>
> On Fri, 18 Sep 2020 at 20:26, Erick Erickson wrote:
> http://fucit.org/solr-jenkins-rep
http://fucit.org/solr-jenkins-reports/failure-report.html
HdfsAutoAddReplicasTest failing 100% of the time.
TestPackages.classMethod failing 100% of the time
3-4 AutoAddReplicas tests failing 98% of the time.
Is anyone looking at these? I realize the code base is changing a lot, and some
Rats, fat fingers and the stupid large touchpad on MBPs, which I dislike
intensely. Anyway:
I was once again explaining that if you upgrade X->X+1->X+2 you need to reindex
from scratch sometime at least with X+1 before upgrading to X+2, even if you
re-index all documents with X+1 into the
I was once again explaining that if you upgrade X->X+1->X+2 you need to reindex
from scratch sometime at least with X+1, even if you re-index all documents
when it occurred to me to wonder whether a new merge policy could make that
process easier.
So
All:
The test framework, and perhaps all of Solr has a disorderly shutdown process.
I’ve seen at least one case where this is responsible for “bogus” test
failures, bogus in the sense that due to race conditions the test failed with
unreleased objects. The short form is that our test harness
ne/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Tue, Aug 18, 2020 at 7:56 PM Erick Erickson
> wrote:
> It _finally_ occurred to me to ask why we have the restriction that the
> destination of a copyField must have stored=false. I understand what
bq. Yes it's an obvious thing and may be a tedious explanation for experienced
Java developers...
The tradeoff, though, is that the experienced Java developers then don’t have
to answer as many questions on the dev list from people new to the ecosystem.
I’ll gladly trade some wordiness in a
re: txt files .vs. the Wiki. In the end, I came down on keeping text files
pure. I’ve come to view it as something of a hierarchy, the less the plain text
files reference this web thingy the better. So I’ll change the CWiki page to
mention the plain text files and leave it at that…
I did make
o that changes can be updated, etc. I know,
> I'm old-fashioned. Don't even use md or anything like that. But stuff in
> plain text is hard to break.
>
> D.
>
> On Fri, Sep 4, 2020 at 3:18 PM Erick Erickson wrote:
> re: “gradle newbie”. Can we reference:
> https://cwiki.a
+100
> On Sep 4, 2020, at 1:11 AM, David Smiley wrote:
>
> Thank you, thank you, thank you!
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Wed, Aug 26, 2020 at 3:42 PM Alexandre Rafalovitch
> wrote:
> Dear all,
>
> Based on the
re: “gradle newbie”. Can we reference:
https://cwiki.apache.org/confluence/display/SOLR/Building+Solr+with+Gradle?
I think it makes sense to put a reference to that in the gradle help file
rather than try to reproduce that info in the text and then have to keep them
coordinated.
I’m thinking
Let’s discuss how we can accommodate Drupal and Solarium (and others) with a
minimal amount of pain to those projects rather than insist on keeping things
the way they are. We’ve been recommending against using
ExtractingRequestHandler in production for years and apparently that advice has
API changes
> to revert now, there is no node to respond to those requests. Hopefully you
> were using some sort of stable storage because all ephemeral is gone.
> Bringing back that cluster is going to be a PITA. I have seen similar things
> happen.
>
>
> On Thu, Se
bq. Isn’t solr.xml is a way to hardcode config in a more flexible way that a
Java class?
Yes, and the problem word here is “flexible”. For a single-node system that
flexibility is desirable. Flexibility comes at the cost of complexity,
especially in the SolrCloud case. In this case, not so
>> What I'm really looking for (and currently my understanding is that
>>>>>>>>>> solr.xml is the only option) is a cluster config a Solr dev can set
>>>>>>>>>> as a default when introducing a new feature for example, so that the
>&g
istro/code to
> ensure that these warnings don't come.
>
> On Thu, Sep 3, 2020, 4:58 AM Erick Erickson wrote:
> Oh bother. Somehow I thought I’d looked and only a handful of tests reported
> this.
>
> So I looked again and I _wish_ I was able to blame drugs cause you’re right,
g 31, 2020, at 1:29 PM, Chris Hostetter
> wrote:
> : >
> : >
> : > Some tests "create" a new solr home dir and copy config files there, but
> : > you'll see this type of WARN logging for any test that just uses the test
> : > configs "in pla
Is this another thing we really should remove? What use-cases are served by
this that are _not_ served by updating SV numeric values?
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail:
Excellent, I’ve put it in my notes… you get a lot of entries there… Thanks!
> On Aug 31, 2020, at 2:59 PM, Dawid Weiss wrote:
>
>> Is there an easy way to insure that versions.props only has necessary
>> dependencies listed? Ideally it would be just a top-level command.
>
> If a dependency
'll see this type of WARN logging for any test that just uses the test
> configs "in place" because of how the code is designed to _try_ and create
> a userfiles directory in the solr home if it's writable.
>
>
> : Date: Sat, 29 Aug 2020 09:25:17 -0400
> : From: Erick Eric
Is there an easy way to insure that versions.props only has necessary
dependencies listed? Ideally it would be just a top-level command.
I got to wondering about this thinking about all the code that’s being removed
from core and was wondering how we’d be sure that any dependencies that were
x. That's one of the main advantages of the Test sandbox:
> No write access anywhere outside the test, see policy file.
>
> Uwe
>
> -
> Uwe Schindler
> Achterdiek 19, D-28357 Bremen
> https://www.thetaphi.de
> eMail: u...@thetaphi.de
>
>> -Original
These exceptions are handled in the code and don’t affect running tests, but
they can be a distraction when trying to figure out what’s causing a failure.
When CoreContainer is being initialized, these two paths get “Permission
Denied” errors since they try to create directories/files.
Just pushed it again, we’ll see if things go wonky this time.
There are still probably some cleanup tasks, but this is most of it. I’m also
updating Confluence.
Any remaining cleanup should be listed under LUCENE-9475, I’ll close
LUCENE-9433 momentarily and transfer any of the items listed
Solr.xml can also exist on Zookeeper, it doesn’t _have_ to exist locally. You
do have to restart to have any changes take effect.
Long ago in a Solr far away solr.xml was where all the cores were defined. This
was before “core discovery” was put in. Since solr.xml had to be there anyway
and
CDCR does work, kind of. But it requires extensive care and feeding and, as
Ishan says, it’s _very_ easy to shoot yourself in the foot. Or run out of disk
space. Or get to a state where you have to replicate the index. And
“bi-directional” means you can go from A -> B _or_ B -> A, but you can’t
IMO, it’s super-awkward to preserve something for 9.0 then remove it for 9.1. I
understand the tendency to say “deprecating it in 8.7 then removing it in the
next release is too fast”, but that strikes me as even worse than taking it out
of 9.0.
> On Aug 27, 2020, at 6:35 PM, David Smiley
Did I understand correctly that I can remove the entire dev-tools/maven
directory for this attempt?
Absent objections, I’ll push this Friday before 10:00 AM, UTC-5.
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Alexandre:
"./gradlew check” is all you need. That does what “ant precommit test” would do.
Dawid put some pretty great help in, "./gradlew help” shows the top-level help
tasks, and “./gradlew helpAnt” gives some very useful gradle versions of some
of the familiar Ant targets you’re used to.
There are a number of tests failing 100% of the time. I should be able to push
a fix momentarily, it’s an NPE that seems straightforward to cure.
In the interests of getting this out of people’s way ASAP, I’m going to push
the fix after getting a few tests that have been failing to run, _then_
We have some pretty frequent failures, see:
http://fucit.org/solr-jenkins-reports/failure-report.html
I’m pretty sure LBSolrClientTest has been addressed. I’m looking at what commit
caused TestConfigOverlay to start failing…
This can be a little hard to interpret since it includes tests that
Please ignore any Jenkins build failures starting, probably, tomorrow. We’re
trying to transition to Gradle for trunk, and it’ll probably have some
“learning experiences” along the way.
Once that’s in reasonable shape, I’ll push LUCENE-9433 again which will remove
all the Ant files.
I just
Welcome Atri!
> On Aug 21, 2020, at 9:52 AM, Tommaso Teofili
> wrote:
>
> Welcome Atri!
>
> Tommaso
>
> On Fri, 21 Aug 2020 at 11:47, Namgyu Kim wrote:
> Congratulations and welcome, Atri! :D
>
> On Fri, Aug 21, 2020 at 5:11 PM Noble Paul wrote:
> Welcome Atri!
>
> On Fri, Aug 21, 2020
ZkMaintenanceUtils has the basic file manipulations between Zk and “someplace
else”,
although it’s pretty much file based. Does that have any bearing on the problem?
> On Aug 19, 2020, at 2:49 AM, Noble Paul wrote:
>
> So, it's not very different from directly reading a file from ZK?
>
> what
It _finally_ occurred to me to ask why we have the restriction that the
destination of a copyField must have stored=false. I understand what currently
happens when that’s the case, you get repeats.
What I wondered is why we can’t detect that a field is the destination of a
copyField and _not_
Failures in Hoss' reports for the last 4 rollups.
There were 242 unannotated tests that failed in Hoss' rollups. Ordered by the
date I downloaded the rollup file, newest->oldest. See above for the dates the
files were collected
These tests were NOT BadApple'd or AwaitsFix'd
Failures
"In Solr.cmd, when using SSL, there is a check to verify what version of java
solr is running with. If this version of Java is greater or equal java 9 it
will load the jetty https module while for java 8 it will use https8."
Could someone with a Windows machine give this a whirl? To fully test
I often use “The best Lucene / Solr beasting script in the world. TM.”
(https://gist.github.com/markrmiller/dbdb792216dc98b018ad).
The it struck me out of the blue (well actually since I’ve been beasting for
SOLR-14750 a lot), “Gosh, when we remove Ant from trunk I won’t be able to use
the
Does it rotate? I.e. is there a new one after every commit?
If you have steps to repro I can take a look. I’ve also been fooled by
having ZK_HOST defined when I _think_ I’m running standalone
that’s caused some head-scratching…
Erick
> On Aug 14, 2020, at 4:41 AM, Dawid Weiss wrote:
>
>
se","org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest","test","33.3","3","1"
HOSS-2019-05-06.csv:"false","org.apache.solr.cloud.SharedFSAutoReplicaFailoverTest","test","100","1"
for 9.0. The shared file system notion
> isn't well supported in SolrCloud, I think.
>
> ~ David Smiley
> Apache Lucene/Solr Search Developer
> http://www.linkedin.com/in/davidwsmiley
>
>
> On Mon, Aug 3, 2020 at 7:26 AM Erick Erickson wrote:
"Perhaps the document has an indexed string field (solr.StrField) which is too
large solr.field”
string based fields have a limit of 32K. If you mean the field to be
searchable, a 32K field _as a single term_ makes little sense.
You probably want to change the fieldType to a text-based field
ncurrentRequests from failing and should
> hopefully stop testSlotBorrowing as well. If testSlotBorrowing
> continues to fail, I will have to rethink the test.
>
> On Mon, Aug 10, 2020 at 8:17 PM Erick Erickson
> wrote:
>>
>> We’re backsliding some. I encourage peop
on and others think it's somewhat beneficial
> that solr has the "Luke plugin", I'd be happy to add it my todo list (or it'd
> be perfectly fit for "newdevs", I think).
>
> Tomoko
>
>
> 2020年8月10日(月) 4:39 Erick Erickson :
> Tomoko:
>
> Indeed, t
ed since,
> so please don't annotate it.
>
> On Mon, Aug 10, 2020 at 7:47 AM Erick Erickson
> wrote:
> We’re backsliding some. I encourage people to look at:
> http://fucit.org/solr-jenkins-reports/failure-report.html, we have a number
> of ill-behaved tests,
We’re backsliding some. I encourage people to look at:
http://fucit.org/solr-jenkins-reports/failure-report.html, we have a number of
ill-behaved tests, particularly TestRequestRateLimiter,
TestBulkSchemaConcurrent, TestConfig, SchemaApiFailureTest and
TestIndexingSequenceNumbers…
Raw fail
Could someone with a Windows machine try the patch at SOLR-14714? I looked it
over and LGTM with one nit: I would move the following up to before they’re
actually used:
set JAVA_MAJOR_VERSION=0
set JAVA_VERSION_INFO=
set JAVA_BUILD=0
I don’t think it matters functionally, just a style thing.
Tomoko:
Indeed, this is what is behind my question about whether it should be a
package for Solr rather than something in the standard distro. The more I think
about this, it’s hard to justify it being part of the standard distro rather
than a package given that some people find it _very_
ce the former is about making a distribution package and the
> latter is about providing a helper for developers.
>
> Tomoko
>
>
> 2020年8月7日(金) 22:28 Erick Erickson :
> All:
>
> I’m not sure this really makes sense at this point. I’ve outlined the current
> state on
All:
I’m not sure this really makes sense at this point. I’ve outlined the current
state on the JIRA. The sort form is:
1> there’s some work currently being done to make the stand-alone Luke app work
in the Gradle world.
2> Currently, invoking it is an ant task, it’s not build/distributed.
nda makes sense somehow.
>
> Thank you!
>
> On Thu, Aug 6, 2020 at 6:40 PM Erick Erickson wrote:
> Dat:
>
> That’s a confusingly-named variable, surely needs a comment. Remembering from
> a long time ago trying to work with PreferredLeader, the problem is that you
&g
1 - 100 of 7265 matches
Mail list logo
