[PATCH] MAINTAINERS: name the kvmarm/kvmarm next branch

[Marc Zyngier]

On Thu, 24 Sep 2026 09:30:36 +0100,
Matthias Goergens <matthias.goergens at gmail.com> wrote:
> 
> On Thu, 24 Sep 2026 07:59:21 +0100, Marc Zyngier wrote:
> > But that's not reflecting the way we deal with this tree. No actual
> > development happens on that branch, as it is solely for integration.
> > [...]
> > Again, this is not how we work. We explicitly discourage patches
> > against -next. The only sane reference to base kvmarm patches on is a
> > published upstream tag from Linus' tree.
> 
> Thanks for taking the time to explain; I'll drop this one and try to
> leave out other integration-only trees.  The rest will say only which
> branch linux-next merges, not that patches should be based on it.

> It does leave a question I'd like your view on.  submitting-patches.rst
> tells contributors to find the tree to base their work on through the
> T: entry, and for KVM/arm64 that leads to a HEAD from 2020, while the

Well, we can forward master to -rc1 when it lands. That's no big deal.

> rule you describe isn't written down anywhere MAINTAINERS points to
> (the entry has no P: profile).  Would it help if the MAINTAINERS header
> said that T: names where a subsystem's tree lives, and that the base
> for patches can differ and belongs in the P: profile?  I'm preparing
> patches documenting T: anyway, so I could fold that in.

Sure. Though that wouldn't help for kvmarm, as we don't have such a
recorded profile.

Documentation/process/maintainer-kvm-x86.rst could be used as a
starting point, but there are some significant differences in the way
we manage the tree, such as the absence of topic branches, the
references to documentation, and of course the base for most patches.

If someone feels the urge to write some documentation...

	M.

-- 
Jazz isn't dead. It just smells funny.