Re: Hosting first-party kernel.org container images

[Guillaume Tucker <gtucker@gtucker.io>]

Hi Nathan et al,

On 10/03/2026 1:48 am, Nathan Chancellor wrote:
> Hi Guillaume,
> 
> On Wed, Feb 25, 2026 at 03:44:13PM +0100, Guillaume Tucker wrote:
>> This boils things down to a few practical options:
>>
>> 1. treating TuxMake images with kernel.org toolchains as the de facto
>>     stardard,
>>
>> 2. creating a repository from scratch on git.kernel.org with
>>     independent hosting for base images,
>>
>> 3. some middle ground to be defined which would remove the risks
>>     associated with third parties without duplicating efforts.
>>
>> I feel it would be good to have more maintainers' feedback though.
>>
>> Nathan, Nicolas, Miguel - what are your thoughts on this?
> 
> To be entirely honest, I do not really have a strong opinion here. I
> generally agree with your thoughts around branded container images,
> although I do think that TuxMake's images tend to be fairly lean, so
> those easily could become the recommended images without many downsides
> aside from maybe where they are hosted and how they are maintained.
> Having a clean set of Containerfiles on git.kernel.org does not sound
> like a bad idea, especially if they would be structured in such a way
> that other entities could customize them for their use case further. I
> guess its usefulness really depends on the other stakeholders like
> KernelCI. It seems like there has to be some sort of buy in from the
> kernel.org administrators around hosting built container images
> somewhere on kernel.org though, as I don't think the regular developer
> is going to want to build images locally. Not really sure what that
> looks like.

Thank you for the feedback, it's very valuable even without a strong
opinion regarding the 3 options in my previous email.  It also tends
to confirm that the risks I mentioned aren't too critical to get
started, having some developer adoption is more important for now.

With all this in mind, I believe we can follow a step-by-step
approach to start simple and deploy more tailored solutions as and
when the need arises.  This can be seen as a bit of a Beta testing
phase until there is enough momentum to look into the longer term.

So here's what I would like to propose for the short term:

1. review current TuxMake kernel.org toolchain images[1] and
    determine what needs to be added or changed there (e.g. I don't
    see any GCC ones right now)

2. update the scripts/container tool to rely on tuxmake korg images
    with default entries in a reference user settings file

3. encourage kernel developers to go and try it out and provide
    feedback, maybe even run a small community survey

4. review the situation after a while e.g. once v7.1-rc2 is out and
    decide what steps to take next based on community priorities

I believe there aren't any blockers here so we can probably just give
it a try as an experiment and see how it goes, unless someone has
anything else to suggest.

Things like moving the Containerfiles to git.kernel.org or hosting
the images in a dedicated registry etc. should eventually emerge by
themselves if there is a real need for them.

Best wishes,
Guillaume

[1] https://hub.docker.com/u/tuxmake?search=korg