[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] more automated/public CI for QEMU pullreqs
From: |
Daniel P . Berrangé |
Subject: |
Re: [Qemu-devel] more automated/public CI for QEMU pullreqs |
Date: |
Thu, 22 Aug 2019 12:47:47 +0100 |
User-agent: |
Mutt/1.12.0 (2019-05-25) |
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 :|
- [Qemu-devel] more automated/public CI for QEMU pullreqs, Peter Maydell, 2019/08/16
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Stefan Hajnoczi, 2019/08/22
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs,
Daniel P . Berrangé <=
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Dr. David Alan Gilbert, 2019/08/22
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Paolo Bonzini, 2019/08/22
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Dr. David Alan Gilbert, 2019/08/22
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Paolo Bonzini, 2019/08/22
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Philippe Mathieu-Daudé, 2019/08/23
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Alex Bennée, 2019/08/24
- Re: [Qemu-devel] more automated/public CI for QEMU pullreqs, Daniel P . Berrangé, 2019/08/22