On Wed, 26 Aug 2026 at 04:48, Robert Haas <[email protected]> wrote:
> I don't currently have a firm position on what we should do here. I
> think it's pretty clear that none of these were as robust at commit
> time as we would like, but that doesn't mean that they're still
> broken.

I don't envy the job of the RMT having to make these choices, but IMO
part of the controls for where to set the bar for the trigger point
for a revert should include the amount of available quality review and
discussion bandwidth that's available at the time when the bug is
discovered. It's easy for people removed from the problem to sit at
home and demand that everything gets done, but when cycles are
limited, something must be sacrificed. Sometimes that's free time, but
it's hard not to let quality slip when under stress and pressure.

I don't have anything to quantify it for the community as a whole, but
at least for me, I don't think I've ever had fewer free cycles. I
suspect that's the case for many of us. So I don't think that it's
unreasonable to set the revert bar a bit lower this year.

David


Reply via email to