[PATCH] MAINTAINERS: name the ext4 dev branch

[PATCH] MAINTAINERS: name the ext4 dev branch

[Matthias Goergens]

The ext4 T: entry names the repository without a branch, so tools that
default to the repository's HEAD select master, which still points at a
merge from October 2020 (96485e446260).  Development happens on dev,
which is also the branch linux-next merges.  Name it.

The Sashiko review bot, for one, falls back to HEAD this way and has
been reviewing ext4 patches against that tree.  Its review of an EA
inode refcount fix reported a Critical double decrement and an
undefined function after applying the patch to that stale baseline;
neither holds on dev.

Link: https://lore.kernel.org/all/20260916072420.316321F000FF@smtp.kernel.org/
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 806bd2d80d153..8ed6ae20c2523 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -9791,7 +9791,7 @@ L:	linux-ext4@vger.kernel.org
 S:	Maintained
 W:	http://ext4.wiki.kernel.org
 Q:	http://patchwork.ozlabs.org/project/linux-ext4/list/
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
 F:	Documentation/filesystems/ext4/
 F:	fs/ext4/
 F:	include/trace/events/ext4.h

base-commit: 9091c97be34083587a75db174aab51551d8e8543
-- 
2.55.0

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Jan Kara]

On Wed 23-09-26 18:17:49, Matthias Goergens wrote:
> The ext4 T: entry names the repository without a branch, so tools that
> default to the repository's HEAD select master, which still points at a
> merge from October 2020 (96485e446260).  Development happens on dev,
> which is also the branch linux-next merges.  Name it.
> 
> The Sashiko review bot, for one, falls back to HEAD this way and has
> been reviewing ext4 patches against that tree.  Its review of an EA
> inode refcount fix reported a Critical double decrement and an
> undefined function after applying the patch to that stale baseline;
> neither holds on dev.
> 
> Link: https://lore.kernel.org/all/20260916072420.316321F000FF@smtp.kernel.org/
> Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>

Good point. Feel free to add:

Acked-by: Jan Kara <jack@suse.cz>

								Honza

> ---
>  MAINTAINERS | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 806bd2d80d153..8ed6ae20c2523 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -9791,7 +9791,7 @@ L:	linux-ext4@vger.kernel.org
>  S:	Maintained
>  W:	http://ext4.wiki.kernel.org
>  Q:	http://patchwork.ozlabs.org/project/linux-ext4/list/
> -T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git
> +T:	git git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git dev
>  F:	Documentation/filesystems/ext4/
>  F:	fs/ext4/
>  F:	include/trace/events/ext4.h
> 
> base-commit: 9091c97be34083587a75db174aab51551d8e8543
> -- 
> 2.55.0
> 
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Theodore Tso]

On Wed, Sep 23, 2026 at 06:17:49PM -0500, Matthias Goergens wrote:
> The ext4 T: entry names the repository without a branch, so tools that
> default to the repository's HEAD select master, which still points at a
> merge from October 2020 (96485e446260).  Development happens on dev,
> which is also the branch linux-next merges.  Name it.

Huh.  I wasn't even aware that you *could* specify the branch name in
the T: entry.  A quick "grep ^T: MAINTAINERS" there are only a few
repos using T: that include branch.

I also tried looking at the documentation, and I can't find any
mention that the git branch could be specified.  Maybe we should
update the documentation for T: in a separate patch to the MAINTAINERS
file?  Or did I miss something?  "git grep MAINTAINERS | grep branch"
didn't turn up anything.

> The Sashiko review bot, for one, falls back to HEAD this way and has
> been reviewing ext4 patches against that tree.  Its review of an EA
> inode refcount fix reported a Critical double decrement and an
> undefined function after applying the patch to that stale baseline;
> neither holds on dev.

... and I didn't know that Sashiko uses the branch specifier.  I
wonder if ext4 is the only tree which might have this issue...

   git log --merges linux-next

... nope, apparently not.  I see a lot of branches which are merged
into linux-net which are not mentioned in the MAINTAINERS file.

Thanks for pointing this out for the ext4 MAINTAINERS entry!

						- Ted

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Matthias Goergens]

On Wed, Sep 23, 2026 at 11:14:31PM -0400, Theodore Ts'o wrote:
> I also tried looking at the documentation, and I can't find any
> mention that the git branch could be specified.  Maybe we should
> update the documentation for T: in a separate patch to the MAINTAINERS
> file?

The header only says "SCM tree type and location", but the branch has
been used since hwmon named two in 2007, 109 of the 846 git T: lines
name one today, and get_maintainer.pl --self-test=scm has parsed it and
checked it with git ls-remote since 083bf9c56d06 (2017).

> I wonder if ext4 is the only tree which might have this issue...
>
>    git log --merges linux-next
>
> ... nope, apparently not.  I see a lot of branches which are merged
> into linux-net which are not mentioned in the MAINTAINERS file.

