Re: [RFC PATCH] Documentation/process: Add a maintainer entry profile for KVM/arm64

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] docs: unresolved draft placeholders in maintainer profile
--

commit dc2a38b3be99b9dc53f4e7a7537844707bf4e7ca
Author: Matthias Goergens <matthias.goergens@gmail.com>
Subject: Documentation/process: Add a maintainer entry profile for KVM/arm64

This commit introduces a new maintainer profile for the KVM/arm64 subsystem.
It details the development trees, patch bases, review cadence, and testing
requirements for contributors.

Link: https://lore.kernel.org/all/875wzu4vuv.wl-maz@kernel.org/

> diff --git a/Documentation/process/maintainer-kvm-arm64.rst b/Documentation/process/maintainer-kvm-arm64.rst
> new file mode 100644
> index 0000000000000..deba2f812cef3
> --- /dev/null
> +++ b/Documentation/process/maintainer-kvm-arm64.rst
[ ... ]
> +``fixes``
> +  Fixes for the release currently in its -rc phase.  linux-next merges this
> +  branch too.
> +
> +[?: ``master`` still points at a 2020 commit.  Once it follows -rc1, should
> +this document mention it?]

[Severity: Low]
This isn't a bug, but should this draft placeholder regarding the master branch
be resolved and removed before the documentation is merged?

> +
> +Changes leave the tree as signed tags, which are pulled into the main KVM tree
> +(``git://git.kernel.org/pub/scm/virt/kvm/kvm.git``) and from there reach Linus
> +Torvalds.
> +
> +Unlike the KVM x86 tree, KVM/arm64 has no standing topic branches for
> +contributors to base their work on.  Where a series also touches code
> +maintained elsewhere, most often the arm64 architecture code, the maintainers
> +may set up a shared stable branch, based on an -rc tag, that both trees merge.
> +Say in the cover letter which parts of a series touch other subsystems.
> +[?: Is this an accurate description of topic branches and of how
> +cross-tree changes are handled?]

[Severity: Low]
Should this question about topic branches and cross-tree changes be answered
and the text finalized rather than keeping the placeholder in the document?

> +
> +Base for patches
> +~~~~~~~~~~~~~~~~
[ ... ]
> +Key Cycle Dates
> +---------------
> +
> +Fixes for the current release are queued on ``fixes`` and sent throughout
> +the -rc phase.  Changes for the next merge window are queued on ``next``.
> +
> +[?: What are the cut-offs: the last -rc for submitting new features, and the
> +last -rc at which the maintainers decide what goes into the next merge
> +window?]

[Severity: Low]
Should this placeholder regarding merge window cut-offs be updated with the
actual deadlines before the patch is accepted?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260925085621.562448-1-matthias.goergens@gmail.com?part=1