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

[Dr. David Alan Gilbert]

* Daniel P. Berrangé (address@hidden) wrote:
> 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.

I'd agree; and I'd also find it useful to have runners setup for
Gitlab CI for related things (it would be useful for the virtio-fs
stuff);  if there are problems on other architectures then we should
find some go wranglers to go fix it.

Dave

> 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 :|
> 
--
Dr. David Alan Gilbert / address@hidden / Manchester, UK