I'll take both on: patches documenting the branch, in the MAINTAINERS
header and where submitting-patches.rst sends contributors to the T:
entry, and patches bringing the T: entries in line with the branches
linux-next merges.  I'll Cc you on the documentation patches.

For the entries, my plan is to start with the roughly 160 T: lines
that name a repository whose HEAD is already in mainline while
linux-next pulls a different branch from it: one small patch per
repository, sent to that entry's maintainers as its own thread.  I'd
send a few first, to maintainers who usually respond quickly, and then
the rest in larger batches once the first ones have landed or drawn
comments.  You know far better than I do how maintainers take this
kind of tree-wide cleanup, so I'd welcome your view on that approach
before I start.

Thanks,
Matthias

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Eric Biggers]

On Thu, Sep 24, 2026 at 11:32:00AM +0800, Matthias Goergens wrote:
> For the entries, my plan is to start with the roughly 160 T: lines
> that name a repository whose HEAD is already in mainline while
> linux-next pulls a different branch from it: one small patch per
> repository, sent to that entry's maintainers as its own thread.  I'd
> send a few first, to maintainers who usually respond quickly, and then
> the rest in larger batches once the first ones have landed or drawn
> comments.  You know far better than I do how maintainers take this
> kind of tree-wide cleanup, so I'd welcome your view on that approach
> before I start.

Explicitly documenting branches in MAINTAINERS sounds good, but in
addition to that, HEAD should also be made to point to the correct
branch (at least in repositories where there is only one main
development branch).  This can be done using gitolite's symbolic-ref
command: https://korg.docs.kernel.org/gitolite/index.html#symbolic-ref

That is how https://git.kernel.org/pub/scm/fs/fscrypt/linux.git points
to the 'for-next' branch by default, for example.

- Eric

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Matthias Goergens]

On Wed, Sep 23, 2026 at 09:00:30PM -0700, Eric Biggers wrote:
> Explicitly documenting branches in MAINTAINERS sounds good, but in
> addition to that, HEAD should also be made to point to the correct
> branch (at least in repositories where there is only one main
> development branch).  This can be done using gitolite's symbolic-ref
> command

Thanks, that's a better fix where it applies.  I'll mention it in the
per-tree patches, so each maintainer can choose between the two.

Matthias

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Jan Kara]

On Wed 23-09-26 21:00:30, Eric Biggers wrote:
> On Thu, Sep 24, 2026 at 11:32:00AM +0800, Matthias Goergens wrote:
> > For the entries, my plan is to start with the roughly 160 T: lines
> > that name a repository whose HEAD is already in mainline while
> > linux-next pulls a different branch from it: one small patch per
> > repository, sent to that entry's maintainers as its own thread.  I'd
> > send a few first, to maintainers who usually respond quickly, and then
> > the rest in larger batches once the first ones have landed or drawn
> > comments.  You know far better than I do how maintainers take this
> > kind of tree-wide cleanup, so I'd welcome your view on that approach
> > before I start.
> 
> Explicitly documenting branches in MAINTAINERS sounds good, but in
> addition to that, HEAD should also be made to point to the correct
> branch (at least in repositories where there is only one main
> development branch).  This can be done using gitolite's symbolic-ref
> command: https://korg.docs.kernel.org/gitolite/index.html#symbolic-ref
> 
> That is how https://git.kernel.org/pub/scm/fs/fscrypt/linux.git points
> to the 'for-next' branch by default, for example.

Thanks for the idea! I've done it for my tree now :)

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Niklas Cassel]

Hello Eric,

On Wed, Sep 23, 2026 at 09:00:30PM -0700, Eric Biggers wrote:
> On Thu, Sep 24, 2026 at 11:32:00AM +0800, Matthias Goergens wrote:
> > For the entries, my plan is to start with the roughly 160 T: lines
> > that name a repository whose HEAD is already in mainline while
> > linux-next pulls a different branch from it: one small patch per
> > repository, sent to that entry's maintainers as its own thread.  I'd
> > send a few first, to maintainers who usually respond quickly, and then
> > the rest in larger batches once the first ones have landed or drawn
> > comments.  You know far better than I do how maintainers take this
> > kind of tree-wide cleanup, so I'd welcome your view on that approach
> > before I start.
> 
> Explicitly documenting branches in MAINTAINERS sounds good, but in
> addition to that, HEAD should also be made to point to the correct
> branch (at least in repositories where there is only one main
> development branch).  This can be done using gitolite's symbolic-ref
> command: https://korg.docs.kernel.org/gitolite/index.html#symbolic-ref

For the record, there is no need to use a gitolite specific command,
regular:

$ git remote set-head libata for-next

works.


Damien and I (co-maintainers for libata) had this discussion offline a few
months ago when Sashiko was constantly using the wrong branch.

