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

[Eric Biggers <ebiggers@kernel.org>]

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