Re: renaming configure.in to configure.ac

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Magnus Hagander <magnus(at)hagander(dot)net>
Cc: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>, Noah Misch <noah(at)leadboat(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: renaming configure.in to configure.ac
Date: 2020-07-17 15:18:44
Message-ID: 3553421.1594999124@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Magnus Hagander <magnus(at)hagander(dot)net> writes:
> That one does more or less what Dagfinn suggests except in a separate repo.
> We could also just have a separate repo for it where people could push if
> we wanted to. Which could be committers, or others. But in comparison with
> what Perl does, I would assume actually having "just committers"be able to
> push would really be enough for that. A committer should be able to judge
> whether a patch needs extra cross-platform testing (and the cfbot does just
> fine for the limited platforms it runs on, which would still be good enough
> for *most* patches).

By and large, once a patch has reached that stage, we just push it to
master and deal with any fallout. I suppose you could argue that
pushing to a testing branch first would reduce the amount of time that
HEAD is broken, but TBH I think it would not help much. An awful lot
of the stuff that breaks the buildfarm is patches that the committer
was not expecting trouble with.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2020-07-17 15:26:56 Re: Which SET TYPE don't actually require a rewrite
Previous Message David G. Johnston 2020-07-17 15:16:50 Re: Patch for reorderbuffer.c documentation.