[PATCH v3 0/3] Maintainer Entry Profiles
From: Dan Williams
Date: Sun Nov 24 2019 - 16:14:08 EST
Changes since v2 [1]:
- Drop any consideration for coding style concerns in the profile. It
was a minor aspect of the proposal that generated the bulk of the
feedback on v2. Lets make progress on the rest.
- Clarify that the "Submit Checklist Addendum" can also include details
that submitters need to take into account before even beginning to
craft a patch. This is in response to the RISC-V use case of
declaring specification readiness as a patch gate, and is now also used
by the libnvdimm subsystem to clarify details about ACPI NVDIMM Device
Specific Method specifications. (Paul)
- Non-change from v2: Kees had asked for a common directory for all
profiles to live, but Mauro noted that this could be handled later
with some scripting to post-process the MAINTAINERS file, or otherwise
converting MAINTAINERS to ReST.
- Clarify the cover letter to focus on the contributor focused
Maintainer Entry Profiles, and defer discussion of a maintainer
focused Handbook.
[1]: https://lore.kernel.org/ksummit-discuss/156821692280.2951081.18036584954940423225.stgit@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx/
---
At last years Plumbers Conference I proposed the Maintainer Entry
Profile as a document that a maintainer can provide to set contributor
expectations and provide fodder for a discussion between maintainers
about the merits of different maintainer policies.
For those that did not attend, the goal of the Maintainer Entry Profile
is to provide contributors documentation of patch submission
considerations that may vary by subsystem. The session introduction was:
The first rule of kernel maintenance is that there are no hard and
fast rules. That state of affairs is both a blessing and a curse. It
has served the community well to be adaptable to the different
people and different problem spaces that inhabit the kernel
community. However, that variability also leads to inconsistent
experiences for contributors, little to no guidance for new
contributors, and unnecessary stress on current maintainers.
To be clear, the proposed document does not impose or suggest new rules.
Instead it provides an outlet to document the existing unwritten
policies in effect for a given subsystem. Over time the hope is that
some of this variability can be up-levelled to new global process
policy, but in the meantime it provides relief for communicating the
guidelines that are being imposed on contributors.
---
Dan Williams (3):
MAINTAINERS: Reclaim the P: tag for Maintainer Entry Profile
Maintainer Handbook: Maintainer Entry Profile
libnvdimm, MAINTAINERS: Maintainer Entry Profile
Documentation/maintainer/index.rst | 1
.../maintainer/maintainer-entry-profile.rst | 87 ++++++++++++++++++++
Documentation/nvdimm/maintainer-entry-profile.rst | 59 ++++++++++++++
MAINTAINERS | 20 +++--
4 files changed, 158 insertions(+), 9 deletions(-)
create mode 100644 Documentation/maintainer/maintainer-entry-profile.rst
create mode 100644 Documentation/nvdimm/maintainer-entry-profile.rst