If it makes anyone feel better, 2600 of the 3600-lines of this patch are tests (and the rest is minor refactoring of the verb handlers).
Anyway, glad to see a ton of participation here. I'll get back into implementation space today, and start dealing with review feedback as it comes in... P.S. I want to call out/thank Sam Tunnicliffe, whose unpublished work is the basis for the patch I've put together. On Fri, Sep 13, 2024 at 8:52 AM Brandon Williams <dri...@gmail.com> wrote: > On Thu, Sep 12, 2024 at 8:34 PM Josh McKenzie <jmcken...@apache.org> > wrote: > > I'm not advocating for us having a rigid principled stance where we > reject all nuance and don't discuss things. I'm advocating for us > coalescing on a shared default stance of correctness unless otherwise > excepted. We know we're a diverse group, we're all different people with > different histories / values / opinions / cultures, and I think that's what > makes this community as effective as it is. > > > > But I don't think it's healthy for us to repeatedly re-litigate whether > data loss is acceptable based on how long it's been around, or how > frequently some of us on the project have observed some given phenomenon. > My gut tells me we'd all be in a better place if we all started from 0 on a > discussion like this as "Ok, data loss is unacceptable. Unless otherwise > warranted, we should do all we can to fix this on all supported branches as > our default response". > > I think this absolutely makes sense in situations where things are > clear cut and just need to be corrected, like an off-by-one error. We > discover the problem, we fix it. > > However, the current situation is not that. You say age is not > relevant, and though that may be true for the age of the bug (which is > before my time!), I do think it's relevant that we've known about this > (documented by the ticket) for at least 7 years, but only now have > decided to address it. Furthermore, this isn't a straight correction, > from the very beginning a possible tradeoff with availability in some > circumstances was mentioned. We are talking about changing behavior > on top of a 200k delta in ~4k lines of code across a significant > amount of files, and doing so in the 13th minor release of a 4 year > old major, for a problem we have known about long enough to have put > this in all current major releases. I don't think painting the > picture with the "data loss" brush alone tells us everything we need > to know to make that kind of commitment to what is now our old stable > branch. > > That said, I want to thank Scott and others who provided helpful > context here. I still think it is in the realm of possibility that > changing behavior can cause a problem for an existing user, and they > will be right to be angry if that happens, but that is an easier pill > to swallow if we are possibly preventing data loss that is easier to > encounter than previously thought. I support doing this in all the > current branches. > > Kind Regards, > Brandon >
