Hey Jan, you didn't provide an argument, so I can only guess: Do you think that we shouldn't tackle that right now, as it would potentially delay the 2.0 release?
On 10.11.2014 15:07, Jan Lehnardt wrote: > I’d say let’s keep em for now. > > Best > Jan > -- > >> On 10 Nov 2014, at 12:40 , Klaus Trainer <klaus_trai...@posteo.de> wrote: >> >> Hello everybody. >> >> I'd like to hear your thoughts about removing the `delayed_commits` >> option together with the corresponding code paths. >> >> Note that independent of this discussion (and in contrast to 1.x >> releases), the delayed commits feature will be disabled by default in >> the upcoming 2.0 release. I'd like to propose that we now (as we're >> already breaking API compatibility with the new major release) go the >> full way and remove that feature entirely. >> >> Speaking for myself: I've never needed that feature, and I'd certainly >> not miss it. I remember several times where I was in the awkward >> position of having to explain it. After recommending people to not >> enable delayed commits in production, I'd usually get asked about the >> purpose of that feature. Then I would answer something awkward like >> "we've implemented and enabled delayed commits by default so that >> CouchDB looks good in certain benchmarks". >> >> Would you miss delayed commits? Do you think that users would miss it, >> and if so, why? >> >> Thanks, >> Klaus >> >
signature.asc
Description: OpenPGP digital signature
