Re: renaming configure.in to configure.ac - Mailing list pgsql-hackers

From Noah Misch
Subject Re: renaming configure.in to configure.ac
Date
Msg-id 20200717062904.GB452830@rfd.leadboat.com
Whole thread Raw
In response to Re: renaming configure.in to configure.ac  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Responses Re: renaming configure.in to configure.ac
List pgsql-hackers
On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Wed, Jul 15, 2020 at 09:45:54AM -0400, Tom Lane wrote:
> >> Along the same line, I read at [1]
> >> 
> >>     Because it has been such a long time, and because some of the changes
> >>     potentially break existing Autoconf scripts, we are conducting a
> >>     public beta test before the final release of version 2.70.  Please
> >>     test this beta with your autoconf scripts, and report any problems you
> >>     find to the Savannah bug tracker:
> >> 
> >> Maybe we should do some pro-active testing, rather than just waiting for
> >> 2.70 to get dropped on us?  God knows how long it will be until 2.71.
> >
> > Sounds good.  A cheap option would be to regenerate with 2.70, push that on a
> > Friday night to see what the buildfarm thinks, and revert it on Sunday night.
> 
> Instead of doing this on the master branch, would it be worth defining a
> namespace for branches that the buildfarm tests in addition to master
> and REL_*_STABLE?
> 
> In the Perl world we have this in the form of smoke-me/* branches, and
> it's invaluable to be able to test things across many platforms without
> breaking blead (our name for the main development branch).

Potentially.  What advantages and disadvantages has Perl experienced?

(Given the support downthread for just changing master indefinitely, which is
fine with me, it's more likely this particular change won't use such a branch.
There have been and will be other changes that may benefit.)



pgsql-hackers by date:

Previous
From: "k.jamison@fujitsu.com"
Date:
Subject: RE: Parallel Seq Scan vs kernel read ahead
Next
From: Laurenz Albe
Date:
Subject: Re: Transactions involving multiple postgres foreign servers, take 2