From: Nathan Chancellor <nathan@kernel.org>
To: Guillaume Tucker <gtucker@gtucker.io>
Cc: "Ben Copeland" <ben.copeland@linaro.org>,
"Konstantin Ryabitsev" <konstantin@linuxfoundation.org>,
"Miguel Ojeda" <ojeda@kernel.org>,
"Nicolas Schier" <nsc@kernel.org>,
"Arnd Bergmann" <arnd@arndb.de>,
"Onur Özkan" <work@onurozkan.dev>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
workflows@vger.kernel.org,
automated-testing@lists.yoctoproject.org,
"kernelci@lists.linux.dev" <kernelci@lists.linux.dev>
Subject: Re: Hosting first-party kernel.org container images
Date: Mon, 9 Mar 2026 17:48:15 -0700 [thread overview]
Message-ID: <20260310004815.GA3293460@ax162> (raw)
In-Reply-To: <78adef0e-81b0-47d4-be20-32f42ab8ec04@gtucker.io>
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.
Cheers,
Nathan
next prev parent reply other threads:[~2026-03-10 0:48 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-12-19 13:37 Hosting first-party kernel.org container images Guillaume Tucker
2026-02-02 12:07 ` Ben Copeland
2026-02-25 14:44 ` Guillaume Tucker
2026-03-10 0:48 ` Nathan Chancellor [this message]
2026-03-19 10:37 ` Guillaume Tucker
2026-03-19 11:10 ` Miguel Ojeda
2026-03-19 14:15 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260310004815.GA3293460@ax162 \
--to=nathan@kernel.org \
--cc=arnd@arndb.de \
--cc=automated-testing@lists.yoctoproject.org \
--cc=ben.copeland@linaro.org \
--cc=gtucker@gtucker.io \
--cc=kernelci@lists.linux.dev \
--cc=konstantin@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=nsc@kernel.org \
--cc=ojeda@kernel.org \
--cc=work@onurozkan.dev \
--cc=workflows@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox