Message-ID: <20260124082939.40715e13@foz.lan>
Date: Sat, 24 Jan 2026 08:29:39 +0100
From: Mauro Carvalho Chehab <mchehab+huawei@...nel.org>
To: Dan Williams <dan.j.williams@...el.com>
Cc: corbet@....net, ksummit@...ts.linux.dev, linux-kernel@...r.kernel.org,
 tech-board-discuss@...ts.linux.dev, Linus Torvalds
 <torvalds@...ux-foundation.org>, Greg Kroah-Hartman
 <gregkh@...uxfoundation.org>, Miguel Ojeda <ojeda@...nel.org>, Kees Cook
 <kees@...nel.org>
Subject: Re: [PATCH] Documentation: Project continuity

On Fri, 23 Jan 2026 17:22:56 -0800
Dan Williams <dan.j.williams@...el.com> wrote:

> Document project continuity procedures. This is a plan for a plan for
> navigating events that affect the forward progress of the canonical Linux
> repository, torvalds/linux.git. It is a follow-up from Maintainer Summit
> [1].

The idea behind this document is interesting, but IMHO it is too
optimistic for a contingency plan ;-)

Conceptually, contingency plans are written to overcome all foreseeable
bad consequences that might happen. So, it should include backups
for each possible bad scenario.

> Cc: Linus Torvalds <torvalds@...ux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@....net>
> Signed-off-by: Jonathan Corbet <corbet@....net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@...nel.org>
> Reviewed-by: Kees Cook <kees@...nel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@...el.com>
> ---
>  Documentation/process/conclave.rst | 41 ++++++++++++++++++++++++++++++
>  Documentation/process/index.rst    |  1 +
>  2 files changed, 42 insertions(+)
>  create mode 100644 Documentation/process/conclave.rst
> 
> diff --git a/Documentation/process/conclave.rst b/Documentation/process/conclave.rst
> new file mode 100644
> index 000000000000..6a1234f54612
> --- /dev/null
> +++ b/Documentation/process/conclave.rst
> @@ -0,0 +1,41 @@
> +.. SPDX-License-Identifier: GPL-2.0
> +
> +Linux kernel project continuity
> +===============================
> +
> +The Linux kernel development project is widely distributed, with over
> +100 maintainers each working to keep changes moving through their own
> +repositories. The final step, though, is a centralized one where changes
> +are pulled into the mainline repository. That is normally done by Linus
> +Torvalds but, as was demonstrated by the 4.19 release in 2018, there are
> +others who can do that work when the need arises.
> +
> +Should the maintainers of that repository become unwilling or unable to
> +do that work going forward (including facilitating a transition), the
> +project will need to find one or more replacements without delay. The

Perhaps it should mention that the "replacements" can be transitory,
e.g. something like:

	The maintainer replacements will have their mandates
	limited to the the period of time where the maintainers are 
	unwilling/unable to voice, if the situation is transitory.


> +process by which that will be done is listed below. $ORGANIZER is the
> +last Maintainer Summit organizer or the current Linux Foundation (LF)
> +Technical Advisory Board (TAB) Chair as a backup.

At the worse "hit-by-a-bus" scenarios, the plan may consider that neither
$ORGANIZER nor TAB would exist.

For such scenarios, I would add:

	If the $ORGANIZER can't be reached within 72 hours, any participant
	of the last Maintainer Summits can start the process.

> +- Within 72 hours, $ORGANIZER will open a discussion with the invitees
> +  of the most recently concluded Maintainers Summit. A meeting of those
> +  invitees and the TAB, either online or in-person, will be set as soon
> +  as possible in a way that maximizes the number of people who can
> +  participate.
> +

Due to the time between the last Maintainers Summit and the conclave,
I would add:

	The participants of the meeting shall still be actively contributing
	with the kernel over the two most recent kernel releases.

Also, it sounds reasonable to define a the minimal number of people
for the conclave (let's say 30). If the number is inferior, the criteria
would be to pick people from the former year and so on until it reaches
the minimal threshold.

> +- If there has been no Maintainers Summit in the last 15 months, the set of
> +  invitees for this meeting will be determined by the TAB.

I would just drop this paragraph. 

This text is meant to prevent any weird situation that might compromise 
the Kernel future. Making it dependent on having an event that could be 
controlled by outside forces to have happened in the last xx months
sounds a bad idea.

Also, if there were no kernel summit in the last year (*), TAB may not 
have its normal 10 members. It may even have zero elected members on its
worse case "hit-by-a-bus" scenario.

Also, on a scenario where TAB won't have enough elected members, a
LF contingency plan might be activated, leading to some weird TAB
composition, which could be filled with people that don't fill the
current criteria and may not understand the Kernel maintainership
processes.

For a contingency plan, all of above sounds a bad idea.

So, if we drop this paragraph nominating TAB as backup, the rule
would be to pick former Maintainers Summit invitees, which should
work properly.

(*) The text says 15 months, but the worse case possible scenario
    with one Maintainers Summit per year would be to have one event
    in, let's say, Jan, 2027 and the next year's one would be in
    Dec, 2028 (so, 23 months).

    Still, if we what happened in 2020, most events were canceled
    those days, including the Maintainers Summit: 

	https://events.linuxfoundation.org/archive/2020/linux-kernel-maintainer-summit/

    It is not absurd to consider we might have things like
    that happening in the future.

> +
> +- The invitees to this meeting may bring in other maintainers as needed.
> +
> +- This meeting, chaired by $ORGANIZER, will consider options for the
> +  ongoing management of the top-level kernel repository consistent with
> +  the expectation that it maximizes the long term health of the project
> +  and its community.
> +
> +- Within two weeks, a representative of this group will communicate to the
> +  broader community, using the ksummit@...ts.linux.dev mailing list, what
> +  the next steps will be.
> +

> +The Linux Foundation, as guided by the TAB, will take the steps
> +necessary to support and implement this plan.

This sounds OK, but in this case we probably need a SoB signed by
someone that can legally sign in the behalf of The Linux Foundation.

> diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst
> index aa12f2660194..492b808a6977 100644
> --- a/Documentation/process/index.rst
> +++ b/Documentation/process/index.rst
> @@ -68,6 +68,7 @@ beyond).
>     stable-kernel-rules
>     management-style
>     researcher-guidelines
> +   conclave
>  
>  Dealing with bugs
>  -----------------
> 
> base-commit: e9a6fb0bcdd7609be6969112f3fbfcce3b1d4a7c



Thanks,
Mauro

Powered by blists - more mailing lists