[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <27446992c6fcc982a26085151988f7be3aa1e3d7.camel@perches.com>
Date: Tue, 25 Jul 2023 14:04:20 -0700
From: Joe Perches <joe@...ches.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Lin Ma <linma@....edu.cn>, jhs@...atatu.com,
xiyou.wangcong@...il.com, jiri@...nulli.us, davem@...emloft.net,
edumazet@...gle.com, pabeni@...hat.com, netdev@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] net/sched: mqprio: Add length check for
TCA_MQPRIO_{MAX/MIN}_RATE64
On Tue, 2023-07-25 at 12:56 -0700, Jakub Kicinski wrote:
> On Tue, 25 Jul 2023 12:50:00 -0700 Joe Perches wrote:
> > > > What do you think the "case" is here?
> > > >
> > > > Do you think John Fastabend, who hasn't touched the file in 7+ years
> > > > should be cc'd? Why?
> > >
> > > Nope. The author of the patch under Fixes.
> >
> > It adds that already since 2019.
>
> Which is awesome! But for that to work you have to run get_maintainer
> on the patchfile not the file paths. Lin Ma used:
>
> # ./scripts/get_maintainer.pl net/sched/sch_mqprio.c
>
> That's what I keep complaining about. People run get_maintainer on
> paths and miss out on all the get_maintainer features which need
> to see the commit message.
Which is useful when editing a file but not when sending
a patch. get_maintainer does _both_.
Again, there's no issue with get_maintainer, but there is
in its use. If there's a real issue, it's with people
and their knowledge of process documentation.
It's _not_ the tool itself as you stated.
Powered by blists - more mailing lists