From: Nico Williams <nico@cryptonector.com>
To: Thomas Munro <thomas.munro@enterprisedb.com>
Cc: Robbie Harwood <rharwood@redhat.com>
Cc: PostgreSQL mailing lists <pgsql-hackers@postgresql.org>
Cc: Michael Paquier <michael.paquier@gmail.com>
Cc: Stephen Frost <sfrost@snowman.net>
Subject: Re: [PATCH v16] GSSAPI encryption support
Date: Thu, 7 Jun 2018 18:04:21 -0500
Message-ID: <20180607230420.GF24501@localhost> (raw)
In-Reply-To: <CAEepm=0E8ga2McBB8fuC92+R0Hj=4TxR3kWR2fpJkwGSbcZF4g@mail.gmail.com>
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>
On Fri, Jun 08, 2018 at 10:11:52AM +1200, Thomas Munro wrote:
> On Fri, Jun 8, 2018 at 9:00 AM, Nico Williams <nico@cryptonector.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.
> The AppVeyor one is not good enough to propose just yet: it's
> cargo-culted and skips a test that doesn't pass and only runs the
> basic check tests (not contribs, isolation, TAP etc). Fortunately
> Andrew Dunstan has recently figured out how to run the official build
> farm script inside AppVeyor[1], and it looks like we might be close to
> figuring out that one test that doesn't work. That makes me wonder if
> we should get the Travis version to use the build farm scripts too.
> If we can get all of that sorted out, then yes, I would like to
> propose that we stick the .XXX.yml files in the tree. Another thing
> not yet explored is Travis's macOS build support.
I use AppVeyor for Heimdal and for jq... Maybe I can help out.
As for Travis' OS X support... the problem there is that their build
farm is very small, so using theirs means waiting and waiting.
> Someone might argue that we shouldn't depend on particular external
> services, or that there are other CI services out there and we should
> use those too/instead for some reason, or that we don't want all that
> junk at top level in the tree. But it seems to me that as long as
> they're dot prefixed files, we could carry control files for any
> number of CI services without upsetting anyone. Having them in the
> tree would allow anyone who has a publicly accessible git repo
> (bitbucket, GitHub, ...) to go to any CI service that interests them
> and enable it with a couple of clicks.
Carrying the .yml files causes no harm beyond dependence, but that's a
nice problem to have when the alternative is to not have a CI at all.
> Then cfbot would still need to create new branches automatically (that
> is fundamentally what it does: converts patches on the mailing list
> into branches on GitHub), but it wouldn't need to add those control
> files anymore, just the submitted patches.
You wouldn't need it to. Instead the CF page could let submitters link
their CI status pages/buttons...
> > Is there a way to get my CF entry building in cfbot, or will it get
> > there when it gets there?
>
> Urgh, due to a bug in my new rate limiting logic it stopped pushing
> new branches for a day or two. Fixed, and I see it's just picked up
> your submission #1319. Usually it picks things up within minutes (it
> rescans threads whenever the 'last mail' date changes on the
> Commitfest web page), and then also rechecks each submission every
> couple of days.
Thanks!
> In a nice demonstration of the complexity of these systems, I see that
> the build for your submission on Travis failed because apt couldn't
> update its package index because repo.mongodb.org's key has expired.
> Other recent builds are OK so that seems to be a weird transient
> failure; possibly out of data in some cache, or some fraction of their
> repo server farm hasn't been updated yet or ... whatever. Bleugh.
Oof.
> > I know I can just apply your patch, push to my fork, and have Travis and
> > AppVeyor build it. And I just might, but cfbot is a neato service!
>
> Thanks. The next step is to show cfbot's results in the Commitfest
> app, and Magnus and I have started working on that. I gave a talk
> about all this at PGCon last week, and the slides are up[2] in case
> anyone is interested:
OK. I think that will be a huge improvement. I find CF to be fantastic
as it is, but this will make it even better.
Thanks,
Nico
--
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: nico@cryptonector.com, thomas.munro@enterprisedb.com, rharwood@redhat.com, michael.paquier@gmail.com, sfrost@snowman.net
Subject: Re: [PATCH v16] GSSAPI encryption support
In-Reply-To: <20180607230420.GF24501@localhost>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox