On Wed, Sep 28, 2022 at 1:48 AM Thomas Munro <thomas.mu...@gmail.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
