I have a hard time reconciling those statements with what I’m seeing in the logs:
Consider this snippet from the latest 2.3.x build log[1]: https://gist.github.com/janl/3c7db5f3ff466f9985306253d61abc3b It is the output for couchdb_views_tests[2], which has 5 test groups defined, and all test groups with all their inside them get an `...ok` line. 4/5 groups get a `erl_child_setup: failed with error 32 on line 253` message *after* the tests in each group ran to successful completion. As such, I’d suggest we do NOT need to abort this vote just yet. It’d be great to figure out what causes those messages to avoid confusion, and we’ve addressed an unrelated but related issue about hard failing the test suite if a sub-group fails, but the 2.3.x log does not exhibit this. Obligatory statement that votes don’t happen on IRC. Best Jan — [1]: full log here: https://api.travis-ci.org/v3/job/494557908/log.txt [2]: https://github.com/apache/couchdb/blob/2.3.x/src/couch/test/couchdb_views_tests.erl > On 27. Feb 2019, at 22:26, Joan Touzet <woh...@apache.org> wrote: > > Based on discussion with Russell Branca (chewbranca) in IRC, we need to > abort this RC vote as he is effectively voting -1. Here's the full > transcript of our discussion: > > ------------------------ > > 16:06 <+Wohali> chewbranca: you there? are you seeing these eunit > context setup errors in 2.3.0 as well as the 2.3.1 RC > and master? > 16:06 <+Wohali> I don't want to hold up 2.3.1 over something that was a > pre-existing condition, but if it's something that > changed between 2.3.0 and 2.3.1/master, we need to fix > it > 16:07 <chewbranca> Wohali: well the fundamental issue right now is test > suite failures don't fail the build, which IMO should > be fixed before any further builds > 16:08 <chewbranca> I've been using this diff locally, which fails the > `make eunit` check upon an eunit failure: > https://gist.github.com/chewbranca/65d2969ac191a5dfaf87172ace18d2ee > 16:08 <chewbranca> not sure that's the best approach, but we need > something like that > 16:08 <+Wohali> What I'm asking is: do you think this should block the > release of 2.3.1? > 16:08 <+Wohali> By all means PR that to master and let's get shit in > gear > 16:08 <+Wohali> I'm trying to work out when this problem started > occurring, though. > 16:09 <chewbranca> yes, should definitely block any further releases, > because unless someone is manually inspecting the > eunit output, then we could have test failures > bubbling through > 16:11 <chewbranca> in theory this particular issue was introduced 26 > days ago with the change to running individual eunit > tests: > https://github.com/apache/couchdb/commit/20bbfbf972ad1f822e2ef1edfb3d47f2cec3f639 > 16:11 <chewbranca> so this is probably a new thing, but we've definitely > had issues with eunit over the years > 16:12 <chewbranca> Wohali: I can make a quick PR with the diff I pasted > above and then we should be good to go IMO, but it > wouldn't hurt to see if there's a more proper way to > do that in a Makefile than just `|| exit 1` > 16:16 <+Wohali> chewbranca: are you 100% sure that context setup > failures mean the tests are actually failing? They seem > to be running and passing even after that. I'm too > unfamiliar to know for sure. > 16:17 <+Wohali> chewbranca: that change you linked isn't in 2.3.1. > 16:17 <chewbranca> context setup failure means that setting up a series > of eunit test generators failed and those tests > aren't being executed > 16:17 <+Wohali> ok. > 16:18 <chewbranca> those will fail if you do `|| exit 1`, but they > continue running today because we don't exit on the > individual eunit runs > 16:18 <+Wohali> 2.3.1 has a critical fix for buffer sizes that we need > to get out there. WOuld you accept me manually reviewing > the output of 2.3.1's test suite to ensure no context > setup failures? > 16:18 <+Wohali> then we make this a blocker for 2.4.0? > 16:18 <chewbranca> what I linked above is just a diff that I've been > using locally because I wanted the suite to fail, and > it works > 16:19 <chewbranca> Wohali: IMO let's just add that diff and then if > folks know a more proper Makefile approach to doing > that type of thing then they can fix it later > 16:19 <+Wohali> to both 2.3.1 and master? And to Makefile.Win I presume? > ;) Then we'll have to cancel the current RC and re-spin. > ... > 16:25 <chewbranca> https://github.com/apache/couchdb/pull/1951 > > ------------------------ > > > ----- Original Message ----- >> From: "Dave Cottlehuber" <d...@skunkwerks.at> >> To: dev@couchdb.apache.org >> Sent: Monday, February 25, 2019 6:10:05 AM >> Subject: Re: [VOTE] Release Apache CouchDB 2.3.1 RC2 >> >> On Mon, 25 Feb 2019, at 10:56, Dave Cottlehuber wrote: >>> On Thu, 21 Feb 2019, at 06:27, Jan Lehnardt wrote: >>> >>> FreeBSD 12.0-RELEASE-p3 amd64 + OTP 21.2.6 custom >>> >>> - OK sigs and checksums >>> - OK release >>> - fauxton verify is happy >>> - make check fails with the C.UTF-8 issues Joan has mentioned >>> previously >>> >>> belated +1 from me >>> >>> BTW the port will be a bit delayed this time as I need to bump OTP >>> version and that usually has a bit of ports tree shakeout. My patch >>> for >>> that is https://reviews.freebsd.org/D18820 >> >> I forgot to mention that the tarball has the annoying -RC2 suffix in >> filenames, which makes the downstream packaging diffs fiddly. I have >> that unfinished PR https://github.com/apache/couchdb/pull/1927 >> hopefully to fix that for next time. >> >> A+ >> Dave >> -- Professional Support for Apache CouchDB: https://neighbourhood.ie/couchdb-support/
