Date: Mon, 11 Jun 2018 12:13:17 -0500
From: Nico Williams <nico@cryptonector.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Thomas Munro <thomas.munro@enterprisedb.com>,
	Robbie Harwood <rharwood@redhat.com>,
	PostgreSQL mailing lists <pgsql-hackers@postgresql.org>,
	Michael Paquier <michael.paquier@gmail.com>,
	Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v16] GSSAPI encryption support
Message-ID: <20180611171315.GA23356@localhost>
References: <jlg1tgq1ktm.fsf@thriss.redhat.com>
 <jlg1se287n3.fsf@redhat.com>
 <CAEepm=2NkNjV97hThgHOQjk9j719wjFxVozs9LVn3YqW9egFgw@mail.gmail.com>
 <jlg603c6chf.fsf@redhat.com>
 <jlgr2lz4l6l.fsf@redhat.com>
 <CAEepm=2+FbEJsVX5B6fYW7UBXpF6osaixSXn2A297WgP+rEhxA@mail.gmail.com>
 <20180607210058.GE24501@localhost>
 <CAEepm=0E8ga2McBB8fuC92+R0Hj=4TxR3kWR2fpJkwGSbcZF4g@mail.gmail.com>
 <CA+TgmoYmPutv1kiU7cbNp7MGCW0ECofVXoGNi6yYPMHB_8z=Mw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
 <CA+TgmoYmPutv1kiU7cbNp7MGCW0ECofVXoGNi6yYPMHB_8z=Mw@mail.gmail.com>
User-Agent: Mutt/1.5.24 (2015-08-30)
Precedence: bulk

On Mon, Jun 11, 2018 at 09:27:17AM -0400, Robert Haas wrote:
> On Thu, Jun 7, 2018 at 6:11 PM, Thomas Munro
> <thomas.munro@enterprisedb.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?

Hmm, that's not really true.  You can have a build and test matrix with
more than one row in it.

For example, look at: https://travis-ci.org/heimdal/heimdal

You'll see that Heimdal's Travis-CI integration has four builds:

 - Linux w/ GCC
 - Linux w/ Clang
 - OS X w/ Clang
 - Linux code coverage w/ GCC

We could easily add more options for Heimdal, if we felt we needed to
build and test more with Travis-CI.

Appveyor also has matrix support (though I'm not using it in Heimdal's
Appveyor-CI integration).

Now, of course if we had a very large set of configurations to test,
things might get slow, and the CIs might find it abusive.  It would be
best to use a maximal build configuration and go from there.  So, for
example, two configurations, one with and w/o JIT, but with all the
optional libraries (GSS, LDAP, ICU, Perl, Python, ...), and with two
different compilers (GCC and Clang, with Clang only for the JIT), plus
one OS X build (with JIT), and so on:

 - Linux w/ GCC
 - Linux w/ Clang (   JIT)
 - Linux w/ Clang (no JIT)
 - Linux code coverage
 - OS X  w/ Clang (   JIT)

and similarly for Windows on Appveyor.

> 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.

Well, all the free CIs like Travis and Appveyor do it this way.  You
don't have to *use* it just because the .yml files are in the source
tree.  But you have to have the .yml files in the source tree in order
to use these CIs.  It'd be nice to be able to point somewhere else for
them, but whatever, that's not something we get much choice in at this
time.

The .yml files are unobstrusive anyways, and it's handy to have them
in-tree anyways.  It also makes it easier to do things like:

 - get build passing/failing buttons on wiki / build status pages 

 - make sure that the .yml files stay up to date as the source tree gets
   changed

It also makes it somewhat easier to get hooked on github and such, but
a bit of discipline will make that a non-issue.

Nico
--