linux-kernel - Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20260122045534.GA3770486@ax162>
Date: Wed, 21 Jan 2026 21:55:34 -0700
From: Nathan Chancellor <nathan@...nel.org>
To: Guillaume Tucker <gtucker@...cker.io>
Cc: Miguel Ojeda <ojeda@...nel.org>, David Gow <davidgow@...gle.com>,
	Onur Özkan <work@...rozkan.dev>,
	Arnd Bergmann <arnd@...db.de>, linux-kernel@...r.kernel.org,
	rust-for-linux@...r.kernel.org, linux-kbuild@...r.kernel.org,
	automated-testing@...ts.yoctoproject.org, workflows@...r.kernel.org,
	llvm@...ts.linux.dev
Subject: Re: [PATCH v3 2/2] Documentation: dev-tools: add container.rst page

On Wed, Jan 21, 2026 at 10:55:53AM +0100, Guillaume Tucker wrote:
> Feel free to make these tweaks now, or we might wait a bit to see if
> others have more feedback with further changes and I can send a v4.

How about this? Send a v4 with:

1. An initial MAINTAINERS entry addition in patch 1 for
   scripts/container like I suggested earlier and scripts/container
   explicitly added to the KERNEL BUILD section so that Nicolas and I
   are included for handling patches.

2. Add the Documentation to the aforementioned MAINTAINERS entry as part
   of patch 2.

3. Either encorporate my suggested change for preferring podman over
   docker with the appropriate changes elsewhere inte the patch set like
   you mentioned or explore checking for the docker alias explicitly.
   Entirely up to you timewise, as long as it results in Nicolas's
   environment working, since I don't think that will be too uncommon.

4. Encorporate any other feedback that you feel is appropriate at this
   stage (if there is any low hanging fruit).

Then we can apply it so that folks can start using it in -next for
testing and validation. After that, you can start thinking of things you
would want to work on for future merge windows from the list you already
started, as I know how that goes when working on a new tool :)

Cheers,
Nathan