Re: renaming configure.in to configure.ac

From: Noah Misch <noah(at)leadboat(dot)com>
To: Dagfinn Ilmari Mannsåker <ilmari(at)ilmari(dot)org>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, 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 06:29:04
Message-ID: 20200717062904.GB452830@rfd.leadboat.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
> Noah Misch <noah(at)leadboat(dot)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.)

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Laurenz Albe 2020-07-17 06:49:08 Re: Transactions involving multiple postgres foreign servers, take 2
Previous Message k.jamison@fujitsu.com 2020-07-17 06:05:17 RE: Parallel Seq Scan vs kernel read ahead