Re: longfin and tamandua aren't too happy but I'm not sure why

On Wed, Sep 28, 2022 at 1:48 AM Thomas Munro <thomas(dot)munro(at)gmail(dot)com> wrote:
> FTR CI reported that cpluspluscheck failure and more[1], so perhaps we
> just need to get clearer agreement on the status of CI, ie a policy
> that CI had better be passing before you get to the next stage. It's
> still pretty new...

Yeah, I suppose I have to get in the habit of looking at CI before
committing anything. It's sort of annoying to me, though. Here's a
list of the follow-up fixes I've so far committed:

1. headerscheck
2. typos
3. pg_buffercache's meson.build
4. compiler warning
5. alignment problem
6. F_INTEQ/F_OIDEQ problem

CI caught (1), (3), and (4). The buildfarm caught (1), (5), and (6).
The number of buildfarm failures that I would have avoided by checking
CI is less than the number of extra things I had to fix to keep CI
happy, and the serious problems were caught by the buildfarm, not by
CI. It's not even clear to me how I was supposed to know that every
future Makefile change is going to require adjusting a meson.build
file as well. It's not like that was mentioned in the commit message
for the meson build system, which also has no README anywhere in the
source tree. I found the wiki page by looking up the commit and
finding the URL in the commit message, but, you know, that wiki page
ALSO doesn't mention the need to now update meson.build files going
forward. So I guess the way you're supposed to know that you need to
update meson.build that is by looking at CI, but CI is also the only
reason it's necessary to carry about meson.build in the first place. I
feel like CI has not really made it in any easier to not break the
buildfarm -- it's just provided a second buildfarm that you can break
independently of the first one.

And like the existing buildfarm, it's severely under-documented.

--
Robert Haas
EDB: http://www.enterprisedb.com