Robert Muir
Robert Muir
there's also no harm in tracking relevance, if its not difficult to do. I just think we should stay "strict"
I think the optimization may be similar to the one done in AutomatonTermsEnum? https://github.com/apache/lucene/blob/main/lucene/core/src/java/org/apache/lucene/index/AutomatonTermsEnum.java#L149-L153 When "ping-ponging" the term dictionary against the automaton, it tracks `visited` bitset and looks for such...
If you want slower but better compression, maybe consider using `BEST_COMPRESSION` instead of `BEST_SPEED`? That is the purpose of the option...
gradle should fail with a clear error though if the version is not supported.
yeah, i think for the smoketester we should just test only java versions supported by gradle? Since this is different than just running tests but trying to check that much...
It was a thing we previously did with `ant` and `jenkins`, there was a "nightly-smoketest" job at least to try to keep the smoketester working.
From what I remember, at a basic level, the previous "nightly-smoketest" job would create a release, then run the smoketester on the release. Stuff such as GPG checks might have...
You could even disable the running of tests (which might be the slowest part) for such a github workflow job. The real value is in the release checks and the...
well, i think part of what makes changing the smoketester scary is that there's no validation of it in any PR I make. So if the github action would "verify...
ok, i'm gonna look at trying to tackle the smoketester.py (for main branch first!) this evening.