Re: Serious doubts about Gitlab CI

[Daniel P . Berrangé]

On Tue, Mar 30, 2021 at 03:19:49PM +0200, Paolo Bonzini wrote:
> On 30/03/21 15:12, Daniel P. Berrangé wrote:
> > > Now, but that may change already in 6.1 in order to add CFI support.
> > We can bundle a newer version, but we don't need to require a newer
> > version. Simply conditional compile for the bits we need. If distro
> > slirp is too old, then sorry, you can't enable CFI + slirp at the
> > same time. If the distro really wants that combination we don't have
> > to own the solution - the distro should update their slirp.
> > 
> > Or to put it another way, QEMU doesn't need to go out of its way to
> > enable new features on old distros. We merely need to not regress
> > in the features we previously offered.  We bundled slirp as a submodule
> > so that old distros didn't loose slirp entirely. We don't need to
> > offer CFI on those distros.
> 
> This is true, on the other hand only having to support one API version has
> its benefits.  The complication in the build system is minimal once slirp is
> made into a subproject; therefore it is appealing to keep the QEMU code
> simple.

I don't think slirp is special in this regard. The benefit you're promoting
here applies to any dependancy we have, but I think the benefit is not big
enough to justify.

The use of submodules has imposed significant pain on QEMU developers over
the years, and as such I think our general goal should be to have zero git
submodules over the long term. Usage of submodules ought to be considered
a short term workaround only, with a clear criteria for removal. We should
continually introduce dependancies on newer & newer versions, as that means
we'll never have any opportunity to remove them and reduce the cost on
QEMU.

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 :|