+1 On Wed, Jul 19, 2017 at 11:04 AM, Jan Lehnardt <[email protected]> wrote:
> +1 > > Cheers > Jan > -- > > > On 17. Jul 2017, at 20:35, Paul Davis <[email protected]> > wrote: > > > > +1 (assuming that's +1 in favor of releasing with scheduling replicator) > > > >> On Sun, Jul 16, 2017 at 7:54 PM, Nick Vatamaniuc <[email protected]> > wrote: > >> +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 > >>> > >
