[PATCH] MAINTAINERS: name the libata/linux for-next branch

[PATCH] MAINTAINERS: name the libata/linux for-next branch

[Matthias Goergens]

The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
names libata/linux without a branch.  The repository's HEAD (master,
8d3ae59288f1) is a commit from 2026-08-16 that mainline already
contains.  linux-next pulls for-next from this repository (Next/Trees,
next-20260923), and on 2026-09-24 that branch carried work not yet in
mainline.  Name the branch so the entry identifies where development
happens.

Documentation/process/submitting-patches.rst sends contributors to the
T: entry to find the tree to prepare patches against, so a branch-less
entry whose HEAD is already in mainline points them at the wrong tree.

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 cc3cae2e378b..6d2897805618 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14905,7 +14905,7 @@ M:	Damien Le Moal <dlemoal@kernel.org>
 M:	Niklas Cassel <cassel@kernel.org>
 L:	linux-ide@vger.kernel.org
 S:	Maintained
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git for-next
 F:	Documentation/ABI/testing/sysfs-ata
 F:	Documentation/devicetree/bindings/ata/
 F:	drivers/ata/

base-commit: 40288c9206c17eb66a603262e06a58d300d0f279
-- 
2.55.0

Re: [PATCH] MAINTAINERS: name the libata/linux for-next branch

[Damien Le Moal]

On 9/24/26 12:35, Matthias Goergens wrote:
> The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
> names libata/linux without a branch.  The repository's HEAD (master,
> 8d3ae59288f1) is a commit from 2026-08-16 that mainline already
> contains.  linux-next pulls for-next from this repository (Next/Trees,
> next-20260923), and on 2026-09-24 that branch carried work not yet in
> mainline.  Name the branch so the entry identifies where development
> happens.
> 
> Documentation/process/submitting-patches.rst sends contributors to the
> T: entry to find the tree to prepare patches against, so a branch-less
> entry whose HEAD is already in mainline points them at the wrong tree.
> 
> Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>

Looks good.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>

-- 
Damien Le Moal
Western Digital Research

Re: [PATCH] MAINTAINERS: name the libata/linux for-next branch

[Niklas Cassel]

Hello Matthias,

On Thu, Sep 24, 2026 at 11:35:45AM +0800, Matthias Goergens wrote:
> The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
> names libata/linux without a branch.  The repository's HEAD (master,
> 8d3ae59288f1) is a commit from 2026-08-16 that mainline already
> contains.  linux-next pulls for-next from this repository (Next/Trees,
> next-20260923), and on 2026-09-24 that branch carried work not yet in
> mainline.  Name the branch so the entry identifies where development
> happens.

I think this could have been written simpler, without references to dates.
Something like:
"
The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
names libata/linux without a branch. The repository's HEAD pointer
points to branch master, which has no active development.
Active development is on the for-next branch. Name the branch so the
entry identifies where development happens.
"

That said, if you are only sending a patch for libata, I don't see why we
should pick this up.

If I look at some entries for other trees (block, scsi, nvme):

T:      git git://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux.git
T:      git git://git.kernel.org/pub/scm/linux/kernel/git/mkp/scsi.git
T:      git git://git.infradead.org/nvme.git


$ git symbolic-ref refs/remotes/block/HEAD
refs/remotes/block/master

$ git symbolic-ref refs/remotes/scsi/HEAD
refs/remotes/scsi/master

$ git symbolic-ref refs/remotes/nvme/HEAD
refs/remotes/nvme/master

They all point to branch master, which is a copy of Linus's master branch
(often some really copy too).

My point is that, only changing libata seems to make things more inconsistent.

Send a series to Jens fixing all of them, and I would give my Acked-by,
so that he can pick up the patch.


But in reality, if you want to clean things up, why limit it to these three?

Write a script that clones all trees, compares HEAD against what is
is Linux Next (Next/Trees file). If it diverges, add the branch name to
the tree entry in MAINTAINERS.


> 
> Documentation/process/submitting-patches.rst sends contributors to the
> T: entry to find the tree to prepare patches against, so a branch-less
> entry whose HEAD is already in mainline points them at the wrong tree.

s/points them to the wrong tree/points them to the wrong branch/


Kind regards,
Niklas

Re: [PATCH] MAINTAINERS: name the libata/linux for-next branch

[Matthias Goergens]

Hi Niklas,

On Thu, Sep 24, 2026 at 11:32:19AM +0200, Niklas Cassel wrote:
> I think this could have been written simpler, without references to dates.

Agreed, your wording is better.  I'll use it, together with the
s/tree/branch/ fix, in a v2.

> But in reality, if you want to clean things up, why limit it to these three?
>
> Write a script that clones all trees, compares HEAD against what is
> is Linux Next (Next/Trees file). If it diverges, add the branch name to
> the tree entry in MAINTAINERS.

That script is how I found these: about 160 T: lines diverge.  libata
isn't a one-off; it's in the first small batch of the plan I described
in the ext4 thread [1].

I'm sending them in small batches rather than all at once because I'd
invariably get something wrong, or miss a subsystem's conventions, and
I'd rather learn that from a handful of maintainers than from 160.
Exhibit A is the KVM/arm64 reply [2]: that for-next is purely an
integration branch and patches there must be based on a tag from
Linus's tree, so naming it would have sent people to the wrong place.
Comparing HEAD with Next/Trees can't tell that apart from a branch like
yours.  So I now also look at how each branch is built, and I'm holding
back the ones that look like integration branches, block included,
until I know how to word them.

