All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: "Peter Maydell" <peter.maydell@linaro.org>,
	"Thomas Huth" <thuth@redhat.com>,
	qemu-devel <qemu-devel@nongnu.org>,
	"Richard Henderson" <richard.henderson@linaro.org>,
	"Andrew Jones" <drjones@redhat.com>,
	"Wainer dos Santos Moschetta" <wainersm@redhat.com>,
	"Philippe Mathieu-Daudé" <f4bug@amsat.org>,
	"Stefan Hajnoczi" <stefanha@redhat.com>,
	"Cleber Rosa" <crosa@redhat.com>,
	"Marc-André Lureau" <marcandre.lureau@redhat.com>,
	"Alex Bennée" <alex.bennee@linaro.org>
Subject: Re: Serious doubts about Gitlab CI
Date: Tue, 30 Mar 2021 14:27:51 +0100	[thread overview]
Message-ID: <YGMnVy4LDHu28wW4@redhat.com> (raw)
In-Reply-To: <23fcbe91-1b9c-559d-1a61-6cce839bb390@redhat.com>

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



  reply	other threads:[~2021-03-30 13:33 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-17 20:29 Serious doubts about Gitlab CI Philippe Mathieu-Daudé
2021-03-18  1:28 ` Bin Meng
2021-03-18  8:55   ` Philippe Mathieu-Daudé
2021-03-18  9:33 ` Daniel P. Berrangé
2021-03-18  9:50   ` Philippe Mathieu-Daudé
2021-03-18 10:28     ` Philippe Mathieu-Daudé
2021-03-19  5:34       ` Thomas Huth
2021-03-18 19:46 ` Stefan Hajnoczi
2021-03-18 19:52   ` John Snow
2021-03-18 20:53     ` Philippe Mathieu-Daudé
2021-03-18 20:30   ` Paolo Bonzini
2021-03-19  9:33     ` Stefan Hajnoczi
2021-03-19  9:41       ` Paolo Bonzini
2021-03-19 11:44         ` Philippe Mathieu-Daudé
2021-03-19 10:18       ` Andrew Jones
2021-03-19 10:59         ` Paolo Bonzini
2021-03-19 11:34           ` Philippe Mathieu-Daudé
2021-03-19 15:27             ` Wainer dos Santos Moschetta
2021-03-29 14:10               ` Stefan Hajnoczi
2021-03-30 11:19                 ` Daniel P. Berrangé
2021-03-30 11:55                   ` Thomas Huth
2021-03-30 12:09                     ` Paolo Bonzini
2021-03-30 12:23                       ` Philippe Mathieu-Daudé
2021-03-30 12:45                         ` Paolo Bonzini
2021-03-30 13:12                           ` Daniel P. Berrangé
2021-03-30 13:19                             ` Paolo Bonzini
2021-03-30 13:27                               ` Daniel P. Berrangé [this message]
2021-03-30 15:59                                 ` Warner Losh
2021-03-30 16:11                                   ` Peter Maydell
2021-03-30 16:24                                     ` Warner Losh
2021-03-30 16:10                                 ` Thomas Huth
2021-03-30 13:09                       ` Daniel P. Berrangé
2021-03-30 12:09                     ` Paolo Bonzini
2021-03-30 12:19                     ` Peter Maydell
2021-03-30 12:33                     ` Philippe Mathieu-Daudé
2021-03-30 13:19                     ` Daniel P. Berrangé
2021-03-31  7:54                       ` Thomas Huth
2021-03-31  9:31                         ` Andrea Bolognani
2021-03-30 14:13                     ` Stefan Hajnoczi
2021-03-30 14:23                       ` Paolo Bonzini
2021-03-30 14:30                         ` Daniel P. Berrangé
2021-03-30 14:09                   ` Stefan Hajnoczi
2021-03-19 12:07         ` Markus Armbruster
2021-03-19 13:06           ` Thomas Huth

Reply instructions:

You may reply publicly 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=YGMnVy4LDHu28wW4@redhat.com \
    --to=berrange@redhat.com \
    --cc=alex.bennee@linaro.org \
    --cc=crosa@redhat.com \
    --cc=drjones@redhat.com \
    --cc=f4bug@amsat.org \
    --cc=marcandre.lureau@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peter.maydell@linaro.org \
    --cc=qemu-devel@nongnu.org \
    --cc=richard.henderson@linaro.org \
    --cc=stefanha@redhat.com \
    --cc=thuth@redhat.com \
    --cc=wainersm@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
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.