|From:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>|
|To:||Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>|
|Cc:||Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, David Steele <david(at)pgmasters(dot)net>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, "Tsunakawa, Takayuki" <tsunakawa(dot)takay(at)jp(dot)fujitsu(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Adam Brightwell <adam(dot)brightwell(at)crunchydata(dot)com>|
|Subject:||Re: PATCH: Configurable file mode mask|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com> writes:
> On 1/19/18 16:54, Alvaro Herrera wrote:
>> If the only problem is that buildfarm would run tests twice, then I
>> think we should just press forward with this regardless of that: it
>> seems a chicken-and-egg problem, because buildfarm cannot be upgraded to
>> use some new test method if the method doesn't exist yet. As a
>> solution, let's just live with some run duplication for a period until
>> the machines are upgraded to a future buildfarm client code.
> Well, people protested against that approach.
I think I was one of the complainers, but my objection was pretty
straightforward. I want the buildfarm script update to be available
more or less contemporaneously with the change going into git.
Some owners might not care if their machines are doing lots of
extra work, but for those that do, we shouldn't leave them stuck
until a buildfarm update appears in some indefinite future.
In short: get Dunstan into the loop. Don't push this till he's
signed off on new buildfarm code.
regards, tom lane
|Next Message||Peter Eisentraut||2018-01-23 16:51:27||Re: PATCH: Configurable file mode mask|
|Previous Message||Tom Lane||2018-01-23 16:46:48||Re: [HACKERS] Refactor handling of database attributes between pg_dump and pg_dumpall|