That test rarely fails - hence warrants an investigation IMO On Wed, 22 Sep 2021, 03:01 Timothy Potter, <[email protected]> wrote:
> Just an update here ... I'm still trying to get an RC built but the > test suite continues to fail with flaky tests, this past run it was: > org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming, > which doesn't look like it fails all that much, see: > > http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.util.TestCircuitBreaker.testResponseWithCBTiming > > > On Mon, Sep 20, 2021 at 3:14 PM Mike Drob <[email protected]> wrote: > > > > That was a bad backport from main, and I was mainly paying attention to > the main jenkins tests. Apologies about that oversight. Please see PR > https://github.com/apache/lucene-solr/pull/2578 > > > > On Mon, Sep 20, 2021 at 2:21 PM Uwe Schindler <[email protected]> wrote: > >> > >> Hi, > >> > >> This test also fails on Jenkins all the time. In all branches and on > all platforms. All the time, it's definitely a regression. > >> > >> Uwe > >> > >> Am 20. September 2021 19:13:56 UTC schrieb Timothy Potter < > [email protected]>: > >>> > >>> Started building the RC1 again today and the smoke tester failed. The > >>> culprit was: org.apache.solr.search.TestFiltering.testRandomFiltering > >>> > >>> Re-ran that test from the RC checkout and it failed again: > >>> > >>> [junit4] 2> 5490 ERROR > >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [ > >>> ] o.a.s.SolrTestCaseJ4 REQUEST FAILED: > >>> > facet.query=*:*&facet.query={!key%3DmultiSelect+ex%3Dt}*:*&facet.query={!key%3DfacetQuery+cache%3Dfalse}+val_i:2+val_i:4&q={!+cost%3D7+tag%3Dt}-_query_:"{!frange+v%3Dval_i+l%3D2+u%3D5}"&facet=true&wt=xml > >>> [junit4] 2> 5491 INFO > >>> (TEST-TestFiltering.testRandomFiltering-seed#[9A85A1D74D8AACF9]) [ > >>> ] o.a.s.SolrTestCaseJ4 ###Ending testRandomFiltering > >>> [junit4] 2> NOTE: reproduce with: ant test > >>> -Dtestcase=TestFiltering -Dtests.method=testRandomFiltering > >>> -Dtests.seed=9A85A1D74D8AACF9 -Dtests.slow=true -Dtests.badapples=true > >>> -Dtests.locale=mgh -Dtests.timezone=Iceland -Dtests.asserts=true > >>> -Dtests.file.encoding=US-ASCII > >>> [junit4] FAILURE 0.82s | TestFiltering.testRandomFiltering <<< > >>> [junit4] > Throwable #1: java.lang.AssertionError: should have > unwrapped > >>> [junit4] > at > >>> > __randomizedtesting.SeedInfo.seed([9A85A1D74D8AACF9:85E60212A8ADECF0]:0) > >>> [junit4] > at > >>> > org.apache.solr.search.SolrIndexSearcher.getAndCacheDocSet(SolrIndexSearcher.java:862) > >>> [junit4] > at > >>> > org.apache.solr.search.SolrIndexSearcher.getDocSet(SolrIndexSearcher.java:824) > >>> [junit4] > at > >>> > org.apache.solr.search.SolrIndexSearcher.getDocListC(SolrIndexSearcher.java:1367) > >>> [junit4] > at > >>> > org.apache.solr.search.SolrIndexSearcher.search(SolrIndexSearcher.java:596) > >>> [junit4] > at > >>> > org.apache.solr.handler.component.QueryComponent.doProcessUngroupedSearch(QueryComponent.java:1511) > >>> [junit4] > at > >>> > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:390) > >>> [junit4] > at > >>> > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:368) > >>> [junit4] > at > >>> > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:216) > >>> [junit4] > at > org.apache.solr.core.SolrCore.execute(SolrCore.java:2637) > >>> > >>> Looking at the stats for this test, it seems like it started failing > >>> more consistently over the past week or so: > >>> > http://fucit.org/solr-jenkins-reports/history-trend-of-recent-failures.html#series/org.apache.solr.search.TestFiltering.testRandomFiltering > >>> > >>> I beasted it and 3/10 failed: > >>> > >>> [beaster] Tests with failures [seed: A5F8AAEF7994FE2B] (first 3 out > of 10): > >>> [beaster] - > org.apache.solr.search.TestFiltering.testRandomFiltering > >>> [beaster] - > org.apache.solr.search.TestFiltering.testRandomFiltering > >>> [beaster] - > org.apache.solr.search.TestFiltering.testRandomFiltering > >>> > >>> I could just mark it as a BadApple and move on, but wanted to see if > >>> anyone had any ideas about this test flakiness? > >>> > >>> Cheers, > >>> Tim > >>> > >>> On Fri, Sep 17, 2021 at 4:06 PM Mike Drob <[email protected]> wrote: > >>>> > >>>> > >>>> Can we move discussion about the implementation to the JIRA issue or > the PR? > >>>> > >>>> I'm not a lawyer, so not playing with the GPL fire is the easiest > way for me to avoid getting burned. The regex I have is pretty > straightforward, I do not feel like it is a great cause for alarm. > >>>> > >>>> On Fri, Sep 17, 2021 at 4:18 PM Ishan Chattopadhyaya < > [email protected]> wrote: > >>>>> > >>>>> > >>>>> Given that we don't ship the code or binaries that involve that > python library, do we need to care about the license? I'm skeptical of hand > rolled regex and would rather favour either of the libraries Jan mentioned. > Just my two cents. > >>>>> > >>>>> On Sat, 18 Sep, 2021, 12:02 am Mike Drob, <[email protected]> wrote: > >>>>>> > >>>>>> > >>>>>> The second library you linked, Jan, is AGPL. Thank you for > continuing to look for alternatives. > >>>>>> > >>>>>> I have some regular expressions cooked up locally that I think > will let us read the split lines going forward, and will put up the patch > shortly. > >>>>>> > >>>>>> On Fri, Sep 17, 2021 at 7:45 AM Yuval Paz < > [email protected]> wrote: > >>>>>>> > >>>>>>> > >>>>>>> Not sure if this is something can be changed easily, but if the > problem is caused by some parsers don't know how to parse line wrapping in > the middle of the Hash why not moving the hash completely to the new line > (the specification allow new line at any point in the value)? > >>>>>>> > >>>>>>> The commit hash + date comes out to be exactly 71 bytes > (including the space at the start), and it should be a constant size, and > by the time the version will reach 48 bytes we all be probably dead > >>>>>>> > >>>>>>> On Fri, Sep 17, 2021, 2:47 PM Robert Muir <[email protected]> > wrote: > >>>>>>>> > >>>>>>>> > >>>>>>>> Sure, but that package is archived/read-only, GPLv3. with 3 > watchers and 1 star. > >>>>>>>> > >>>>>>>> On Fri, Sep 17, 2021 at 4:27 AM Jan Høydahl < > [email protected]> wrote: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Let's just follow the spec and move on. > >>>>>>>>> > >>>>>>>>> Just tested this python package, which has no problem parsing > the problematic manifest https://pypi.org/project/jarmanifest/ > >>>>>>>>> > >>>>>>>>>>>> manifest.getAttributes("/tmp/lucene-manifest.mf") > >>>>>>>>> > >>>>>>>>> [{'implementationversion': '9.0.0-SNAPSHOT > de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, details > omitted]'}] > >>>>>>>>> > >>>>>>>>> Jan > >>>>>>>>> > >>>>>>>>> 17. sep. 2021 kl. 09:32 skrev Dawid Weiss < > [email protected]>: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> We could do a few things to keep everyone happy - > >>>>>>>>> > >>>>>>>>> 1) keep abbreviated hash in the Implementat-Version and use a > separate manifest entry to store a full hash. > >>>>>>>>> 2) use a longer version for git show (abbrev=num) so that the > chance of collisions in the future is minimized. It's still not a full hash > but a > >>>>>>>>> long(er) forced prefix. > >>>>>>>>> > >>>>>>>>> D. > >>>>>>>>> > >>>>>>>>> On Fri, Sep 17, 2021 at 12:21 AM Chris Hostetter < > [email protected]> wrote: > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> : I was referring to doing this with languages other than java. > >>>>>>>>>> : > >>>>>>>>>> : I'm also assuming that exceeding this limit is going to > cause indirect > >>>>>>>>>> : hassles for users of lucene, e.g. breaking various security > / supply > >>>>>>>>>> : chain tools. We know a lot of these are total crap but > people in the > >>>>>>>>>> : corporate world have to suffer under them. > >>>>>>>>>> > >>>>>>>>>> Just to be clear -- our 'Implementation-Version:' has been > exceeding the > >>>>>>>>>> 72 byte "single line" limit for a LOOOOONG time -- worrying > about how > >>>>>>>>>> "security / supply chain" tools will handle parsing that line > now seems > >>>>>>>>>> kind of silly... > >>>>>>>>>> > >>>>>>>>>> If tools can't handle a line wrap in the 8.10 jars, then they > haven't > >>>>>>>>>> been able to handle the line wrap since we switched from svn > to git (when > >>>>>>>>>> the Implementation Version values switched from being based > svn version# > >>>>>>>>>> to git sha) > >>>>>>>>>> > >>>>>>>>>> The *ONLY* thing that's new here is where in the value the > line wrap > >>>>>>>>>> happens (with 8.10.0 it happens in the middle of the SHA) and > that our > >>>>>>>>>> smoketest tool isn't smart enough to parse the values properly. > >>>>>>>>>> > >>>>>>>>>> This is not even the first time we've even had a conversation > about the > >>>>>>>>>> smoke tester and Implementation Version line wraps: > LUCENE-7023. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> : Its super-easy to use a short hash here and avoid problems. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> There is however an actual and practical downside to switching > our > >>>>>>>>>> implementation version to using a "short" SHA, and that's that > we would > >>>>>>>>>> lose the ability to garuntee that the information in the > >>>>>>>>>> Implementation-Version uniquely identifies what commit a given > jar was > >>>>>>>>>> built from. Multiple commits with the same short(end) hash > are possible > >>>>>>>>>> -- Multiple commits with identical (full) commits is not. > >>>>>>>>>> > >>>>>>>>>> Folks may think that using git tags is useful enough for > figuring this > >>>>>>>>>> out from official releases, but being able to look at the jar > metadata > >>>>>>>>>> from arbitrary builds off of arbitrary branches and sanity > check where > >>>>>>>>>> exactly they come from has been very useful to me for 10+ > years. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> : On Thu, Sep 16, 2021 at 3:03 AM Dawid Weiss < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>>>>>>> : > Jar command doesn't have it, true. But it's fairly trivial > to do, even > >>>>>>>>>> : > with an inline snippet like this one? > >>>>>>>>>> : > > >>>>>>>>>> : > public class PrintManifest { > >>>>>>>>>> : > public static void main(String[] jars) throws > IOException { > >>>>>>>>>> : > for (var jar : jars) { > >>>>>>>>>> : > var manifest = new > JarFile(Paths.get(jar).toFile()).getManifest(); > >>>>>>>>>> : > var attrs = manifest.getMainAttributes(); > >>>>>>>>>> : > System.out.println(jar + ": " + > attrs.getValue("Implementation-Version")); > >>>>>>>>>> : > } > >>>>>>>>>> : > } > >>>>>>>>>> : > } > >>>>>>>>>> : > > >>>>>>>>>> : > I have this in my lucene-core-9.0.0-SNAPSHOT.jar: > >>>>>>>>>> : > > >>>>>>>>>> : > Implementation-Version: 9.0.0-SNAPSHOT > de45b68c909815ce5ea7b6b9e1a2ce337 > >>>>>>>>>> : > 5b6334d [snapshot build, details omitted] > >>>>>>>>>> : > > >>>>>>>>>> : > and running: > >>>>>>>>>> : > > >>>>>>>>>> : > java PrintManifest.java lucene-core-9.0.0-SNAPSHOT.jar > >>>>>>>>>> : > > >>>>>>>>>> : > shows: > >>>>>>>>>> : > > >>>>>>>>>> : > lucene-core-9.0.0-SNAPSHOT.jar: 9.0.0-SNAPSHOT > >>>>>>>>>> : > de45b68c909815ce5ea7b6b9e1a2ce3375b6334d [snapshot build, > details > >>>>>>>>>> : > omitted] > >>>>>>>>>> : > > >>>>>>>>>> : > This seems easier to me than trying to remember and keep > the length of > >>>>>>>>>> : > that line shorter than an arbitrary limit. > >>>>>>>>>> : > > >>>>>>>>>> : > Dawid > >>>>>>>>>> : > > >>>>>>>>>> : > > >>>>>>>>>> : > On Wed, Sep 15, 2021 at 9:46 PM Robert Muir < > [email protected]> wrote: > >>>>>>>>>> : > > > >>>>>>>>>> : > > But its irrelevant that is "valid" when virtually no > tools match it. > >>>>>>>>>> : > > > >>>>>>>>>> : > > In other words, I'd agree with you if the "jar" command > had some > >>>>>>>>>> : > > ability to read these manifests and print stuff to > stdout, e.g. if > >>>>>>>>>> : > > there was ANY interop at all here. > >>>>>>>>>> : > > > >>>>>>>>>> : > > But there isn't. So IMO it makes no sense to cause > confusion and chaos > >>>>>>>>>> : > > by adding an unnecessarily long git commit hash. > >>>>>>>>>> : > > > >>>>>>>>>> : > > On Wed, Sep 15, 2021 at 3:26 PM Dawid Weiss < > [email protected]> wrote: > >>>>>>>>>> : > > > > >>>>>>>>>> : > > > > >>>>>>>>>> : > > > This is valid manifest line-breaking though... Can we > read the manifest properly on the smoke tester side somehow (for example, > run a Java process that reads and extracts the required attribute)? This > way we wouldn't care about the implementation details of how manifest wraps > the lines (or escapes characters). > >>>>>>>>>> : > > > > >>>>>>>>>> : > > > D. > >>>>>>>>>> : > > > > >>>>>>>>>> : > > > On Wed, Sep 15, 2021 at 8:46 PM Mike Drob < > [email protected]> wrote: > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> The benchmark jar has the info we need… sort of. When > I built it, it has: > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> Implementation-Version: 8.10.0 > 75a5061d3715cc5d93c4cbe4f1fa62bf035eea1 > >>>>>>>>>> : > > >> 1 - mdrob - 2021-09-15 11:40:36 > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> and it’s looking for Implementation-Version: 8.10.0 > 75a5061d3715cc5d93c4cbe4f1fa62bf035eea11 on one line. > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> Because 8.10 is a character longer than 8.9, we > happen to wrap the last character of the git commit sha. From the manifest > spec: > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> No line may be longer than 72 bytes (not characters), > in its UTF8-encoded form. > >>>>>>>>>> : > > >> If a value would make the initial line longer than > this, it should be continued > >>>>>>>>>> : > > >> on extra lines (each starting with a single SPACE). > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> And we were already teetering on the edge of that > limit. We'll run into this problem again in a few years when we try to > release version 10.0.0, so solving it now has practical benefits down the > line. > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> There's a few options that I can come up with - > >>>>>>>>>> : > > >> 1. Use the short-hash when we generate the jar > >>>>>>>>>> : > > >> 2. Use the short-hash when we check the contents in > the smoke test > >>>>>>>>>> : > > >> 3. Do some line join magic in the smoke test. > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> I'm leaning towards number 1 as I feel that would > still be unique enough for our needs, but would like to hear from others as > well. > >>>>>>>>>> : > > >> > >>>>>>>>>> : > > >> On Wed, Sep 15, 2021 at 9:46 AM Timothy potter < > [email protected]> wrote: > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> can someone also please look into that benchmark jar > issue? > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> Sent from my iPhone > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> On Sep 15, 2021, at 9:44 AM, Nhat Nguyen < > [email protected]> wrote: > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> Thanks Mayya and Mike! I will backport it to the > 8.10 branch. > >>>>>>>>>> : > > >>> > >>>>>>>>>> : > > >>> On Wed, Sep 15, 2021 at 10:12 AM Mike Drob < > [email protected]> wrote: > >>>>>>>>>> : > > >>>> > >>>>>>>>>> : > > >>>> I think since Tim is out on vacation, it's probably > not too late. That looks like a good fix to have, do we know how long the > bug has been present? > >>>>>>>>>> : > > >>>> > >>>>>>>>>> : > > >>>> On Wed, Sep 15, 2021 at 7:56 AM Mayya Sharipova < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>> > >>>>>>>>>> : > > >>>>> Hello everyone, > >>>>>>>>>> : > > >>>>> We have discovered a bug and fixed a bug in Lucene > sort optimization (LUCENE-10106) and would like to merge it to Lucene 8.10 > if it is not too late. > >>>>>>>>>> : > > >>>>> I apologize for the inconvenience, the bug was > discovered just yesterday. > >>>>>>>>>> : > > >>>>> > >>>>>>>>>> : > > >>>>> On Tue, Sep 14, 2021 at 9:26 PM Timothy Potter < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> Ahem ... unfortunately there will not be an 8.10 > RC this week. I'm > >>>>>>>>>> : > > >>>>>> headed out on vacation tomorrow, back at keys on > Monday, Sept 20 > >>>>>>>>>> : > > >>>>>> unless someone else wants to pick up the RM > duties before then? > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> After failing the test suite at various places > and other weirdness > >>>>>>>>>> : > > >>>>>> like .asc files not getting created, I finally > got to the smoke test > >>>>>>>>>> : > > >>>>>> part, which is now failing with: > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> File > "/Users/tjp/.lucene-releases/8.10.0/lucene-solr/dev-tools/scripts/smokeTestRelease.py", > >>>>>>>>>> : > > >>>>>> line 176, in checkJARMetaData > >>>>>>>>>> : > > >>>>>> raise RuntimeError('%s is missing "%s" inside > its > >>>>>>>>>> : > > >>>>>> META-INF/MANIFEST.MF (wrong git revision?)' % \ > >>>>>>>>>> : > > >>>>>> RuntimeError: JAR file > >>>>>>>>>> : > > >>>>>> > "/Users/tjp/.lucene-releases/8.10.0/RC1/smoketest/unpack/lucene-8.10.0/benchmark/lucene-benchmark-8.10.0.jar" > >>>>>>>>>> : > > >>>>>> is missing "Implementation-Version: 8.10.0 > >>>>>>>>>> : > > >>>>>> ecf5c747e6df418dd05a18af327c20051f0584d7" inside > its > >>>>>>>>>> : > > >>>>>> META-INF/MANIFEST.MF (wrong git revision?) > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> FWIW, I verified that the other Lucene JAR files > have this line in > >>>>>>>>>> : > > >>>>>> them, such as core: > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> Manifest-Version: 1.0 > >>>>>>>>>> : > > >>>>>> Ant-Version: Apache Ant 1.9.15 > >>>>>>>>>> : > > >>>>>> Created-By: 1.8.0_265-b01 (AppleJDK-8.0.265.1.1) > >>>>>>>>>> : > > >>>>>> Extension-Name: org.apache.lucene > >>>>>>>>>> : > > >>>>>> Specification-Title: Lucene Search Engine: core > >>>>>>>>>> : > > >>>>>> Specification-Version: 8.10.0 > >>>>>>>>>> : > > >>>>>> Specification-Vendor: The Apache Software > Foundation > >>>>>>>>>> : > > >>>>>> Implementation-Title: org.apache.lucene > >>>>>>>>>> : > > >>>>>> Implementation-Version: 8.10.0 > ecf5c747e6df418dd05a18af327c20051f0584d > >>>>>>>>>> : > > >>>>>> 7 - tjp - 2021-09-14 19:08:42 > >>>>>>>>>> : > > >>>>>> Implementation-Vendor: The Apache Software > Foundation > >>>>>>>>>> : > > >>>>>> X-Compile-Source-JDK: 8 > >>>>>>>>>> : > > >>>>>> X-Compile-Target-JDK: 8 > >>>>>>>>>> : > > >>>>>> Multi-Release: true > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> On Tue, Sep 14, 2021 at 1:21 PM Ishan > Chattopadhyaya > >>>>>>>>>> : > > >>>>>> <[email protected]> wrote: > >>>>>>>>>> : > > >>>>>> > > >>>>>>>>>> : > > >>>>>> > All the best, this is the worst step. > >>>>>>>>>> : > > >>>>>> > > >>>>>>>>>> : > > >>>>>> > On Tue, 14 Sep, 2021, 10:47 pm Timothy Potter, < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>>> >> > >>>>>>>>>> : > > >>>>>> >> Building RC1 now ... stay tuned. > >>>>>>>>>> : > > >>>>>> >> > >>>>>>>>>> : > > >>>>>> >> On Thu, Sep 9, 2021 at 2:30 PM Timothy Potter < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>>> >> > > >>>>>>>>>> : > > >>>>>> >> > Thanks for the update Mike! > >>>>>>>>>> : > > >>>>>> >> > > >>>>>>>>>> : > > >>>>>> >> > I'm backporting SOLR-15620 right now and am > cooking up a quick PR for > >>>>>>>>>> : > > >>>>>> >> > SOLR-15621, which looks like an easy win for > the issue Cassandra > >>>>>>>>>> : > > >>>>>> >> > reported on Slack earlier today. > >>>>>>>>>> : > > >>>>>> >> > > >>>>>>>>>> : > > >>>>>> >> > Cheers, > >>>>>>>>>> : > > >>>>>> >> > Tim > >>>>>>>>>> : > > >>>>>> >> > > >>>>>>>>>> : > > >>>>>> >> > On Thu, Sep 9, 2021 at 11:32 AM Mike Drob < > [email protected]> wrote: > >>>>>>>>>> : > > >>>>>> >> > > > >>>>>>>>>> : > > >>>>>> >> > > Hi Tim, I'm still working on SOLR-15555, > the code and benchmarking > >>>>>>>>>> : > > >>>>>> >> > > both look pretty good, but I've got a few > last unit tests that I need > >>>>>>>>>> : > > >>>>>> >> > > to chase down. Hopefully taken care of by > today or tomorrow, I'll be > >>>>>>>>>> : > > >>>>>> >> > > sure to keep you updated though. > >>>>>>>>>> : > > >>>>>> >> > > > >>>>>>>>>> : > > >>>>>> >> > > > >>>>>>>>>> : > > >>>>>> >> > > On Thu, Sep 9, 2021 at 11:39 AM Timothy > Potter <[email protected]> wrote: > >>>>>>>>>> : > > >>>>>> >> > > > > >>>>>>>>>> : > > >>>>>> >> > > > I found > https://issues.apache.org/jira/browse/SOLR-15620 while testing > >>>>>>>>>> : > > >>>>>> >> > > > the schema designer. I haven't built the > RC yet, so going to see if I > >>>>>>>>>> : > > >>>>>> >> > > > can get this in today. > >>>>>>>>>> : > > >>>>>> >> > > > > >>>>>>>>>> : > > >>>>>> >> > > > On Tue, Sep 7, 2021 at 12:36 PM Timothy > Potter <[email protected]> wrote: > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > NOTICE: > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > Branch branch_8_10 has been cut and > versions updated to 8.11 on stable branch. > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > Please observe the normal rules: > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > * No new features may be committed to > the branch. > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > * Documentation patches, build patches > and serious bug fixes may be > >>>>>>>>>> : > > >>>>>> >> > > > > committed to the branch. However, > you should submit all patches you > >>>>>>>>>> : > > >>>>>> >> > > > > want to commit to Jira first to give > others the chance to review > >>>>>>>>>> : > > >>>>>> >> > > > > and possibly vote against the patch. > Keep in mind that it is our > >>>>>>>>>> : > > >>>>>> >> > > > > main intention to keep the branch as > stable as possible. > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > * All patches that are intended for > the branch should first be committed > >>>>>>>>>> : > > >>>>>> >> > > > > to the unstable branch, merged into > the stable branch, and then into > >>>>>>>>>> : > > >>>>>> >> > > > > the current release branch. > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > * Normal unstable and stable branch > development may continue as usual. > >>>>>>>>>> : > > >>>>>> >> > > > > However, if you plan to commit a big > change to the unstable branch > >>>>>>>>>> : > > >>>>>> >> > > > > while the branch feature freeze is > in effect, think twice: can't the > >>>>>>>>>> : > > >>>>>> >> > > > > addition wait a couple more days? > Merges of bug fixes into the branch > >>>>>>>>>> : > > >>>>>> >> > > > > may become more difficult. > >>>>>>>>>> : > > >>>>>> >> > > > > > >>>>>>>>>> : > > >>>>>> >> > > > > * Only Jira issues with Fix version > 8.10 and priority "Blocker" will delay > >>>>>>>>>> : > > >>>>>> >> > > > > a release candidate build. > >>>>>>>>>> : > > >>>>>> >> > > > > ---- > >>>>>>>>>> : > > >>>>>> >> > > > > >>>>>>>>>> : > > >>>>>> >> > > > > --------------------------------------------------------------------- > >>>>>>>>>> : > > >>>>>> >> > > > To unsubscribe, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> > > > For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> > > > > >>>>>>>>>> : > > >>>>>> >> > > > >>>>>>>>>> : > > >>>>>> >> > > > --------------------------------------------------------------------- > >>>>>>>>>> : > > >>>>>> >> > > To unsubscribe, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> > > For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> > > > >>>>>>>>>> : > > >>>>>> >> > >>>>>>>>>> : > > >>>>>> >> > --------------------------------------------------------------------- > >>>>>>>>>> : > > >>>>>> >> To unsubscribe, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> >> > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > >>>>>> > --------------------------------------------------------------------- > >>>>>>>>>> : > > >>>>>> To unsubscribe, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>> > >>>>>>>>>> : > > > >>>>>>>>>> : > > > --------------------------------------------------------------------- > >>>>>>>>>> : > > To unsubscribe, e-mail: [email protected] > >>>>>>>>>> : > > For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > > >>>>>>>>>> : > > >>>>>>>>>> : > > --------------------------------------------------------------------- > >>>>>>>>>> : > To unsubscribe, e-mail: [email protected] > >>>>>>>>>> : > For additional commands, e-mail: > [email protected] > >>>>>>>>>> : > > >>>>>>>>>> : > >>>>>>>>>> : > --------------------------------------------------------------------- > >>>>>>>>>> : To unsubscribe, e-mail: [email protected] > >>>>>>>>>> : For additional commands, e-mail: [email protected] > >>>>>>>>>> : > >>>>>>>>>> : > >>>>>>>>>> > >>>>>>>>>> -Hoss > >>>>>>>>>> http://www.lucidworks.com/ > >>>>>>>>>> ________________________________ > >>>>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>>>> For additional commands, e-mail: [email protected] > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>> ________________________________ > >>>>>>>> To unsubscribe, e-mail: [email protected] > >>>>>>>> For additional commands, e-mail: [email protected] > >>>>>>>> > >>> ________________________________ > >>> To unsubscribe, e-mail: [email protected] > >>> For additional commands, e-mail: [email protected] > >>> > >> -- > >> Uwe Schindler > >> Achterdiek 19, 28357 Bremen > >> https://www.thetaphi.de > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > >
