Jonathan Corbet | 53b7f3a | 2020-01-22 16:05:43 -0700 | [diff] [blame] | 1 | .. SPDX-License-Identifier: GPL-2.0 |
Sameer Rahmani | ff1e81a | 2020-02-03 20:15:43 +0000 | [diff] [blame] | 2 | |
Jonathan Corbet | 53b7f3a | 2020-01-22 16:05:43 -0700 | [diff] [blame] | 3 | Documentation subsystem maintainer entry profile |
| 4 | ================================================ |
| 5 | |
| 6 | The documentation "subsystem" is the central coordinating point for the |
| 7 | kernel's documentation and associated infrastructure. It covers the |
| 8 | hierarchy under Documentation/ (with the exception of |
Mauro Carvalho Chehab | 3ecad8c | 2020-04-14 18:48:36 +0200 | [diff] [blame] | 9 | Documentation/devicetree), various utilities under scripts/ and, at least |
Jonathan Corbet | 53b7f3a | 2020-01-22 16:05:43 -0700 | [diff] [blame] | 10 | some of the time, LICENSES/. |
| 11 | |
| 12 | It's worth noting, though, that the boundaries of this subsystem are rather |
| 13 | fuzzier than normal. Many other subsystem maintainers like to keep control |
| 14 | of portions of Documentation/, and many more freely apply changes there |
| 15 | when it is convenient. Beyond that, much of the kernel's documentation is |
| 16 | found in the source as kerneldoc comments; those are usually (but not |
| 17 | always) maintained by the relevant subsystem maintainer. |
| 18 | |
| 19 | The mailing list for documentation is linux-doc@vger.kernel.org. Patches |
| 20 | should be made against the docs-next tree whenever possible. |
| 21 | |
| 22 | Submit checklist addendum |
| 23 | ------------------------- |
| 24 | |
| 25 | When making documentation changes, you should actually build the |
| 26 | documentation and ensure that no new errors or warnings have been |
| 27 | introduced. Generating HTML documents and looking at the result will help |
| 28 | to avoid unsightly misunderstandings about how things will be rendered. |
| 29 | |
| 30 | Key cycle dates |
| 31 | --------------- |
| 32 | |
| 33 | Patches can be sent anytime, but response will be slower than usual during |
| 34 | the merge window. The docs tree tends to close late before the merge |
| 35 | window opens, since the risk of regressions from documentation patches is |
| 36 | low. |
| 37 | |
| 38 | Review cadence |
| 39 | -------------- |
| 40 | |
| 41 | I am the sole maintainer for the documentation subsystem, and I am doing |
| 42 | the work on my own time, so the response to patches will occasionally be |
| 43 | slow. I try to always send out a notification when a patch is merged (or |
| 44 | when I decide that one cannot be). Do not hesitate to send a ping if you |
| 45 | have not heard back within a week of sending a patch. |