On Thu, Jan 22, 2026 at 12:05:14PM +0100, Thomas Huth wrote: > On 22/01/2026 11.48, Daniel P. Berrangé wrote: > > On Thu, Jan 22, 2026 at 11:43:35AM +0100, Thomas Huth wrote: > > > On 22/01/2026 11.14, Daniel P. Berrangé wrote: > > > > On Tue, Jan 20, 2026 at 04:42:38PM -0500, Stefan Hajnoczi wrote: > > > > > Hi Marc-André, > > > > > I haven't seen discussion about the project ideas you posted, so I'll > > > > > try to kick it off here for the mkosi idea here. > > > > > > > > > > Thomas: Would you like to co-mentor the following project with > > > > > Marc-André? Also, do you have any concerns about the project idea from > > > > > the maintainer perspective? > > > > > > I'm fine with co-mentoring the project, but could you do me a favour and > > > add > > > some wording about AI tools to > > > https://wiki.qemu.org/Google_Summer_of_Code_2026 to set the expectations > > > right? Since we don't allow AI generated code in QEMU, I'd appreciate if > > > we > > > could state this in a prominent place here to avoid that some people think > > > they could get some quick money here by using AI tools, just to finally > > > discover that AI generated code is not allowed in the QEMU project. > > > Thanks! > > > > > > > IMHO, our baseline for functional testing images ought to be > > > > a Linux Kconfig recipe used to build a dedicate kernel, plus > > > > a busybox build for the target. > > > > > > Not sure if we want to add kernel compilation time to the functional tests > > > (even if it's only done once during the initial build)...? That could > > > easily > > > sum up to a couple of hours for a fresh checkout of QEMU... > > > > That's absolutely *NOT* what I was suggesting. > > > > We should have a 'qemu-test-images.git' repository that maintains all > > the recipes, with CI jobs to build and publish them (along with > > corresponding > > source). Those prebuilt images would be consumed by QEMU functional tests. > > This would be quicker than what we have today, as the images downloaded by > > functional tests could be an order of magnitude smaller, and boot more > > quickly too. > > Ah, sorry for getting that wrong! > > Ok, so this sounds basically just like a gitlab-CI wrapper around what > buildroot.org already provides. ... not sure whether that's challenging > enough for a GSoC project?
Given the number of machines we have, it is certainly time consuming enough to figure out the build for each one, and integrate it with the functional test. Not massively mentally challenging, but that's not a bad thing for GSoC. > Also, adding this as a separate repository will easily burn your gitlab-CI > minutes if you don't have a dedicated runner for this, so developing this > feature might be no fun at all... I'd expect most of the work would be on a local machine to construct and test images for all the different machines and validate them in functional tests. The integration into GitLab CI is a small-ish part which could be validated with just a couple of images, so you'd only burn major CI credits towards the end when needing to do a full run across all images. 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 :|