Assuming that you have a 'fixes' branch and a 'for-next' branch, which
branch should be default?

The branch to use depends on the type of change it is.

And many maintainers can go a very long time without either merging in
'fixes' to 'for-next', or rebasing 'for-next', so critical fixes might
be lacking from 'for-next'.

We decided to keep HEAD pointed to 'master' as that is somewhat neutral.


Kind regards,
Niklas

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Eric Biggers]

On Fri, Sep 25, 2026 at 03:06:28PM +0200, Niklas Cassel wrote:
> Hello Eric,
> 
> On Wed, Sep 23, 2026 at 09:00:30PM -0700, Eric Biggers wrote:
> > On Thu, Sep 24, 2026 at 11:32:00AM +0800, Matthias Goergens wrote:
> > > For the entries, my plan is to start with the roughly 160 T: lines
> > > that name a repository whose HEAD is already in mainline while
> > > linux-next pulls a different branch from it: one small patch per
> > > repository, sent to that entry's maintainers as its own thread.  I'd
> > > send a few first, to maintainers who usually respond quickly, and then
> > > the rest in larger batches once the first ones have landed or drawn
> > > comments.  You know far better than I do how maintainers take this
> > > kind of tree-wide cleanup, so I'd welcome your view on that approach
> > > before I start.
> > 
> > Explicitly documenting branches in MAINTAINERS sounds good, but in
> > addition to that, HEAD should also be made to point to the correct
> > branch (at least in repositories where there is only one main
> > development branch).  This can be done using gitolite's symbolic-ref
> > command: https://korg.docs.kernel.org/gitolite/index.html#symbolic-ref
> 
> For the record, there is no need to use a gitolite specific command,
> regular:
> 
> $ git remote set-head libata for-next
> 
> works.
> 
> 
> Damien and I (co-maintainers for libata) had this discussion offline a few
> months ago when Sashiko was constantly using the wrong branch.
> 
> Assuming that you have a 'fixes' branch and a 'for-next' branch, which
> branch should be default?

Probably the one that most commits go through for that subsystem.  For
most subsystems that is for-next (or equivalent) rather than fixes (or
equivalent).

> The branch to use depends on the type of change it is.
> 
> And many maintainers can go a very long time without either merging in
> 'fixes' to 'for-next', or rebasing 'for-next', so critical fixes might
> be lacking from 'for-next'.

I rebase mine at least once per release, and I think other maintainers
should do that too.  But yes, that can happen.

Really, people sending patches should pass the --base option to 'git
format-patch', and in the vast majority of cases should use a base
commit that's in mainline or linux-next.  Then it's straightforward for
anyone (or anything) to apply the patches without any knowledge of any
subsystem specific development branches.

(Note that can work even if there are prerequisite patches that aren't
in the base yet.  They'll show up as prerequisite-patch-id lines.)

In the few cases where that isn't enough the sender should be super
clear how to apply the patches.

The fact that it's often so difficult to apply patches is a very
frustrating and mostly unnecessary problem in kernel development.  (And
I run into it a lot, since when reviewing patches I like to apply them
and review them in proper context, not just work from the email only.)

- Eric

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Matthias Goergens]

Hi Niklas,

On Fri, Sep 25, 2026 at 03:06:28PM +0200, Niklas Cassel wrote:
> For the record, there is no need to use a gitolite specific command,
> regular:
>
> $ git remote set-head libata for-next
>
> works.

Did you mean this as a way to change the server's default branch, or
for each consumer to run in its own clone?

For the server, I tried it with a scratch bare repository that has
master and for-next, and it looks to me as if set-head only moves
refs/remotes/origin/HEAD in the clone where it runs.  The server's HEAD
stays on master, and so do ls-remote and a fresh clone.  With git
2.55.0, this script:

  git init --quiet --bare --initial-branch=master server.git
  git clone --quiet server.git work
  git -C work commit --quiet --allow-empty --message one
  git -C work push --quiet origin HEAD:master HEAD:for-next
  git --git-dir=server.git symbolic-ref HEAD
  git -C work remote set-head origin for-next
  git -C work symbolic-ref refs/remotes/origin/HEAD
  git --git-dir=server.git symbolic-ref HEAD
  git ls-remote --symref server.git HEAD
  git clone --quiet server.git consumer
  git -C consumer symbolic-ref refs/remotes/origin/HEAD

prints

  refs/heads/master
  refs/remotes/origin/for-next
  refs/heads/master
  ref: refs/heads/master  HEAD
  (object id)  HEAD
  refs/remotes/origin/master

For each consumer's own clone, it works, as long as the consumer knows
which branch to pick; for tools that read MAINTAINERS, that is what
naming the branch in the T: entry would tell them.  Have I missed
something?

Thanks,
Matthias

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Niklas Cassel]

