> 4.0 / 4.1 - if we treat this like a fix for latent opportunity for data loss > (which it implicitly is), I guess? If we have known data loss scenarios we should fix them in all supported branches even if that fix can potentially modify user-facing behavior. We should definitely try and prioritize fixing issues w/out changing behavior of course, but if it's zero sum between risk of data loss and risk of user-facing disruptive behavior, I'll choose the 2nd every time.
Size of the patch shouldn't really be a make or break on that position, though something to consider in terms of risk it introduces, other things we may need to touch / test / qualify, extent of fuzzing and potential additional property-based testing for subsystems impacted, etc. On Thu, Sep 12, 2024, at 12:55 PM, Jeff Jirsa wrote: > This patch is so hard for me. > > The safety it adds is critical and should have been added a decade ago. > Also it’s a huge patch, and touches “everything”. > > It definitely belongs in 5.0. I’d probably reject by default in 5.0.1. > > 4.0 / 4.1 - if we treat this like a fix for latent opportunity for data loss > (which it implicitly is), I guess? > > > > > On Sep 12, 2024, at 9:46 AM, Brandon Williams <dri...@gmail.com> wrote: > > > > On Thu, Sep 12, 2024 at 11:41 AM Caleb Rackliffe > > <calebrackli...@gmail.com> wrote: > >> > >> Are you opposed to the patch in its entirety, or just rejecting unsafe > >> operations by default? > > > > I had the latter in mind. Changing any default in a patch release is > > a potential surprise for operators and one of this nature especially > > so. > > > > Kind Regards, > > Brandon > >
