qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: "Daniel P. Berrangé" <berrange@redhat.com>
To: Thomas Huth <thuth@redhat.com>
Cc: Stefan Hajnoczi <stefanha@redhat.com>,
	Michael Roth <michael.roth@amd.com>,
	qemu-devel@nongnu.org, Gerd Hoffmann <kraxel@redhat.com>,
	Peter Maydell <peter.maydell@linaro.org>,
	Paolo Bonzini <pbonzini@redhat.com>,
	Richard Henderson <richard.henderson@linaro.org>
Subject: Re: [PATCH v2 for-8.0 0/5] scripts/make-release: Decrease size of the release tarballs
Date: Mon, 28 Nov 2022 17:04:16 +0000	[thread overview]
Message-ID: <Y4TqEDYs+T4z6PX/@redhat.com> (raw)
In-Reply-To: <20221128092555.37102-1-thuth@redhat.com>

On Mon, Nov 28, 2022 at 10:25:50AM +0100, Thomas Huth wrote:
> Our release tarballs are huge - qemu-7.2.0-rc2.tar.xz has a size of 116
> MiB. If you look at the contents, approx. 80% of the size is used for the
> firmware sources that we ship along to provide the sources for the ROM
> binaries. This feels very wrong, why do we urge users to download such
> huge tarballs while 99.9% of them never will rebuilt the firmware sources?
> We were also struggeling a bit in the past already with server load and
> costs, so we should really try to decrease the size of our release tarballs
> to a saner level.

The main reason for shipping the source in the tarball was to
guarantee license compliance for anyone who is distributing
qemu release tarballs, including ourselves.

Splitting off the firmware source, but not the firmware binaries,
means people are now at risk of not complying with the license
but failing to provide complete and corresponding source.

Technically the license requirement is only critical for GPL
licenses ROMs, but as good practice we do it for all our ROMs.

> So let's split the firmware sources into a separate tarball to decrease
> the size of the main QEMU sources tarball a lot (which should help us
> to safe a lot of traffic on the server).

With my distro maintainer hat I would rather QEMU ship neither the
ROM source, nor the ROM binaries.

Still the binaries are convenient for people doing their own QEMU
builds from source.

How about shipping two distinct options:

  qemu-x.y.z.tar.xz          (QEMU source only)
  qemu-bundled-x.y.z.tar.xz  (QEMU source + bundled ROM binaries + ROM sources)

though I'm not sure how much of an impact that will have on the download
traffic - depends what is causing the traffic.

Another option is

  qemu-x.y.z.tar.xz        (QEMU source only)
  qemu-roms-x.y.z.tar.xz   (bundled ROM binaries + ROM sources)

though this is slightly more inconvenient for users, and there's the
risk they'll use new QEMU with old ROMs.


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



  parent reply	other threads:[~2022-11-28 17:04 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-28  9:25 [PATCH v2 for-8.0 0/5] scripts/make-release: Decrease size of the release tarballs Thomas Huth
2022-11-28  9:25 ` [PATCH v2 for-8.0 1/5] scripts/make-release: Add a simple help text for the script Thomas Huth
2022-11-28 16:47   ` Alex Bennée
2022-11-28  9:25 ` [PATCH v2 for-8.0 2/5] scripts/make-release: Only clone single branches to speed up " Thomas Huth
2022-11-28 16:54   ` Alex Bennée
2022-11-28  9:25 ` [PATCH v2 for-8.0 3/5] scripts/make-release: Remove CI yaml and more git files from the tarball Thomas Huth
2022-11-28 16:55   ` Alex Bennée
2022-11-28  9:25 ` [PATCH v2 for-8.0 4/5] roms: Add a README file with some basic information Thomas Huth
2022-11-28 16:58   ` Alex Bennée
2022-11-28  9:25 ` [PATCH v2 for-8.0 5/5] scripts/make-release: Move roms into separate tarball Thomas Huth
2022-11-28 16:51   ` Stefan Hajnoczi
2022-11-30 11:10     ` Thomas Huth
2022-11-28 16:58   ` Alex Bennée
2022-11-28 16:53 ` [PATCH v2 for-8.0 0/5] scripts/make-release: Decrease size of the release tarballs Stefan Hajnoczi
2022-11-28 17:04 ` Daniel P. Berrangé [this message]
2022-11-28 19:25   ` Paolo Bonzini
2022-11-29  8:12     ` Daniel P. Berrangé
2022-11-29 12:56       ` Paolo Bonzini
2022-11-30  9:39     ` Mark Cave-Ayland
2022-11-30 10:49   ` Thomas Huth
2022-11-30 12:09     ` Daniel P. Berrangé
2022-12-09  8:07       ` 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=Y4TqEDYs+T4z6PX/@redhat.com \
    --to=berrange@redhat.com \
    --cc=kraxel@redhat.com \
    --cc=michael.roth@amd.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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).