On Fri, Mar 08, 2019 at 02:09:53PM +0100, Laszlo Ersek wrote: > Hi, > > I have a mostly-ready-for-posting patch set for $SUBJECT. My question is > what QEMU release I should be targeting with it. > > The Soft Feature Freeze for 4.0 is on 2019-03-12. Here's why that's a > bit inconvenient for me. > > The upcoming EDK2 stable release is edk2-stable201903, and it is planned > for... today. > > > https://github.com/tianocore/tianocore.github.io/wiki/EDK-II-Release-Planning#edk2-stable201903-tag-planning > > But, it's being blocked (at least one CVE fix still needs merging, but > there could be something else too). I don't know what that will mean for > the actual tag date. Maybe next Monday (the 11th)? > > In my series, I'd like to advance QEMU's roms/edk2 submodule to this new > release. But that might leave us with 1 day before the QEMU 4.0 Soft > Feature Freeze (see above), i.e., for me to post the series, and for a > submaintainer to send a pullreq with it. That's a bit too tight.
IMHO if you advanced the submodule hash to a nearly-released version before freeze, it would be fine to then advance it again to the actually released commit hash during QEMU freeze, because presumably the EDK changes are similarly bugfix only at this point in its release process. > > I'm not in a mortal rush to get this into 4.0, but the next release > cycles (in three months, approximately?) might align similarly, between > edk2 and QEMU. It would be best to avoid QEMU carrying edk2 platform > firmware that is at all times at least three months old. The main reason > is that CVEs tend to exist, for both edk2 proper, and for the specific > OpenSSL release that is bundled with the given edk2 stable tag. And edk2 > doesn't yet have stable *branches*. > > Should we try to squeeze my set into 4.0 (possibly moving the Soft > Feature Freeze), or just aim for 4.1? > > Also, who'd be the maintainer to queue my set? I mostly thought of Gerd, > due to his work on iPXE and SeaBIOS. Here's the current diffstat: > > Makefile | 17 +- > pc-bios/README | 11 + > pc-bios/descriptors/50-edk2-i386-secure.json | 34 +++ > pc-bios/descriptors/50-edk2-x86_64-secure.json | 35 +++ > pc-bios/descriptors/60-edk2-aarch64.json | 31 +++ > pc-bios/descriptors/60-edk2-arm.json | 31 +++ > pc-bios/descriptors/60-edk2-i386.json | 33 +++ > pc-bios/descriptors/60-edk2-x86_64.json | 34 +++ > pc-bios/edk2-aarch64-code.fd | Bin 0 -> 67108864 bytes > pc-bios/edk2-arm-code.fd | Bin 0 -> 67108864 bytes > pc-bios/edk2-arm-vars.fd | Bin 0 -> 67108864 bytes > pc-bios/edk2-i386-code.fd | Bin 0 -> 3653632 bytes > pc-bios/edk2-i386-secure-code.fd | Bin 0 -> 3653632 bytes > pc-bios/edk2-i386-vars.fd | Bin 0 -> 540672 bytes > pc-bios/edk2-licenses.txt | 209 +++++++++++++++ > pc-bios/edk2-x86_64-code.fd | Bin 0 -> 3653632 bytes > pc-bios/edk2-x86_64-secure-code.fd | Bin 0 -> 3653632 bytes Yikes, am I really reading those sizes right ? The biggest ROMs there are 64 MB, so this is proposing to add ~206 MB of binaries to the pc-bios directory ? I think this is a very undesirable thing to do. Consider that we'll need to refresh those ROMs multiple times a year to track updates or security fixes. It will result in our .git repo size growing massively over time. I don't think people will like cloning multi-GB sized repos after a few years of ROM updates. As I've mentioned before, I think QEMU should get out of the business of distributing ROMs in its primary released qemu-x.x.x.tar.gz archives, and provide them as a separate tar.gz bundle. Even better if we can move the existing ROMS out of git too, though we have to consider how developers biulding from git would access the ROMs & know when they need to acquire new copies. The main important things to version control are the build config and the git submodule version information. 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 :|
