From 10a29eb658b3039eccfa6f249da079194f535a9a Mon Sep 17 00:00:00 2001 From: Theodore Ts'o Date: Wed, 8 Mar 2023 14:04:03 -0500 Subject: Documentation/process: Add Linux Kernel Contribution Maturity Model As a follow-up to a discussion at the 2021 Maintainer's Summit on the topic of maintainer recruitment and retention, the TAB took on the task of creating a document which to help companies and other organizations to grow in their ability to engage with the Linux Kernel development community, using the Maturity Model[2] framework. The goal is to encourage, in a management-friendly way, companies to allow their engineers to contribute with the upstream Linux Kernel development community, so we can grow the "talent pipeline" for contributors to become respected leaders, and eventually kernel maintainers. [1] https://lwn.net/Articles/870581/ [2] https://en.wikipedia.org/wiki/Maturity_model Signed-off-by: Theodore Ts'o Co-developed-by: Kees Cook Signed-off-by: Kees Cook Co-developed-by: Dan Williams Signed-off-by: Dan Williams Acked-by: Jakub Kicinski Acked-by: Christian Brauner (Microsoft) Acked-by: Dave Hansen Acked-by: Jonathan Corbet Acked-by: Randy Dunlap Link: https://lore.kernel.org/r/20230308190403.2157046-1-tytso@mit.edu Signed-off-by: Jonathan Corbet --- .../process/contribution-maturity-model.rst | 109 +++++++++++++++++++++ Documentation/process/index.rst | 1 + 2 files changed, 110 insertions(+) create mode 100644 Documentation/process/contribution-maturity-model.rst (limited to 'Documentation/process') diff --git a/Documentation/process/contribution-maturity-model.rst b/Documentation/process/contribution-maturity-model.rst new file mode 100644 index 000000000000..b87ab34de22c --- /dev/null +++ b/Documentation/process/contribution-maturity-model.rst @@ -0,0 +1,109 @@ +.. SPDX-License-Identifier: GPL-2.0 + +======================================== +Linux Kernel Contribution Maturity Model +======================================== + + +Background +========== + +As a part of the 2021 Linux Kernel Maintainers’ Summit, there was a +`discussion `_ about the challenges in +recruiting kernel maintainers as well as maintainer succession. Some of +the conclusions from that discussion included that companies which are a +part of the Linux Kernel community need to allow engineers to be +maintainers as part of their job, so they can grow into becoming +respected leaders and eventually, kernel maintainers. To support a +strong talent pipeline, developers should be allowed and encouraged to +take on upstream contributions such as reviewing other people’s patches, +refactoring kernel infrastructure, and writing documentation. + +To that end, the Linux Foundation Technical Advisory Board (TAB) +proposes this Linux Kernel Contribution Maturity Model. These common +expectations for upstream community engagement aim to increase the +influence of individual developers, increase the collaboration of +organizations, and improve the overall health of the Linux Kernel +ecosystem. + +The TAB urges organizations to continuously evaluate their Open Source +maturity model and commit to improvements to align with this model. To +be effective, this evaluation should incorporate feedback from across +the organization, including management and developers at all seniority +levels. In the spirit of Open Source, we encourage organizations to +publish their evaluations and plans to improve their engagement with the +upstream community. + +Level 0 +======= + +* Software Engineers are not allowed to contribute patches to the Linux + kernel. + + +Level 1 +======= + +* Software Engineers are allowed to contribute patches to the Linux + kernel, either as part of their job responsibilities or on their own + time. + +Level 2 +======= + +* Software Engineers are expected to contribute to the Linux Kernel as + part of their job responsibilities. +* Software Engineers will be supported to attend Linux-related + conferences as a part of their job. +* A Software Engineer’s upstream code contributions will be considered + in promotion and performance reviews. + +Level 3 +======= + +* Software Engineers are expected to review patches (including patches + authored by engineers from other companies) as part of their job + responsibilities +* Contributing presentations or papers to Linux-related or academic + conferences (such those organized by the Linux Foundation, Usenix, + ACM, etc.), are considered part of an engineer’s work. +* A Software Engineer’s community contributions will be considered in + promotion and performance reviews. +* Organizations will regularly report metrics of their open source + contributions and track these metrics over time. These metrics may be + published only internally within the organization, or at the + organization’s discretion, some or all may be published externally. + Metrics that are strongly suggested include: + + * The number of upstream kernel contributions by team or organization + (e.g., all people reporting up to a manager, director, or VP). + * The percentage of kernel developers who have made upstream + contributions relative to the total kernel developers in the + organization. + * The time interval between kernels used in the organization’s servers + and/or products, and the publication date of the upstream kernel + upon which the internal kernel is based. + * The number of out-of-tree commits present in internal kernels. + +Level 4 +======= + +* Software Engineers are encouraged to spend a portion of their work + time focused on Upstream Work, which is defined as reviewing patches, + serving on program committees, improving core project infrastructure + such as writing or maintaining tests, upstream tech debt reduction, + writing documentation, etc. +* Software Engineers are supported in helping to organize Linux-related + conferences. +* Organizations will consider community member feedback in official + performance reviews. + +Level 5 +======= + +* Upstream kernel development is considered a formal job position, with + at least a third of the engineer’s time spent doing Upstream Work. +* Organizations will actively seek out community member feedback as a + factor in official performance reviews. +* Organizations will regularly report internally on the ratio of + Upstream Work to work focused on directly pursuing business goals. diff --git a/Documentation/process/index.rst b/Documentation/process/index.rst index d4b6217472b0..33715da7e684 100644 --- a/Documentation/process/index.rst +++ b/Documentation/process/index.rst @@ -50,6 +50,7 @@ Other guides to the community that are of interest to most developers are: embargoed-hardware-issues maintainers researcher-guidelines + contribution-maturity-model These are some overall technical guides that have been put here for now for lack of a better place. -- cgit v1.2.3 From 9121782e02a936865f48e6a88bb6f62561d36294 Mon Sep 17 00:00:00 2001 From: Carlos Bilbao Date: Wed, 22 Feb 2023 12:34:45 -0600 Subject: docs: Add relevant kernel publications to list of books For the list of kernel published books, include publication covering kernel debugging from August, 2022 (ISBN 978-1801075039) and one from March, 2021 on the topic of char device drivers and kernel synchronization (ISBN 978-1801079518). Also add foundational book from Robert Love (ISBN 978-1449339531) and remove extra spaces. Co-developed-by: Kaiwan N Billimoria Signed-off-by: Kaiwan N Billimoria Signed-off-by: Carlos Bilbao Link: https://lore.kernel.org/r/20230222183445.3127324-1-carlos.bilbao@amd.com Signed-off-by: Jonathan Corbet --- Documentation/process/kernel-docs.rst | 36 ++++++++++++++++++++++++++++++----- 1 file changed, 31 insertions(+), 5 deletions(-) (limited to 'Documentation/process') diff --git a/Documentation/process/kernel-docs.rst b/Documentation/process/kernel-docs.rst index 1c6e2ab92f4e..46f927aae6eb 100644 --- a/Documentation/process/kernel-docs.rst +++ b/Documentation/process/kernel-docs.rst @@ -75,13 +75,39 @@ On-line docs Published books --------------- + * Title: **Linux Kernel Debugging: Leverage proven tools and advanced techniques to effectively debug Linux kernels and kernel modules** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: August, 2022 + :Pages: 638 + :ISBN: 978-1801075039 + :Notes: Debugging book + * Title: **Linux Kernel Programming: A Comprehensive Guide to Kernel Internals, Writing Kernel Modules, and Kernel Synchronization** - :Author: Kaiwan N. Billimoria - :Publisher: Packt Publishing Ltd - :Date: 2021 - :Pages: 754 - :ISBN: 978-1789953435 + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 754 + :ISBN: 978-1789953435 + + * Title: **Linux Kernel Programming Part 2 - Char Device Drivers and Kernel Synchronization: Create user-kernel interfaces, work with peripheral I/O, and handle hardware interrupts** + + :Author: Kaiwan N Billimoria + :Publisher: Packt Publishing Ltd + :Date: March, 2021 + :Pages: 452 + :ISBN: 978-1801079518 + + * Title: **Linux System Programming: Talking Directly to the Kernel and C Library** + + :Author: Robert Love + :Publisher: O'Reilly Media + :Date: June, 2013 + :Pages: 456 + :ISBN: 978-1449339531 + :Notes: Foundational book * Title: **Linux Kernel Development, 3rd Edition** -- cgit v1.2.3 From 0c4ff6f6c6898de4489d89889febae6a970acdff Mon Sep 17 00:00:00 2001 From: Bagas Sanjaya Date: Mon, 20 Mar 2023 19:43:27 +0700 Subject: Documentation: maintainer-tip: Rectify link to "Describe your changes" section of submitting-patches.rst The general changelog rules for the tip tree refers to "Describe your changes" section of submitting patches guide. However, the internal link reference targets to non-existent "submittingpatches" label, which brings reader to the top of the linked doc. Correct the target. No changes to submitting-patches.rst since the required label is already there. Fixes: 31c9d7c8297558 ("Documentation/process: Add tip tree handbook") Signed-off-by: Bagas Sanjaya Reviewed-by: Thomas Gleixner Link: https://lore.kernel.org/r/20230320124327.174881-1-bagasdotme@gmail.com Signed-off-by: Jonathan Corbet --- Documentation/process/maintainer-tip.rst | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'Documentation/process') diff --git a/Documentation/process/maintainer-tip.rst b/Documentation/process/maintainer-tip.rst index 572a3289c9cb..178c95fd17dc 100644 --- a/Documentation/process/maintainer-tip.rst +++ b/Documentation/process/maintainer-tip.rst @@ -128,8 +128,8 @@ uppercase letter and should be written in imperative tone. Changelog ^^^^^^^^^ -The general rules about changelogs in the process documentation, see -:ref:`Documentation/process/ `, apply. +The general rules about changelogs in the :ref:`Submitting patches guide +`, apply. The tip tree maintainers set value on following these rules, especially on the request to write changelogs in imperative mood and not impersonating -- cgit v1.2.3 From 775a445d9a638d8950b1831b605ae6a92a468d7e Mon Sep 17 00:00:00 2001 From: Jakub Wilk Date: Wed, 22 Mar 2023 22:53:11 +0100 Subject: coding-style: fix title of Greg K-H's talk The talk title was inadvertently mangled in 8c27ceff3604 ("docs: fix locations of several documents that got moved"). Signed-off-by: Jakub Wilk Link: https://lore.kernel.org/r/20230322215311.6579-1-jwilk@jwilk.net Signed-off-by: Jonathan Corbet --- Documentation/process/coding-style.rst | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'Documentation/process') diff --git a/Documentation/process/coding-style.rst b/Documentation/process/coding-style.rst index 007e49ef6cec..6db37a46d305 100644 --- a/Documentation/process/coding-style.rst +++ b/Documentation/process/coding-style.rst @@ -1267,5 +1267,5 @@ gcc internals and indent, all available from https://www.gnu.org/manual/ WG14 is the international standardization working group for the programming language C, URL: http://www.open-std.org/JTC1/SC22/WG14/ -Kernel :ref:`process/coding-style.rst `, by greg@kroah.com at OLS 2002: +Kernel CodingStyle, by greg@kroah.com at OLS 2002: http://www.kroah.com/linux/talks/ols_2002_kernel_codingstyle_talk/html/ -- cgit v1.2.3 From c0d747a5b226f36cebdce6da3a3c54ba5a301455 Mon Sep 17 00:00:00 2001 From: Krzysztof Kozlowski Date: Thu, 13 Apr 2023 18:55:01 +0200 Subject: Documentation/process: always CC responsible lists The "Select the recipients for your patch" part about CC-ing mailing lists is a bit vague and might be understood that only some lists should be Cc-ed. That's not what most of the maintainers expect. For given code, associated mailing list must always be CC-ed, because the list is used for reviewing and testing patches. Example are the Devicetree bindings patches, which are tested iff Devicetree mailing list is CC-ed. Signed-off-by: Krzysztof Kozlowski Link: https://lore.kernel.org/r/20230413165501.47442-1-krzysztof.kozlowski@linaro.org Signed-off-by: Jonathan Corbet --- Documentation/process/submitting-patches.rst | 19 ++++++++----------- 1 file changed, 8 insertions(+), 11 deletions(-) (limited to 'Documentation/process') diff --git a/Documentation/process/submitting-patches.rst b/Documentation/process/submitting-patches.rst index 69ce64e03c70..b7e345b93081 100644 --- a/Documentation/process/submitting-patches.rst +++ b/Documentation/process/submitting-patches.rst @@ -223,20 +223,17 @@ patch. Select the recipients for your patch ------------------------------------ -You should always copy the appropriate subsystem maintainer(s) on any patch -to code that they maintain; look through the MAINTAINERS file and the -source code revision history to see who those maintainers are. The -script scripts/get_maintainer.pl can be very useful at this step (pass paths to -your patches as arguments to scripts/get_maintainer.pl). If you cannot find a +You should always copy the appropriate subsystem maintainer(s) and list(s) on +any patch to code that they maintain; look through the MAINTAINERS file and the +source code revision history to see who those maintainers are. The script +scripts/get_maintainer.pl can be very useful at this step (pass paths to your +patches as arguments to scripts/get_maintainer.pl). If you cannot find a maintainer for the subsystem you are working on, Andrew Morton (akpm@linux-foundation.org) serves as a maintainer of last resort. -You should also normally choose at least one mailing list to receive a copy -of your patch set. linux-kernel@vger.kernel.org should be used by default -for all patches, but the volume on that list has caused a number of -developers to tune it out. Look in the MAINTAINERS file for a -subsystem-specific list; your patch will probably get more attention there. -Please do not spam unrelated lists, though. +linux-kernel@vger.kernel.org should be used by default for all patches, but the +volume on that list has caused a number of developers to tune it out. Please +do not spam unrelated lists and unrelated people, though. Many kernel-related lists are hosted on vger.kernel.org; you can find a list of them at http://vger.kernel.org/vger-lists.html. There are -- cgit v1.2.3