On Sat, Sep 26, 2026 at 02:11:01PM +0800, Matthias Goergens wrote:
> Hi Niklas,
> 
> On Fri, Sep 25, 2026 at 03:06:28PM +0200, Niklas Cassel wrote:
> > For the record, there is no need to use a gitolite specific command,
> > regular:
> >
> > $ git remote set-head libata for-next
> >
> > works.
> 
> Did you mean this as a way to change the server's default branch, or
> for each consumer to run in its own clone?
> 
> For the server, I tried it with a scratch bare repository that has
> master and for-next, and it looks to me as if set-head only moves
> refs/remotes/origin/HEAD in the clone where it runs.  The server's HEAD
> stays on master, and so do ls-remote and a fresh clone.  With git
> 2.55.0, this script:
> 
>   git init --quiet --bare --initial-branch=master server.git
>   git clone --quiet server.git work
>   git -C work commit --quiet --allow-empty --message one
>   git -C work push --quiet origin HEAD:master HEAD:for-next
>   git --git-dir=server.git symbolic-ref HEAD
>   git -C work remote set-head origin for-next
>   git -C work symbolic-ref refs/remotes/origin/HEAD
>   git --git-dir=server.git symbolic-ref HEAD
>   git ls-remote --symref server.git HEAD
>   git clone --quiet server.git consumer
>   git -C consumer symbolic-ref refs/remotes/origin/HEAD
> 
> prints
> 
>   refs/heads/master
>   refs/remotes/origin/for-next
>   refs/heads/master
>   ref: refs/heads/master  HEAD
>   (object id)  HEAD
>   refs/remotes/origin/master
> 
> For each consumer's own clone, it works, as long as the consumer knows
> which branch to pick; for tools that read MAINTAINERS, that is what
> naming the branch in the T: entry would tell them.  Have I missed
> something?

You are right.

Even though:
https://git-scm.com/docs/git-remote#Documentation/git-remote.txt-set-head

says:
Set or delete the default branch (i.e. the target of the symbolic-ref
refs/remotes/<name>/HEAD) for the named remote.

And:

$ git symbolic-ref refs/remotes/libata/HEAD

gets updated, it still only seems to get applied in my local repo,
even after a git push.

Seems like gitolite commands are actually needed then.
I'm sorry for misleading you guys.


Kind regards,
Niklas

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Matthias Goergens]

Hi Ted,

A short report on how the T: cleanup went, as promised.

The documentation patch is at v2 [1].  It now only describes the
syntax: a git T: entry may name a branch, or an entry may have several
T: lines, and what each branch is for is left to the subsystem's P:
profile or the maintainer.  Niklas Cassel, Krzysztof Kozlowski and Eric
Biggers reviewed it and Marc Zyngier acked it; no word from Jon yet.

I sent one patch each to 18 repositories, a few a day.  Three were
picked up (libata, clk, mfd), three have acks or reviews (ext4, phy,
fbdev), six had no reply, and the rest I withdrew or am withdrawing.
Most objections came down to two points.  One branch cannot describe a
tree with both a fixes and a next branch (Greg Kroah-Hartman, Guenter
Roeck).  And several maintainers want contributors to start from
mainline, not from their next branch (Fan Wu, Marc Zyngier); Petr
Mladek and Miroslav Benes added that T: names a repository, and that
review tools should get their own pointer if they need one.

The trigger was Sashiko, the AI review bot, reviewing against a
repository's default branch even when mainline had long since merged
it.  That is now fixed in Sashiko itself: since 28 September it skips
such a branch and uses linux-next.  So I am not sending the 46 further
patches I had prepared.

For ext4 the patch is still correct, but no tool needs it any more, so
take it only if you want it there for people; dropping it is fine.

[1] https://lore.kernel.org/all/20260925120047.1093617-1-matthias.goergens@gmail.com/

Thanks,
Matthias

Re: [PATCH] MAINTAINERS: name the ext4 dev branch

[Theodore Ts'o]

On Wed, 23 Sep 2026 18:17:49 +0800, Matthias Goergens wrote:
> The ext4 T: entry names the repository without a branch, so tools that
> default to the repository's HEAD select master, which still points at a
> merge from October 2020 (96485e446260).  Development happens on dev,
> which is also the branch linux-next merges.  Name it.
> 
> The Sashiko review bot, for one, falls back to HEAD this way and has
> been reviewing ext4 patches against that tree.  Its review of an EA
> inode refcount fix reported a Critical double decrement and an
> undefined function after applying the patch to that stale baseline;
> neither holds on dev.
> 
> [...]

Applied, thanks!

[1/1] MAINTAINERS: name the ext4 dev branch
      commit: 4b1d04693e5ef388d8c6110bc93ee0d0681f9711

Best regards,
-- 
Theodore Ts'o <tytso@mit.edu>