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?
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...
Thomas
Thomas
