Re: ABI Compliance Checker GSoC Project

Mankirat Singh <mankiratsingh1315@gmail.com> writes:
> Here, I had a proposal: In case an ABI break is found, then loop
> through the commits after the last run to find the offending commit.
> We can also give the animal owner the option to decide whether they
> want to use their own machine to perform this search or not. Let me
> know your thoughts on this.

On reflection, assuming that this is being run by one or more
buildfarm animals, there are not likely to be so many commits
between runs that it'll be hard to assign blame after a breakage.
So I'm not convinced that we need to build the logic you describe.

What we do need to think about perhaps is how we identify
the reference commit to compare ABI with.  In stable branches
it might be sufficient to say "the reference is the last
tagged commit in this branch", since we only tag known-good
release points.  I'm less sure that that rule works for a
branch that's currently in beta, since it's quite likely that
there will be ABI breaks that we are willing to accept.
(I guess that that scenario could happen for stable branches
too, though rarely.)  If that happens, it'd be nice to be able
to silence the complaints sooner than the next release point.

One way to solve that without additional mechanism is to say
"a tag is a tag; if you want to deem some commit good just
tag it with a tag that doesn't look like a release tag".
This feels a little icky somehow but I guess it could work.
We'd probably want some documented convention for how to
name such non-release-point ABI-blessing tags.

Alternatively, does git have any kind of metadata that isn't
a tag but acts sort of like one?  The fact that you cannot
move or remove a tag once pushed could come back to bite us
if we start using them for this purpose.

Another idea could be an in-tree file, different in each branch,
that records the hash of the commit we presently want to compare to.
This would require a small amount of additional manual effort to
maintain, but maybe it's the most flexible way.  Notably, we could
say that if the file isn't present in a given branch then we don't
want any ABI checking, whereas with the tag approach I think we'd
need some hard-coded rule about which branches to ignore.

Sorry about the thinking-out-loud character of this message.
Of the ideas I've thought of, the in-tree file is appealing
to me the most, but maybe somebody else has a better idea.

            regards, tom lane