On Tue, Feb 27, 2024 at 8:25 AM Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
> The way I see this working, is that we set up a buildfarm animal [per
> architecture] that runs the new rules produced by the abidw option and
> stores the result locally, so that for stable branches it can turn red
> when an ABI-breaking change with the previous minor release of the same
> branch is introduced. There's no point on it ever turning red in the
> master branch, since we're obviously not concerned with ABI changes there.
ABI stability doesn't seem like something that you can alert on. There
are quite a few individual cases where the ABI was technically broken,
in a way that these tools will complain about. And yet it was
generally understood that these changes did not really break ABI
stability, for various high-context reasons that no tool can possibly
be expected to understand. This will at least be true under our
existing practices, or anything like them.
For example, if you look at the "Problems with Symbols, High Severity"
from the report I posted comparing REL_11_0 to REL_11_20, you'll see
that I removed _bt_pagedel() when backpatching a fix. That was
justified by the fact that any extension that was calling that
function was already hopelessly broken (I pointed this out at the
time).
Having some tooling in this area would be extremely useful. The
absolute number of false positives seems quite manageable, but the
fact is that most individual complaints that the tooling makes are
false positives. At least in some deeper sense.
--
Peter Geoghegan
