(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 <j...@apache.org> wrote: >> On 21. May 2017, at 04:17, Eli Stevens (Gmail) <wickedg...@gmail.com> 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: https://gist.github.com/elistevens/14be978964292516b8f8 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
