| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Thomas Munro <thomas(dot)munro(at)enterprisedb(dot)com> |
| Cc: | Nico Williams <nico(at)cryptonector(dot)com>, Robbie Harwood <rharwood(at)redhat(dot)com>, PostgreSQL mailing lists <pgsql-hackers(at)postgresql(dot)org>, Michael Paquier <michael(dot)paquier(at)gmail(dot)com>, Stephen Frost <sfrost(at)snowman(dot)net> |
| Subject: | Re: [PATCH v16] GSSAPI encryption support |
| Date: | 2018-06-11 13:27:17 |
| Message-ID: | CA+TgmoYmPutv1kiU7cbNp7MGCW0ECofVXoGNi6yYPMHB_8z=Mw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jun 7, 2018 at 6:11 PM, Thomas Munro
<thomas(dot)munro(at)enterprisedb(dot)com> wrote:
>> Cool! Is there any reason that your patch for Travis and AppVeyor
>> integration is not just committed to master?
>
> I think that's a good idea and I know that some others are in favour.
One problem is that was discussed at PGCon it commits us to one
particular build configuration i.e. one set of --with-whatever options
to configure. It's not bad to provide a reasonable set of defaults,
but it means that patches which are best tested with some other set of
values will have to modify the file (I guess?). Patches that need to
be tested with multiple sets of flags are ... maybe just out of luck?
I really don't understand the notion of putting the build script
inside the source tree. It's all fine if there's One Way To Do It but
often TMTOWTDII. If the build configurations are described outside
the source tree then you can have as many of them as you need.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Arturas Mazeika | 2018-06-11 13:35:34 | Fwd: pgAgent: ERROR: Couldn't register event handle. |
| Previous Message | David Rowley | 2018-06-11 13:20:06 | Re: Performance regression with PostgreSQL 11 and partitioning |