couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From support-tiger <>
Subject Re: 2.1
Date Sun, 21 May 2017 19:02:25 GMT
It is a good point not to dismiss/ignore/adjust tests so they pass, BUT, 
if the failures are deemed intermittent and minor, they can be placed as 
a bug and lots of software (all ?)  ships with bugs.  Obviously for a 
db, one hopes any bug is very minor or highly sporadic.   Getting stuff 
out there often helps find/correct the bugs - just call it 2.1 beta - 
keep up the great work and keep moving forward.

On 05/21/2017 03:03 PM, Eli Stevens (Gmail) wrote:
> (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.
> +1
> 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.
> Cheers,
> Eli

Support Dept
Tiger Nassau, Inc.

View raw message