cachepc-linux

Fork of AMDESE/linux with modifications for CachePC side-channel attack
git clone https://git.sinitax.com/sinitax/cachepc-linux
Log | Files | Refs | README | LICENSE | sfeed.txt

maintainer-profile.rst (1967B)


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