Re: [PATCH 1/2] MAINTAINERS: document the branch in git T: entries

[Niklas Cassel]

Hello Matthias,

On Thu, Sep 24, 2026 at 10:22:32AM +0200, Krzysztof Kozlowski wrote:
> > @@ -30,6 +30,8 @@ Descriptions of section entries and preferred order
> >         See Documentation/maintainer/maintainer-entry-profile.rst for details.
> >  	T: *SCM* tree type and location.
> >  	   Type is one of: git, hg, quilt, stgit, topgit
> > +	   A git entry may name a branch after the URL; name one when
> > +	   development does not happen on the repository's HEAD.

I like the idea of what you are working on.

But one thing crossed my mind.

If we look in:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/Next/Trees

You will see that for most trees, e.g. ext4.git, the same tree is specified
twice:
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git#fixes
https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git#dev

That is because the most logical thing is to use the same tree, but obviously
you need different branches, if it is new development or a fix.


memblock even specify multiple entries in MAINTAINERS:
https://github.com/torvalds/linux/blob/v7.3-rc4/MAINTAINERS#L17035-L17036

memblock seems to be unique here though, and I don't like the idea of having
multiple T: entries for each branch in the same tree.

Possibly we could allow multiple branches to be specified after the tree,
but I'm not sure if that is a good idea.

A fix is usually merged within a week, so a developer should not really
need to think about "fixes" branch. They should just base it on latest
SHA1 in Linus's tree.


> What contributors need is the branch feeding next, because this is the
> base for them.

I think you are right.

Possibly the documentation should be updated to differentiate the "strictly
a fix / regression in recent release" case versus "new development" case...
but such documentation is hard to write in a generic way. (Not all fixes
might be so important that they deserve to be queued for -fixes.)

But we should probably try to add something to submitting-patches doc which
makes this distinction a bit clearer for a beginner.


Kind regards,
Niklas