+1 for option #1 Let's control the hash to a reasonable size, so that the version number will "fit"
We would hit this same problem with 10.0.0 and then we'd have to revisit it again with 10.10.0, so let's not try to solve it onesy-twosey at this time On Wed, Sep 15, 2021 at 2: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]
