* Daniel P. Berrangé (berra...@redhat.com) 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 / dgilb...@redhat.com / Manchester, UK
