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
