Russell confirmed on IRC. The vote can proceed. For extra safety: if anyone runs make check on this tarball and find test fails in the log, please post them here, that would block the release.
It's all fine on Travis and I think Jenkins. Cheers Jan — > On 1. Mar 2019, at 11:17, Jan Lehnardt <j...@apache.org> wrote: > > 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/ >
