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 >
