Re: Adding CI to our tree

On Sun, Feb 13, 2022 at 3:30 AM Andres Freund <andres(at)anarazel(dot)de> wrote:
> > There's other things that it'd be nice to enable, but maybe these don't need to
> > be on by default. Maybe just have a list of optional compiler flags (and hints
> > when they're useful). Like WRITE_READ_PARSE_PLAN_TREES.
>
> I think it'd be good to enable a reasonable set by default. Particularly for
> newer contributors stuff like forgetting in/out/readfuncs, or not knowing
> about some undefined behaviour, is easy. Probably makes sense to use different
> settings on different tasks.

This is exactly why I'm not a huge fan of having ci stuff in the tree.
It supposes that there's one right way to do a build, but in reality,
different people want and indeed need to use different options for all
kinds of reasons. That's the whole value of having things like
configure and pg_config_manual.h. When we start arguing about whether
or ci builds should use -DWRITE_READ_PARSE_PLAN_TREES we're inevitably
into the realm where no choice is objectively better, and whoever
yells the loudest will get it the way they want, and then somebody
else later will say "well that's dumb I don't like that" or even just
"well that's not the right thing for testing MY patch," at which point
the previous mailing list discussion will be cited as "precedent" for
what was essentially an arbitrary decision made by 1 or 2 people.

Mind you, I'm not trying to hold back the tide. I realize that in-tree
ci stuff is very much in vogue. But I think it would be a very healthy
thing if we acknowledged that what goes in there is far more arbitrary
than most of what we put in the tree.

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