couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: [VOTE] Release Apache CouchDB 2.3.1 RC2
Date Fri, 01 Mar 2019 10:17:48 GMT
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]:

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.


[1]: full log here:

> On 27. Feb 2019, at 22:26, Joan Touzet <> 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:
> 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:
> 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>
>  ------------------------
> ----- Original Message -----
>> From: "Dave Cottlehuber" <>
>> To:
>> 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
>> 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
>> hopefully to fix that for next time.
>> A+
>> Dave

Professional Support for Apache CouchDB:

View raw message