Hi. With the current five +1's and two -1's I'm not seeing the kind of consensus we traditionally want for a release. It's understandable due the uncertainty caused by the two bugs uncovered during the vote. The important question is whether the majority of us deem any of these bugs as release blockers.
Before I conclude the vote (tomorrow), I'll allow time for more votes to be cast (or changed in either direction), taking the latest insight into account.. Jan > 2. mai 2022 kl. 21:40 skrev Joel Bernstein <[email protected]>: > > It would be a pretty odd edge case. The enum method would typically not be > used in high cardinality cases and limit:-1 means an overrequest is not > needed. I personally don't think this is a blocker. > > > Joel Bernstein > http://joelsolr.blogspot.com/ <http://joelsolr.blogspot.com/> > > > On Mon, May 2, 2022 at 12:43 PM Michael Gibney <[email protected] > <mailto:[email protected]>> wrote: > Gus said most of what I have to say -- this affects an odd edge case: > explicit positive overrequest _and_ method:enum _and_ limit:-1. This would be > a pretty pathological combination; but even so, the consequence would be to > turn an unlimited (limit:-1) request into a limited one (limit:n, n>=0) -- it > would not be subtle in how that would manifest. So I'll retract my earlier > statement ("I'd be surprised if this turns out to be a blocker for 9.0"). > > On Mon, May 2, 2022 at 11:45 AM Gus Heck <[email protected] > <mailto:[email protected]>> wrote: > Also this changes my vote to -1 > > On Mon, May 2, 2022 at 11:44 AM Gus Heck <[email protected] > <mailto:[email protected]>> wrote: > Some offline discussion indicates that this is more than just SKG and it > looks like Michael will look into it, so I've filed > https://issues.apache.org/jira/browse/SOLR-16176 > <https://issues.apache.org/jira/browse/SOLR-16176> as a blocker and assigned > to him. > > On Mon, May 2, 2022 at 11:03 AM Jan Høydahl <[email protected] > <mailto:[email protected]>> wrote: > Tried some seeds from Jenkins failures for this same test, and found another > reproducible seed: 19DF63E9537FFBA3 > > On the face of it, it seems like a corner case bug, but could of course be a > generic enum JSON Facet bug that has lived with us for some time? > I'll wait a bit more to gather more insight on this. > Gus, have you created a JIRA? > > Jan > >> 2. mai 2022 kl. 16:01 skrev Gus Heck <[email protected] >> <mailto:[email protected]>>: >> >> >> I was hoping someone more familiar with SKG's test/code that I found a >> failure for might chime in. It looks like it's a case where enum facets are >> not producing all results produced for default faceting, which seems >> possibly bad, but I am not familiar with this code at all. This probably is >> localized to Semantic Knowledge Graphs (which after some digging is what SKG >> stands for... be nice if that were in the comments for the class)... so the >> question is do we want to release with a known break in that feature I >> guess. I'm inclined to say no, but I am certainly not going to be able to >> dig into SKG's to fix this in a timely fashion. So I guess the question is >> is SKG important enough to someone out there to fix it soon? >> >> Also looks like the code iterates across possible parameter values and fails >> on the first one to go wrong so there may be other failure cases for STREAM >> or SMART hiding behind this... >> >> -Gus >> >> On Mon, May 2, 2022 at 6:55 AM Jan Høydahl <[email protected] >> <mailto:[email protected]>> wrote: >> Hi, >> >> If I close the vote now, it will technically pass with four +1s, one -1 and >> one -0. A bit too fragile result IMO. >> >> I would too like to understand the severity of the configsets bug, and >> whether it is serious enough to stop the release. >> As I understand the issue, it ONLY affects those creating a new configset >> based on another one in ZK. >> I.e. there are many workarounds for this bug >> - Use an authenticated user when creating configset (and not an "untrusted" >> one) >> - Upload a new configset rather than basing it on an existing? >> - Upload configset directly to Zookeeper >> >> Please verify or shoot down my assumption. If my assumption is correct, I'll >> keep my +1 vote, and wait for a few more +1s before closing the vote. If the >> issue is indeed more serious and there are more -1's, I'll happily respin >> after the fix. >> >> Jan >> >> >>> 29. apr. 2022 kl. 21:03 skrev Gus Heck <[email protected] >>> <mailto:[email protected]>>: >>> >>> -0 for now, pending discussion of severity... I have hit a reproducing >>> failure: >>> >>> ./gradlew :solr:core:test --tests >>> "org.apache.solr.search.facet.TestCloudJSONFacetSKGEquiv.testRandom" >>> -Ptests.jvms=5 -Ptests.jvmargs=-XX:TieredStopAtLevel=1 >>> -Ptests.seed=C730F33909C71234 -Ptests.badapples=false >>> -Ptests.file.encoding=UTF-8 >>> >>> On Fri, Apr 29, 2022 at 1:28 PM Kevin Risden <[email protected] >>> <mailto:[email protected]>> wrote: >>> Smoketester passed on the second try for me: SUCCESS! [1:29:24.214674] >>> >>> The first failure was "gradlew :solr:core:test --tests >>> "org.apache.solr.cloud.HttpPartitionOnCommitTest.test" -Ptests.jvms=4 >>> -Ptests.jvmargs=-XX:TieredStopAtLevel=1 -Ptests.seed=66730F3AEF630DB6 >>> -Ptests.badapples=false -Ptests.file.encoding=US-ASCII". I haven't >>> reproduced it yet. >>> >>> However it looks like the configsets API is broken with one of the simpler >>> examples. Eric Pugh found this the other day and asked me to check on 9.0 >>> RC4: https://issues.apache.org/jira/browse/SOLR-16164 >>> <https://issues.apache.org/jira/browse/SOLR-16164> >>> >>> I'm still poking around the release today. >>> >>> Based on the configset api error - I'm -1 for releasing. >>> >>> Kevin Risden >>> >>> >>> On Fri, Apr 29, 2022 at 11:26 AM Mike Drob <[email protected] >>> <mailto:[email protected]>> wrote: >>> +1 (binding) >>> >>> >>> Smoketester succeeded with Java 11 and Java 17 -- SUCCESS! [2:04:03.678208] >>> >>> Unlike for some others, this succeeded on my first try. I guess I'm just >>> lucky :) >>> >>> >>> Tested building an application that uses EmbeddedSolrServer and depends on >>> our maven artifacts - validated SOLR-16157, SOLR-16117 >>> >>> Tested a mixed state cluster with 8.11.1 and 9.0.0 nodes (no security). >>> Queries worked as expected. >>> Tested a rolling upgrade from 8.11.1 to 9.0.0 with basic authentication >>> enabled. Queries failed (as expected) at first, but then succeeded when >>> setting solr.pki.sendVersion=v1 and solr.pki.acceptVersions=v1,v2on the >>> Solr 9 node, as described in our ref guide and upgrade notes. >>> >>> Manually checked for license headers in source release, missing headers on >>> the following: >>> * SYSTEM_REQUIREMENTS.md >>> * solr/core/src/resources/SystemCollection*.xml >>> * lots and lots of stuff under solr-ref-guide, unclear which pieces of this >>> are our code and which are copied from external sources. >>> * modules/*/README.md >>> >>> Will file a follow up JIRA for the license issues. >>> >>> On Wed, Apr 27, 2022 at 8:15 AM Jan Høydahl <[email protected] >>> <mailto:[email protected]>> wrote: >>> Please vote for release candidate 4 for Solr 9.0.0 >>> >>> The artifacts can be downloaded from: >>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>> >>> <https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc> >>> >>> You can run the smoke tester directly with this command: >>> >>> python3 -u dev-tools/scripts/smokeTestRelease.py \ >>> https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc >>> >>> <https://dist.apache.org/repos/dist/dev/solr/solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc> >>> >>> You are encouraged to do an extra thorough test and manual inspection beyond >>> running the smoketester, since this is a major release. >>> >>> You can build a release-candidate of the official docker image using the >>> following command: >>> >>> DIST_BASE=https://dist.apache.org/repos/dist/dev/solr >>> <https://dist.apache.org/repos/dist/dev/solr> && \ >>> RC_FOLDER=solr-9.0.0-RC4-rev-d6e36d590896755ca962c6d2ddedf78ca4f463cc && \ >>> docker build $DIST_BASE/$RC_FOLDER/solr/docker/Dockerfile.official \ >>> --build-arg SOLR_DOWNLOAD_URL=$DIST_BASE/$RC_FOLDER/solr/solr-9.0.0.tgz \ >>> -t solr-rc:9.0.0-4 >>> >>> The vote will be open for at least 72 hours i.e. until 2022-04-30 13:00 UTC. >>> >>> [ ] +1 approve >>> [ ] +0 no opinion >>> [ ] -1 disapprove (and reason why) >>> >>> Here is my +1 >>> >>> SUCCESS! [0:56:56.134141] >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> <mailto:[email protected]> >>> For additional commands, e-mail: [email protected] >>> <mailto:[email protected]> >>> >>> >>> >>> -- >>> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >>> http://www.the111shift.com <http://www.the111shift.com/> (play) >> >> >> >> -- >> http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) >> http://www.the111shift.com <http://www.the111shift.com/> (play) > > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play) > > > -- > http://www.needhamsoftware.com <http://www.needhamsoftware.com/> (work) > http://www.the111shift.com <http://www.the111shift.com/> (play)
