Hey everyone, from Joan’s excellent blog post about testing Release Candidates:
> To our valued CouchDB application and library developers: please, please run > your software against each of the options below. — https://blog.couchdb.org/2016/08/08/release-candidates/ I think we can be a little more proactive about this for CouchDB client libraries: let’s open issues on all the CouchDB-compatible client software we care about to test an RC. Since there are a lot of projects, and we don’t necessarily know which one we “care” about, we should try to be clever about it. Maybe something like this can work: 1. We prepare an issue text explaining the thing: Heya, CouchDB team here, major new version coming up, you should test it like so: <include instructions to test against a 3-node cluster. Maybe even provide a cluster to do this, or Cloudant can sponsor something? 2. Post this message with a call to action on [email protected], the weekly news, and our other (social) media channels. 3. Ask people who submitted an issue to report back with a link. 4. Collect the link in an issue or JIRA (this could be done in 3., but then everybody needs to be added to the wiki write group, and that’s just extra overhead we don’t need). Maybe we borrow a gist for this, or a Google doc. That way we encourage client software to check out RCs and we can keep track, while the community helps to select which software to encourage to test 2.0 compat, and helps spread the word and the burden is not left with just a few folks. What do you think? Best Jan --
