couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <>
Subject Re: 2.1
Date Sun, 21 May 2017 18:03:56 GMT
(I should note that since I'm the point person for CouchDB at my
company, I end up using I/we a bit interchangeably.)

On Sun, May 21, 2017 at 3:07 AM, Jan Lehnardt <> wrote:
>> On 21. May 2017, at 04:17, Eli Stevens (Gmail) <> wrote:
>> I realize that this might be somewhat nonsensical, given that I don't
>> have a good handle on what the testing situation was surrounding 2.0,
>> but our expectation is that going from 1.6.1 to 2.0 should be a
>> support and stability improvement, which is important for us.
> I’m not sure this is a sensible expectation. Of course some things
> will be better, but 2.0 is a major version bump especially because
> there code-base is significantly different from 1.6.1 which for the
> most part is very solid (once one knows what not to do, which I know
> you do :)

I hope that's true.  :)  We're currently thinking about contracting
out some performance tuning once we have 2.0 in place, just in case.

>> Right now the biggest source of test failures for my company's product is
>> CouchDB 1.6.1 instability.
> Do you have JIRA pointers for us?

No. My typical pattern when encountering an issue was to post on IRC
first asking essentially "does this look like user error?" and only
escalating to JIRA if instructed to by one of the devs. I suspect that
this Nov. 2014 gist is an example:

Post-Nebraska merge I started being told (heavily paraphrased) "the
codebase has changed so much that there's no way to relate a 1.6.1
error with the current state of the master branch." Essentially my
options were to reproduce the issue on a source build off of master,
or wait for 2.0 proper (we chose to wait). I understand the reasoning,
even if it's somewhat unsatisfying as a customer.

So when I say "2.0 should be a support and stability improvement" I
mean that we can start to file bugs again, and if we have urgent
issues it's a reasonable expectation that we can hire someone to fix
them. I am also hoping that the at-scale usage at Cloudant hardened it
somewhat, but that's just a bonus.

> It is mostly that the tests are not stable, not the code-base itself.

Yeah, that's an unpleasant situation to be in. However, at the end of
the day "trust me, it's fine" isn't an argument that I'm likely to
risk the nights and weekends of our support team on (the engineers on
my team don't get a pass here either).

> All that said, despite the plan I set out here, I spent some time
> trying to stabilise the tests and/or improve debugging options where
> the cause of the intermittent issues wasn’t clear. This landed
> yesterday, so no we’ll have to see how this holds up.


Despite my critical tone, I want to make it clear that I do appreciate
all of the volunteer work that gets put into the project. Thank you
for doing so.


View raw message