+1 On Jul 16, 2017 17:14, "Joan Touzet" <[email protected]> wrote:
> Hi all, > > *Per the CouchDB bylaws, this is a concrete proposal that will default > to lazy consensus in 72 hours (2017.07.19 ~21:00).* > > As we approach release candidates for v2.1 (see next email), we have one > major decision left to make: whether or not to include the scheduling > replicator in 2.1. > > Arguments for inclusion: > > * New feature allowing CouchDB to manage more replication jobs at > the same time by switching between them / starting / stopping. > From the documentation: > * Handles failing jobs more gracefully (exponnential backoff). > * Includes a new pair of API endpoints: _scheduler/jobs and > _scheduler/docs with enhanced information and an updated state > machine for replication jobs. > * Shared connection pool improves network resource usage and > performance, especially with large numbers of connections to > the same source/target. > * Improved request rate limit handling. > * Improved recovery from long but temporary network failures. > * Better handling of filtered replications. > * Feature includes its own tests, which all pass. > * Feature is fully documented. > * Cherry-picking out the scheduling replicator commits from the > ~190 commits since then (all bugfixes and minor improvements) is > labour intensive for the release team, and possibly error prone. > > Arguments against inclusion: > > * It has been ~9 months since the 2.0 release. Many bugs have been > found and fixed. > * A new release without the scheduling replicator would provide > risk mitigation for users who need those bug fixes but are risk- > averse to new features. > * Scheduling replicator has not seen much real-world testing. Bugs > may surface in a 2.1 release that could destabilise existing > installs being upgraded. > > I've thought a lot about this issue, and would like to propose that we > release 2.1 *with* the scheduling replicator included. My reasoning is > that the benefits outweigh the potential downsides. If necessary, we > can release a 2.1.1 in the following weeks with urgent bug fixes to > the scheduling replicator if necessary. > > Another alternative would be to ~simultaneously release a 2.1 from just > before the scheduling replicator landed (~190 commits ago), then a 2.2 > from the HEAD of the master branch with all the subsequent fixes. 2.1 > would be missing these more recent fixes, but it would again avoid the > massive cherry-picking operation necessary to port all of them to the > 2.1 branch without the scheduling replicator. I'm -0 on this because > of the confusion it might create with release announcements, but > wouldn't block if that was the desired path forward. > > Developers, please make your voices heard! :) > > -Joan >
