On Wed, 11 Sep 2019 08:48:54 -0700
Dan Williams <dan.j.williams(a)intel.com> wrote:
As presented at the 2018 Linux Plumbers conference , the
Entry Profile (formerly Subsystem Profile) is proposed as a way to reduce
friction between committers and maintainers and encourage conversations
amongst maintainers about common best practices. While coding-style,
submit-checklist, and submitting-drivers lay out some common expectations
there remain local customs and maintainer preferences that vary by
The profile contains short answers to some of the common policy questions a
contributor might have that are local to the subsystem / device-driver, or
otherwise not covered by the top-level process documents.
Overview: General introduction to how the subsystem operates
Submit Checklist Addendum: Mechanical items that gate submission staging
Key Cycle Dates:
- Last -rc for new feature submissions: Expected lead time for submissions
- Last -rc to merge features: Deadline for merge decisions
Coding Style Addendum: Clarifications of local style preferences
Resubmit Cadence: When to ping the maintainer
Checkpatch / Style Cleanups: Policy on pure cleanup patches
So I'm finally back home after my European tour, and I have it on good
authority that my bag might even get here eventually too. That means I'm
digging through a pile of docs stuff I've been neglecting badly...
My intention is to apply these patches. But as I was reading through
them, one little nagging thing came to mind...
See Documentation/maintainer/maintainer-entry-profile.rst for more
and a follow-on example profile for the libnvdimm subsystem.
Thus far, the maintainer guide is focused on how to *be* a maintainer.
This document, instead, is more about how to deal with specific
maintainers. So I suspect that Documentation/maintainer might be the
wrong place for it.
Should we maybe place it instead under Documentation/process, or even
create a new top-level "book" for this information?