Received: from malur.postgresql.org ([2a02:16a8:dc51::56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fR3xJ-0003Ym-09 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jun 2018 23:04:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1fR3xG-00018K-55 for pgsql-hackers@arkaria.postgresql.org; Thu, 07 Jun 2018 23:04:30 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.89) (envelope-from ) id 1fR3xF-000189-QV for pgsql-hackers@lists.postgresql.org; Thu, 07 Jun 2018 23:04:29 +0000 Received: from homie-sub4.mail.dreamhost.com ([69.163.253.135] helo=homiemail-a89.g.dreamhost.com) by makus.postgresql.org with esmtps (TLS1.1:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1fR3xB-0000LY-NL for pgsql-hackers@postgresql.org; Thu, 07 Jun 2018 23:04:27 +0000 Received: from homiemail-a89.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTP id 40B0DD000B34; Thu, 7 Jun 2018 16:04:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=cryptonector.com; h=date :from:to:cc:subject:message-id:references:mime-version :content-type:in-reply-to; s=cryptonector.com; bh=8yYCawZJqqD2FJ GDwwE5UBWnR74=; b=ShDXcw4QLHNJZnZyOcJ14BTlRiW4UHhwIONfTgeikHjwNw 0Km4hMUIponyMpSoVrkU9U74gJvfVv7ZaV3zTnm8mkXBAGZxORx3YUBuGh/cPHeT HId8wDgURY5JhzfrF+p3Qv9VdJtmUh3kEtgA/xWUSzV14Al15TW+DnhE8OR9c= Received: from localhost (unknown [8.2.105.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: nico@cryptonector.com) by homiemail-a89.g.dreamhost.com (Postfix) with ESMTPSA id 66562D000B31; Thu, 7 Jun 2018 16:04:22 -0700 (PDT) Date: Thu, 7 Jun 2018 18:04:21 -0500 From: Nico Williams To: Thomas Munro Cc: Robbie Harwood , PostgreSQL mailing lists , Michael Paquier , Stephen Frost Subject: Re: [PATCH v16] GSSAPI encryption support Message-ID: <20180607230420.GF24501@localhost> References: <20180607210058.GE24501@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk On Fri, Jun 08, 2018 at 10:11:52AM +1200, Thomas Munro wrote: > On Fri, Jun 8, 2018 at 9:00 AM, Nico Williams 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 --