Re: [Qemu-devel] more automated/public CI for QEMU pullreqs

From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Peter Maydell <peter.maydell@linaro.org>
Cc: "Samuel Ortiz" <sameo@linux.intel.com>,
	"Kashyap Chamarthy" <kchamart@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"QEMU Developers" <qemu-devel@nongnu.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Paolo Bonzini" <pbonzini@redhat.com>,
	"Philippe Mathieu-Daudé" <philmd@redhat.com>
Subject: Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
Date: Thu, 22 Aug 2019 12:47:47 +0100	[thread overview]
Message-ID: <20190822114747.GS3267@redhat.com> (raw)
In-Reply-To: <CAFEAcA8kEKVcRu62+VGDkzRj2J87QPxzjg05dCHszeBC6X76pg@mail.gmail.com>

On Fri, Aug 16, 2019 at 07:16:55PM +0100, Peter Maydell wrote:
> The two major contenders suggested were:
> 
> (1) GitLab CI, which supports custom 'runners' which we can set
> up to run builds and tests on machines we have project access to
> 
> (2) Patchew, which can handle running tests on multiple machines (eg
> we do s390 testing today for all patches on list), and which we could
> enhance to provide support for the release-manager to do their work
> 
> Advantages of Gitlab CI:
>  * somebody else is doing the development and maintainance of the
>    CI tool -- bigger 'bus factor' than patchew
>  * already does (more or less) what we want without needing
>    extra coding work
> 
> Advantages of Patchew:
>  * we're already using it for patch submissions, so we know it's
>    not going to go away
>  * it's very easy to deploy to a new host
>  * no dependencies except Python, so works anywhere we expect
>    to be able to build QEMU (whereas gitlab CI's runner is
>    written in Go, and there seem to be ongoing issues with getting
>    it actually to compile for other architectures than x86)

IMHO the development tools/processes chosen should enable the project
contributors to maximise the time they can put into developing useful
features for QEMU itself. Time we spend writing CI systems like patchew
is time we're taking away from writing QEMU features, unless the new CI
system offers major efficiency benefits over other existing solutions.

A second important aspect is that to enable a smooth/shallow onramp
for new contributors it is useful to have our development processes
and tools be familiar to those with general open source dev experience
outside QEMU.

With both these points in mind, I think it is  pretty hard sell to
say we should write & maintain a custom CI system just for QEMU
unless it is offering major compelling functionality we can't do
without.

IOW, I'd be biased in favour of GitLab CI.

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|