public inbox for dev@dpdk.org
 help / color / mirror / Atom feed
From: Stephen Hemminger <stephen@networkplumber.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: dev@dpdk.org, Bruce Richardson <bruce.richardson@intel.com>,
	Aaron Conole <aconole@redhat.com>,
	David Marchand <david.marchand@redhat.com>
Subject: Re: [RFC] devtools: replace get-maintainer shell wrapper with Python script
Date: Sun, 1 Feb 2026 14:23:55 -0800	[thread overview]
Message-ID: <20260201142355.32b3e073@phoenix.local> (raw)
In-Reply-To: <5531059.31r3eYUQgx@thomas>

On Sun, 01 Feb 2026 21:16:52 +0100
Thomas Monjalon <thomas@monjalon.net> wrote:

> 01/02/2026 20:01, Stephen Hemminger:
> > On Sun, 01 Feb 2026 14:51:01 +0100
> > Thomas Monjalon <thomas@monjalon.net> wrote:
> >   
> > > 31/01/2026 21:48, Stephen Hemminger:  
> > > > DPDK has been reusing the Linux kernel get_maintainer perl script
> > > > but that creates an unwanted dependency on kernel source.
> > > > 
> > > > This new script replaces that with a standalone Python implementation
> > > > created in a few minutes with AI. The command line arguments are
> > > > a subset of the features that make sense in DPDK.    
> > > 
> > > Almost thousand lines for this new script.
> > > Are you sure that's something we want to maintain ourself?  
> > 
> > It really is less bad than the awk mess.
> > And the kernel often changes the rules.
> > 
> > The bigger issue is that the python version is not detecting everything yet.  
> 
> Our wrapper is very simple.
> How much an issue is this dependency? What others think?

I started looking because of the patch suggestion to auto download
from kernel repo which seemed like an awkward way to solve the problem.

Of the two patches, get-maintainer and checkpatches my feelings are different for
each.

Get-maintainer is just a light wrapper, so probably ok to keep the original
shell script; but DPDK should consider adding other fields about support status
etc. The shell version is 34 line wrapper that calls 2655 line perl script.
There are some policy questions like does DPDK subsystem work like kernel
subsystem, but so far DPDK is fine. Evolution of the kernel version has
been slow; so developers are unlikely to get broken by having old or newer
version of kernel script.

Checkpatches has grown into a slow beast. With multiple awk calls and lots
of copy/paste repetition. The pure Python version is actually easier to read
and support. The shell part of checkpatches is 559 lines and the kernel
part is 7882; in total pretty big. The problem is that kernel version of checkpatches
changes often, and in fact the current DPDK shell script has ignores for
things that are no longer present or have changed. It is not uncommon for
CI to give different answers than running locally with current upstream.
Diverging for this script is overdue.

At this point, the patches are more a "what would it look like if"
to start the discussion.

  reply	other threads:[~2026-02-01 22:24 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-31 20:48 [RFC] devtools: replace get-maintainer shell wrapper with Python script Stephen Hemminger
2026-02-01 13:51 ` Thomas Monjalon
2026-02-01 19:01   ` Stephen Hemminger
2026-02-01 20:16     ` Thomas Monjalon
2026-02-01 22:23       ` Stephen Hemminger [this message]
2026-02-01 19:22 ` [RFC v2] devtools: replace checkpatches " Stephen Hemminger
2026-02-03 14:17 ` [RFC v3] " Stephen Hemminger
2026-02-04 16:59 ` [PATCH v4] " Stephen Hemminger
2026-02-04 17:29   ` Bruce Richardson
2026-02-04 17:32   ` Bruce Richardson
2026-02-05  1:43     ` Stephen Hemminger
2026-02-26 17:15 ` [PATCH v5] devtools: add Python-based patch style checker Stephen Hemminger
2026-03-24 14:48 ` [PATCH v6] " Stephen Hemminger

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=20260201142355.32b3e073@phoenix.local \
    --to=stephen@networkplumber.org \
    --cc=aconole@redhat.com \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    /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