+1 Cheers Jan --
> On 17. Jul 2017, at 20:35, Paul Davis <paul.joseph.da...@gmail.com> wrote: > > +1 (assuming that's +1 in favor of releasing with scheduling replicator) > >> On Sun, Jul 16, 2017 at 7:54 PM, Nick Vatamaniuc <vatam...@gmail.com> wrote: >> +1 >> >>> On Jul 16, 2017 17:14, "Joan Touzet" <woh...@apache.org> 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 >>>