As for the other two: SCSI went out in the same first batch [3], and
nvme.git isn't in Next/Trees at all, so the script never flagged it.
Thanks for the offered Acked-by; I'll Cc you when block comes up.

Thanks,
Matthias

[1] https://lore.kernel.org/all/20260924033200.3615554-1-matthias.goergens@gmail.com/
[2] https://lore.kernel.org/all/877bkb3zjq.wl-maz@kernel.org/
[3] https://lore.kernel.org/all/20260924033541.3624532-1-matthias.goergens@gmail.com/

Re: [PATCH] MAINTAINERS: name the libata/linux for-next branch

[Niklas Cassel]

Hello Matthias,

On Thu, Sep 24, 2026 at 06:18:44PM +0800, Matthias Goergens wrote:
> On Thu, Sep 24, 2026 at 11:32:19AM +0200, Niklas Cassel wrote:
> > I think this could have been written simpler, without references to dates.
> 
> Agreed, your wording is better.  I'll use it, together with the
> s/tree/branch/ fix, in a v2.
> 
> > But in reality, if you want to clean things up, why limit it to these three?
> >
> > Write a script that clones all trees, compares HEAD against what is
> > is Linux Next (Next/Trees file). If it diverges, add the branch name to
> > the tree entry in MAINTAINERS.
> 
> That script is how I found these: about 160 T: lines diverge.  libata
> isn't a one-off; it's in the first small batch of the plan I described
> in the ext4 thread [1].
> 
> I'm sending them in small batches rather than all at once because I'd
> invariably get something wrong, or miss a subsystem's conventions, and
> I'd rather learn that from a handful of maintainers than from 160.
> Exhibit A is the KVM/arm64 reply [2]: that for-next is purely an
> integration branch and patches there must be based on a tag from
> Linus's tree, so naming it would have sent people to the wrong place.
> Comparing HEAD with Next/Trees can't tell that apart from a branch like
> yours.  So I now also look at how each branch is built, and I'm holding
> back the ones that look like integration branches, block included,
> until I know how to word them.
> 
> As for the other two: SCSI went out in the same first batch [3], and
> nvme.git isn't in Next/Trees at all, so the script never flagged it.
> Thanks for the offered Acked-by; I'll Cc you when block comes up.

Okay, nice to see that you are actually putting in the effort to fix all
entries and not just one.

I guess I would have know if you sent it as a series, but that would
probably have been worse than sending a single patch per subsystem,
as I am sure many people will have comments.

Perhaps mention that you are doing a cleanup of all entries after the:

---

line after the commit message, with the links that you shared just now.
That way maintainers will know that you are actually doing a longer
work and not just a one-off.


Kind regards,
Niklas

[PATCH v2] MAINTAINERS: name the libata/linux for-next branch

[Matthias Goergens]

The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
names libata/linux without a branch.  The repository's HEAD pointer
points to branch master, which has no active development.  Active
development is on the for-next branch.  Name the branch so the entry
identifies where development happens.

Documentation/process/submitting-patches.rst sends contributors to the
T: entry to find the tree to prepare patches against, so a branch-less
entry whose HEAD is already in mainline points them to the wrong branch.

Reviewed-by: Damien Le Moal <dlemoal@kernel.org>
Signed-off-by: Matthias Goergens <matthias.goergens@gmail.com>
---
Changes in v2:
- Reworded the commit message as Niklas Cassel suggested: no dates or
  commit hashes, and "wrong branch" rather than "wrong tree".
- Kept Damien's Reviewed-by, as the diff is unchanged.

v1: https://lore.kernel.org/all/20260924033545.3624716-1-matthias.goergens@gmail.com/

This is part of a cleanup of all T: entries whose repository HEAD is
not where development happens: one patch per repository, sent in small
batches.  The plan is at [1], and why it goes out in batches at [2].

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

 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 140eafcbbd78..c9565f2c7644 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14905,7 +14905,7 @@ M:	Damien Le Moal <dlemoal@kernel.org>
 M:	Niklas Cassel <cassel@kernel.org>
 L:	linux-ide@vger.kernel.org
 S:	Maintained
-T:	git git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git
+T:	git git://git.kernel.org/pub/scm/linux/kernel/git/libata/linux.git for-next
 F:	Documentation/ABI/testing/sysfs-ata
 F:	Documentation/devicetree/bindings/ata/
 F:	drivers/ata/

base-commit: 62f4c998b297cf233997a2b4cd6fc2d2df0319c9
-- 
2.55.0

Re: [PATCH v2] MAINTAINERS: name the libata/linux for-next branch

[Niklas Cassel]

On Fri, 25 Sep 2026 13:23:29 +0800, Matthias Goergens wrote:
> The T: entry for LIBATA SUBSYSTEM (Serial and Parallel ATA drivers)
> names libata/linux without a branch.  The repository's HEAD pointer
> points to branch master, which has no active development.  Active
> development is on the for-next branch.  Name the branch so the entry
> identifies where development happens.
> 
> Documentation/process/submitting-patches.rst sends contributors to the
> T: entry to find the tree to prepare patches against, so a branch-less
> entry whose HEAD is already in mainline points them to the wrong branch.
> 
> [...]

Applied to libata/linux.git (for-7.3-fixes), thanks!

[1/1] MAINTAINERS: name the libata/linux for-next branch
      https://git.kernel.org/libata/linux/c/113dcdfa

Kind regards,
Niklas