Re: renaming configure.in to configure.ac

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: ilmari(at)ilmari(dot)org (Dagfinn Ilmari Mannsåker )
Cc: 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 14:12:19
Message-ID: 3541570.1594995139@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

ilmari(at)ilmari(dot)org (Dagfinn Ilmari =?utf-8?Q?Manns=C3=A5ker?=) writes:
> Noah Misch <noah(at)leadboat(dot)com> writes:
>> On Thu, Jul 16, 2020 at 11:41:56AM +0100, Dagfinn Ilmari Mannsåker wrote:
>>> 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?

>> Potentially. What advantages and disadvantages has Perl experienced?

> The advantage is getting proposed changes tested on a number of
> platforms that individual developers otherwise don't have access to.
> For example http://perl.develop-help.com/?b=smoke-me%2Filmari%2Fremove-symbian
> shows the reults of one branch of mine.
> The only disadvantage is that it takes up more build farm capacity, but
> it's not used for all changes, only ones that developers are concerned
> might break on other platforms (e.g. affecting platform-specific code or
> constructs otherwise known to behave differently across platforms and
> compilers).

I'd argue that cluttering the main development repo with dead branches
is a non-negligible cost. We have one or two such left over from very
ancient days, and I don't really want more. (Is there a way to remove
a branch once it's been pushed to a shared git repo?)

Another issue is that we're not going to open up the main repo for
access by non-committers, so this approach doesn't help for most
developers. We've had some success, I think, with Munro's cfbot
solution --- I'd rather see that approach expanded to provide more
test environments.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Surafel Temesgen 2020-07-17 14:18:20 Re: WIP: System Versioned Temporal Table
Previous Message Magnus Hagander 2020-07-17 14:08:36 Re: Which SET TYPE don't actually require a rewrite