From: Simon Horman <horms@kernel.org>
To: Andrew Lunn <andrew@lunn.ch>
Cc: Jakub Kicinski <kuba@kernel.org>,
davem@davemloft.net, netdev@vger.kernel.org, edumazet@google.com,
pabeni@redhat.com, andrew+netdev@lunn.ch
Subject: Re: [PATCH net 2/2] MAINTAINERS: add a sample ethtool section entry
Date: Tue, 4 Feb 2025 09:39:45 +0000 [thread overview]
Message-ID: <20250204093945.GM234677@kernel.org> (raw)
In-Reply-To: <9f6c2d87-bb45-4c95-af93-7d2ca5f1dcc3@lunn.ch>
On Mon, Feb 03, 2025 at 02:29:23PM +0100, Andrew Lunn wrote:
> On Mon, Feb 03, 2025 at 10:56:47AM +0000, Simon Horman wrote:
> > On Sat, Feb 01, 2025 at 06:11:55PM -0800, Jakub Kicinski wrote:
> > > I feel like we don't do a good enough keeping authors of driver
> > > APIs around. The ethtool code base was very nicely compartmentalized
> > > by Michal. Establish a precedent of creating MAINTAINERS entries
> > > for "sections" of the ethtool API. Use Andrew and cable test as
> > > a sample entry. The entry should ideally cover 3 elements:
> > > a core file, test(s), and keywords. The last one is important
> > > because we intend the entries to cover core code *and* reviews
> > > of drivers implementing given API!
> > >
> > > Signed-off-by: Jakub Kicinski <kuba@kernel.org>
> > > ---
> > > This patch is a nop from process perspective, since Andrew already
> > > is a maintainer and reviews all this code. Let's focus on discussing
> > > merits of the "section entries" in abstract?
> >
> > In the first instance this seems like a good direction to go in to me.
> > My only slight concern is that we might see an explosion in entries.
>
> I don't think that will happen. I don't think we really have many
> sections of ethtool which people personally care about, always try to
> review across all drivers.
>
> Even if it does explode, so what. Is ./scripts/get_maintainer.pl the
> bottleneck in any workflows?
Thanks Andrew,
I'm not overly concerned by the points I raised either, but I did think
they were worth raising. And given that doing so didn't raise any alarm
bells (so far), I'm happy for this patch to proceed.
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2025-02-04 9:39 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-02-02 2:11 [PATCH net 1/2] MAINTAINERS: add entry for ethtool Jakub Kicinski
2025-02-02 2:11 ` [PATCH net 2/2] MAINTAINERS: add a sample ethtool section entry Jakub Kicinski
2025-02-03 10:56 ` Simon Horman
2025-02-03 13:29 ` Andrew Lunn
2025-02-03 16:46 ` Jakub Kicinski
2025-02-04 9:39 ` Simon Horman [this message]
2025-02-04 9:26 ` Paolo Abeni
2025-02-04 15:37 ` Jakub Kicinski
2025-02-04 15:48 ` Paolo Abeni
2025-02-04 16:12 ` Andrew Lunn
2025-02-03 10:55 ` [PATCH net 1/2] MAINTAINERS: add entry for ethtool Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20250204093945.GM234677@kernel.org \
--to=horms@kernel.org \
--cc=andrew+netdev@lunn.ch \
--cc=andrew@lunn.ch \
--cc=davem@davemloft.net \
--cc=edumazet@google.com \
--cc=kuba@kernel.org \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).