Or Slow should be disabled by default? One or the other.
In the Lucene issue you linked to
https://issues.apache.org/jira/browse/LUCENE-10532 Tomoko did a comparison
table of tests running with & without Slow, and across threads. If we
assume at least 4 workers, what are the results? I wouldn't
Ok, another correction, tests.slow is enabled by default, so if they're
already running most of the time then it's pretty "safe" to just axe the
annotations.
On Thu, Jul 21, 2022 at 8:19 PM Mike Drob wrote:
> Hmm... correction here - the failing Slow tests also happen to be
> AwaitsFix tests so
Hmm... correction here - the failing Slow tests also happen to be AwaitsFix
tests so they were broken anyway. I wonder why my gradle command decided to
include them.
On Thu, Jul 21, 2022 at 8:14 PM Mike Drob wrote:
> While I would agree with you in principle, I don't think the Slow tests
> are c
While I would agree with you in principle, I don't think the Slow tests are
currently running anywhere right now. I tried running them locally and
immediately got three reproducible failures.
Uwe's jenkins doesn't run the slow tests and I don't see any jobs on ASF
Jenkins that seem to do that eith
Thanks for spearheading this!
Your definition of "slow" seems fine. We can change it later. As long as
the build publishes tests with a runtime exceeding this threshold, we can
maintain this easily.
I think keeping @Slow makes sense so that we can identify these tests
as-such to avoid running t
Howdy devs,
I stumbled onto https://issues.apache.org/jira/browse/SOLR-16304 while
trying to upgrade our Lucene dependency and it's motivated me to take a
little bit of a look at our tests. I know that there are dragons here and
I'm under no illusions that I can fix everything, but I feel like a
t
