QEMU-Devel Archive on lore.kernel.org
 help / color / Atom feed
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
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 :|


  parent reply index

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16 18:16 Peter Maydell
2019-08-22 10:49 ` Stefan Hajnoczi
2019-08-22 11:04   ` Peter Maydell
2019-08-22 11:14     ` Paolo Bonzini
2019-09-30 12:53   ` Peter Maydell
2019-10-04  9:31     ` Stefan Hajnoczi
2019-08-22 11:47 ` Daniel P. Berrangé [this message]
2019-08-22 16:31   ` [Qemu-devel] " Dr. David Alan Gilbert
2019-08-22 16:48     ` Paolo Bonzini
2019-08-22 16:50       ` Dr. David Alan Gilbert
2019-08-22 17:05         ` Paolo Bonzini
2019-08-23 13:15           ` Philippe Mathieu-Daudé
2019-08-24  7:44             ` Alex Bennée
2019-08-22 17:03       ` Daniel P. Berrangé

Reply instructions:

You may reply publically to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190822114747.GS3267@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=kchamart@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=philmd@redhat.com \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=sameo@linux.intel.com \
    --cc=stefanha@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

QEMU-Devel Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/qemu-devel/0 qemu-devel/git/0.git
	git clone --mirror https://lore.kernel.org/qemu-devel/1 qemu-devel/git/1.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 qemu-devel qemu-devel/ https://lore.kernel.org/qemu-devel \
		qemu-devel@nongnu.org qemu-devel@archiver.kernel.org
	public-inbox-index qemu-devel

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.nongnu.qemu-devel


AGPL code for this site: git clone https://public-inbox.org/ public-inbox