Re: Call for GSoC internship project ideas

["Alex Bennée" <alex.bennee@linaro.org>]

Thomas Huth <thuth@redhat.com> writes:

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

My intention was to get the test images as part of buildroots own
testing setup and re-use them for QEMU.

>
>  Thomas
>
>
>  Thomas

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro