[PATCH] Documentation: Project continuity

[PATCH] Documentation: Project continuity

[Dan Williams]

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

Cc: Linus Torvalds <torvalds@linux-foundation.org>
Co-developed-by: Jonathan Corbet <corbet@lwn.net>
Signed-off-by: Jonathan Corbet <corbet@lwn.net>
Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
Reviewed-by: Kees Cook <kees@kernel.org>
Link: https://lwn.net/Articles/1050179/ [1]
Signed-off-by: Dan Williams <dan.j.williams@intel.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
+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.
+
+- 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.
+
+- 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.
+
+- 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@lists.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.
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
-- 
2.52.0

Re: [PATCH] Documentation: Project continuity

[Mauro Carvalho Chehab]

On Fri, 23 Jan 2026 17:22:56 -0800
Dan Williams <dan.j.williams@intel.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@linux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.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@lists.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

Re: [PATCH] Documentation: Project continuity

[Greg Kroah-Hartman]

On Sat, Jan 24, 2026 at 08:29:39AM +0100, Mauro Carvalho Chehab wrote:
> On Fri, 23 Jan 2026 17:22:56 -0800
> Dan Williams <dan.j.williams@intel.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.

That is not the goal here, we aren't going to enumerate all of the
potential issues/plans for every possible scenario, that's just
impossible and would take forever and likely result in something that is
unworkable.  This is here to say "these are the steps we will take to
form a future plan if something goes wrong with our current one."

thanks,

greg k-h

Re: [PATCH] Documentation: Project continuity

[Miguel Ojeda]

On Sat, Jan 24, 2026 at 8:29 AM Mauro Carvalho Chehab
<mchehab+huawei@kernel.org> wrote:
>
> Also, if there were no kernel summit in the last year (*), TAB may not

Quick note on the TAB elections: while they typically happen
during/around the KS/LPC, it is not a hard requirement, and we briefly
discussed potentially changing that (unrelated to this document).

So if a KS didn't happen (or was moved to a significantly different
time of the year) for some reason, then we would likely need to do
elections anyway.

Cheers,
Miguel

Re: [PATCH] Documentation: Project continuity

[Jiri Kosina]

On Sat, 24 Jan 2026, Mauro Carvalho Chehab 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.

I agree with Greg here, that covering each possible scenario is not really 
realistic an feasible anyway.

I believe that rather than the actual deep details of the plan, it's much 
more important to have it written that "there is a plan".

I for example know for sure that there are people out there who believe 
that there is some secret testament hidden somewhere within the depths of 
Linux Foundation on this topic, and this explicitly clarifies it. Which 
should be the main prupose, in my view.

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Documentation: Project continuity

[Linus Torvalds]

On Fri, 23 Jan 2026 at 17:21, Dan Williams <dan.j.williams@intel.com> wrote:
>
> Document project continuity procedures.

I think I'll just commit this as-is, and directly.

Sure, it could just go through the doc tree, and that would be
"standard procedure", but when it comes to something like this, I
think it looks better to just have me commit it myself than have me
pull it from some other source.

Any future updates from further discussion can then go through the doc
tree as normal...

            Linus

Re: [PATCH] Documentation: Project continuity

[Jiri Kosina]

On Sat, 24 Jan 2026, Linus Torvalds wrote:

> > Document project continuity procedures.
> 
> I think I'll just commit this as-is, and directly.
> 
> Sure, it could just go through the doc tree, and that would be
> "standard procedure", but when it comes to something like this, I
> think it looks better to just have me commit it myself than have me
> pull it from some other source.
> 
> Any future updates from further discussion can then go through the doc
> tree as normal...

FWIW

	Reviewed-by: Jiri Kosina <jkosina@suse.com>

(or Supported-by:, or whatnot).

Thanks,

-- 
Jiri Kosina
SUSE Labs

Re: [PATCH] Documentation: Project continuity

[Steven Rostedt]

On Fri, 23 Jan 2026 17:22:56 -0800
Dan Williams <dan.j.williams@intel.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].
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

I thought I sent this out earlier, but anyway...

  Reviewed-by: Steven Rostedt <rostedt@goodmis.org>

-- Steve

Re: [PATCH] Documentation: Project continuity

[Shuah]

On 1/23/26 18:22, Dan Williams 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].
> 
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>   Documentation/process/conclave.rst | 41 ++++++++++++++++++++++++++++++
>   Documentation/process/index.rst    |  1 +
>   2 files changed, 42 insertions(+)
>   create mode 100644 Documentation/process/conclave.rst
> 
>
Loos good to me.

Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>

thanks,
-- Shuah

Re: [PATCH] Documentation: Project continuity

[Julia Lawall]

On Fri, 23 Jan 2026, Dan Williams 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].
>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>
> ---
>  Documentation/process/conclave.rst | 41 ++++++++++++++++++++++++++++++
>  Documentation/process/index.rst    |  1 +
>  2 files changed, 42 insertions(+)
>  create mode 100644 Documentation/process/conclave.rst

Reviewed-by: Julia Lawall <julia.lawall@inria.fr>

Re: [PATCH] Documentation: Project continuity

[Linus Walleij]

On Sat, Jan 24, 2026 at 2:21 AM Dan Williams <dan.j.williams@intel.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].
>
> Cc: Linus Torvalds <torvalds@linux-foundation.org>
> Co-developed-by: Jonathan Corbet <corbet@lwn.net>
> Signed-off-by: Jonathan Corbet <corbet@lwn.net>
> Reviewed-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> Reviewed-by: Miguel Ojeda <ojeda@kernel.org>
> Reviewed-by: Kees Cook <kees@kernel.org>
> Link: https://lwn.net/Articles/1050179/ [1]
> Signed-off-by: Dan Williams <dan.j.williams@intel.com>

FWIW:
Reviewed-by: Linus Walleij <linusw@kernel.org>

Yours,
Linus Walleij