Re: renaming configure.in to configure.ac

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: renaming configure.in to configure.ac
Дата
Msg-id 20200717062904.GB452830@rfd.leadboat.com
обсуждение исходный текст
Ответ на Re: renaming configure.in to configure.ac  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Ответы Re: renaming configure.in to configure.ac  (ilmari@ilmari.org (Dagfinn Ilmari Mannsåker))
Список 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 по дате отправления:

Предыдущее
От: "k.jamison@fujitsu.com"
Дата:
Сообщение: RE: Parallel Seq Scan vs kernel read ahead
Следующее
От: Laurenz Albe
Дата:
Сообщение: Re: Transactions involving multiple postgres foreign servers, take 2