couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <wickedg...@gmail.com>
Subject Re: 2.0 blocker: new failing tests on Windows
Date Sun, 11 Sep 2016 05:41:37 GMT
FWVLIW, I'd rather keep the tests active, and have the release happen
with not all tests passing. A failing test doesn't have to be a
release blocker (I mean, this PR is clearly stating as much). Maybe
add a known issue in the release notes or something.

If the policy is "the tests must pass" with an implied "...but it's
okay to comment out any that aren't passing" then it's probably a bad
policy. It's too easy to forgot to re-enable the tests once the
release is out, and hence forget that anything needs to be looked at.

Note: my day job is such that the FDA takes an active interest in the
results of my team's unit tests (the audit a couple of weeks ago was
fun), and so I tend to be a bit more pedantic about these things than
average.

Cheers,
Eli

On Sat, Sep 10, 2016 at 12:36 PM, Joan Touzet <wohali@apache.org> wrote:
> Hi there,
>
> About 3 weeks ago eiri added new tests to the couchdb_os_proc_pool
> suite. Unfortunately, I haven't run the test suite since then, so it is
> only at this late date that I discover two of the tests are failing on
> Windows, blocking my ability to declare the build clean.
>
> You can view sample output of a failed test run here:
>
>   https://issues.apache.org/jira/browse/COUCHDB-3140
>
> I have a PR open to temporarily disable these tests to allow us to
> proceed with a timely 2.0.0 release:
>
>   https://github.com/apache/couchdb-couch/pull/195
>
> The reason for doing so is chiefly one of expediency. At the moment I am
> the only Windows CouchDB developer and I simply don't have the time to
> diagnose what is wrong with either the test or the process manager it is
> testing. I did a bit of playing around with increasing the timeout (and
> configuring eunit to give the tests more time to run than its default
> 5s) but the problem did not go away, suggesting the issue is more subtle
> than one of slow-to-start/stop couchjs processes.
>
> Any help anyone can provide would be greatly appreciated. If I hear
> nothing in the next 24 hours or so, I will merge this PR (and bump
> rebar.config in the main couch repo to pick up the change).
>
> Thanks,
> Joan

Mime
View raw message