[RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[Alex Bennée]

I wanted to look at adding gitlab tags to MAINTAINERS and baulked
slightly at figuring out what I would need to change in the perl
script to cleanly handle it.

While we imported the perl script from the kernel I'm fairly sure we
don't use half the features it has and as us grey beards age out less
people will be willing to tweak it. Consider this a proof-of-concept
for discussion about if it is worth perusing this path.

For v2:

  - added the missing K: keyword support
  - added basic --git fallback support
  - picked up a few more MAINTAINER updates from list
  - updated entries for Arm and *-user

I've CC'd the kernel maintainers for the script to see if they are
interested in this work.

While the python script is still cooking I will send a PR on Monday
with just the MAINTAINER updates which are reviewed/acked.

Alex.

Alex Bennée (13):
  MAINTAINERS: fix missing names
  MAINTAINERS: fix libvirt entry
  MAINTAINERS: regularise the status fields
  MAINTAINERS: update Arm to Supported status
  MAINTAINERS: be realistic about *-user
  scripts/get_maintainer.py: minimal argument parsing
  scripts/get_maintainer.py: resolve the source path
  scripts/get_maintainer.py: initial parsing of MAINTAINERS
  scripts/get_maintainer.py: add support for -f
  scripts/get_maintainer.py: add support reading patch files
  scripts/get_maintainer.py: add keyword (K:) support
  scripts/get_maintainer.py: implement basic git fallback support
  gitlab: add a check-maintainers task

Mads Ynddal (1):
  MAINTAINERS: remove myself as reviewer

Pierrick Bouvier (2):
  MAINTAINERS: add maintainer for docs/
  MAINTAINERS: add reviewer for linux-user

 MAINTAINERS                    |  31 +-
 .gitlab-ci.d/static_checks.yml |   9 +
 scripts/get_maintainer.py      | 499 +++++++++++++++++++++++++++++++++
 3 files changed, 525 insertions(+), 14 deletions(-)
 create mode 100755 scripts/get_maintainer.py

-- 
2.47.3

[RFC PATCH v2 01/16] MAINTAINERS: fix missing names

[Alex Bennée]

The form is Name <email> so lets fix that up before we enforce it.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 36a2be3ddba..392100b213b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2551,7 +2551,7 @@ F: hw/virtio/vhost-user-snd*
 F: include/hw/virtio/vhost-user-snd.h
 
 vhost-user-scmi
-R: mzamazal@redhat.com
+R: Milan Zamazal <mzamazal@redhat.com>
 S: Supported
 F: hw/virtio/vhost-user-scmi*
 F: include/hw/virtio/vhost-user-scmi.h
-- 
2.47.3

[RFC PATCH v2 02/16] MAINTAINERS: fix libvirt entry

[Alex Bennée]

We have a particular tag for lists so lets use it.

Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Thomas Huth <thuth@redhat.com>
Reviewed-by: Cornelia Huck <cohuck@redhat.com>
Reviewed-by: Daniel P. Berrangé <berrange@redhat.com>
Reviewed-by: Ján Tomko <jtomko@redhat.com>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 392100b213b..8b256835647 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4511,7 +4511,7 @@ F: gitdm.config
 F: contrib/gitdm/*
 
 Incompatible changes
-R: devel@lists.libvirt.org
+L: devel@lists.libvirt.org
 F: docs/about/deprecated.rst
 
 Build System
-- 
2.47.3

[RFC PATCH v2 03/16] MAINTAINERS: regularise the status fields

[Alex Bennée]

Orphaned isn't a state, Orphan is. Likewise all the other "Odd Fixes"
are capitalised so fix the ones that are not.

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 8b256835647..851fa3b3d69 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2694,7 +2694,7 @@ F: hw/i2c/i2c_mux_pca954x.c
 F: include/hw/i2c/i2c_mux_pca954x.h
 
 pcf8574
-S: Orphaned
+S: Orphan
 F: hw/gpio/pcf8574.c
 F: include/gpio/pcf8574.h
 
@@ -2922,7 +2922,7 @@ S390 3270 device
 M: Halil Pasic <pasic@linux.ibm.com>
 M: Christian Borntraeger <borntraeger@linux.ibm.com>
 R: Collin Walling <walling@linux.ibm.com>
-S: Odd fixes
+S: Odd Fixes
 F: include/hw/s390x/3270-ccw.h
 F: hw/char/terminal3270.c
 F: hw/s390x/3270-ccw.c
@@ -3841,7 +3841,7 @@ F: tests/unit/test-uuid.c
 
 Yank feature
 M: Lukas Straub <lukasstraub2@web.de>
-S: Odd fixes
+S: Odd Fixes
 F: util/yank.c
 F: migration/yank_functions*
 F: tests/unit/test-yank.c
-- 
2.47.3

[RFC PATCH v2 04/16] MAINTAINERS: remove myself as reviewer

[Alex Bennée]

From: Mads Ynddal <mads@ynddal.dk>

My work has changed focus, and I do not have the time to continue.

Signed-off-by: Mads Ynddal <mads@ynddal.dk>
Message-ID: <20260121112725.40060-1-mads@ynddal.dk>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index 851fa3b3d69..3604422f8b4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -536,7 +536,6 @@ F: system/cpus.c
 
 Apple Silicon HVF CPUs
 M: Alexander Graf <agraf@csgraf.de>
-R: Mads Ynddal <mads@ynddal.dk>
 S: Maintained
 F: target/arm/hvf/
 F: target/arm/hvf-stub.c
@@ -553,7 +552,6 @@ HVF
 M: Cameron Esfahani <dirty@apple.com>
 M: Roman Bolshakov <rbolshakov@ddn.com>
 R: Phil Dennis-Jordan <phil@philjordan.eu>
-R: Mads Ynddal <mads@ynddal.dk>
 W: https://wiki.qemu.org/Features/HVF
 S: Maintained
 F: accel/hvf/
@@ -3655,7 +3653,6 @@ F: stubs/
 
 Tracing
 M: Stefan Hajnoczi <stefanha@redhat.com>
-R: Mads Ynddal <mads@ynddal.dk>
 S: Maintained
 F: trace/
 F: trace-events
-- 
2.47.3

[RFC PATCH v2 05/16] MAINTAINERS: add maintainer for docs/

[Alex Bennée]

From: Pierrick Bouvier <pierrick.bouvier@linaro.org>

I would like to help maintaining qemu documentation and I've been
invited by Alex to apply as maintainer.

Files in docs/ that are already maintained will continue to be under
their respective maintainer. The goal here is to have someone that can
help on all other files that don't have an official maintainer.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Acked-by: Daniel P. Berrangé <berrange@redhat.com>
Acked-by: Thomas Huth <thuth@redhat.com>
Acked-by: Alex Bennée <alex.bennee@linaro.org>
Acked-by: Markus Armbruster <armbru@redhat.com>
Message-ID: <20260115203529.2713193-1-pierrick.bouvier@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3604422f8b4..a691e3511c9 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4511,6 +4511,11 @@ Incompatible changes
 L: devel@lists.libvirt.org
 F: docs/about/deprecated.rst
 
+General Documentation
+M: Pierrick Bouvier <pierrick.bouvier@linaro.org>
+S: Maintained
+F: docs/
+
 Build System
 ------------
 Meson
-- 
2.47.3

[RFC PATCH v2 06/16] MAINTAINERS: update Arm to Supported status

[Alex Bennée]

We are involved in lots of areas of the QEMU code base but as I'm sure
most developers will realise we are actively funded to support the Arm
ecosystem for both emulation and virtualisation use-cases. Lets make
that clear in MAINTAINERS to keep parity with the other Supported
architectures.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index a691e3511c9..87ec6f3595b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -200,7 +200,7 @@ F: disas/alpha.c
 ARM TCG CPUs
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
-S: Maintained
+S: Supported
 F: target/arm/
 F: target/arm/tcg/
 F: tests/functional/aarch64/meson.build
@@ -462,7 +462,7 @@ F: scripts/kvm/kvm_flightrecorder
 ARM KVM CPUs
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
-S: Maintained
+S: Supported
 F: target/arm/kvm.c
 F: tests/functional/aarch64/test_kvm.py
 
@@ -1102,7 +1102,7 @@ F: docs/system/arm/versatile.rst
 Virt
 M: Peter Maydell <peter.maydell@linaro.org>
 L: qemu-arm@nongnu.org
-S: Maintained
+S: Supported
 F: hw/arm/virt*
 F: include/hw/arm/virt.h
 F: docs/system/arm/virt.rst
-- 
2.47.3

[RFC PATCH v2 07/16] MAINTAINERS: add reviewer for linux-user

[Alex Bennée]

From: Pierrick Bouvier <pierrick.bouvier@linaro.org>

I had interest in this area for some time, and would like to help
reviewing it.

Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
Acked-by: Laurent Vivier <laurent@vivier.eu>
Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Message-ID: <20260115201712.2706663-1-pierrick.bouvier@linaro.org>
Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 MAINTAINERS | 1 +
 1 file changed, 1 insertion(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 87ec6f3595b..ee64a528c7f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4033,6 +4033,7 @@ T: git https://github.com/qemu-bsd-user/qemu-bsd-user bsd-user-rebase-3.1
 
 Linux user
 M: Laurent Vivier <laurent@vivier.eu>
+R: Pierrick Bouvier <pierrick.bouvier@linaro.org>
 S: Maintained
 F: linux-user/
 F: configs/targets/*linux-user.mak
-- 
2.47.3

[RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Alex Bennée]

Looking at the merges for the last year:

  $ git shortlog --merges --since "last year" *-user/ accel/tcg/user-exec* hw/core/cpu-user.c include/user/ scripts/qemu-binfmt-conf.sh scripts/update-syscalltbl.sh scripts/update-mips-syscall-args.sh tests/functional/arm/test_bflt.py tests/vm/*bsd

  Richard Henderson (4):
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-tcg-20251019' of https://gitlab.com/rth7680/qemu into staging

  Stefan Hajnoczi (12):
        Merge tag 'linux-user-fix-gupnp-pull-request' of https://github.com/hdeller/qemu-hppa into staging
        Merge tag 'pull-10.0-testing-and-gdstub-updates-100225-1' of https://gitlab.com/stsquad/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-loongarch-20250424' of https://github.com/gaosong715/qemu into staging
        Merge tag 'pull-misc-2025-04-24' of https://repo.or.cz/qemu/armbru into staging
        Merge tag 'pull-trivial-patches' of https://gitlab.com/mjt0k/qemu into staging
        Merge tag 'hppa-fpe-fixup-pull-request' of https://github.com/hdeller/qemu-hppa into staging
        Merge tag 'pull-target-arm-20250704' of https://gitlab.com/pm215/qemu into staging
        Merge tag 'for-upstream' of https://gitlab.com/bonzini/qemu into staging
        Merge tag 'pull-10.1-rc0-maintainer-140725-1' of https://gitlab.com/stsquad/qemu into staging
        Merge tag 'for_upstream' of https://git.kernel.org/pub/scm/virt/kvm/mst/qemu into staging
        Merge tag 'accel-20250715' of https://github.com/philmd/qemu into staging

None of the pull requests have come through the maintainers and while
there are a fair number of commits overall they have been mostly bug
fixes, re-factoring clean-ups and the occasional new syscall/ioctl
handling.

We should reflect the current status so users don't have unrealistic
expectations of how quickly things can get reviewed and merged.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---

[AJB] I realise this is a slightly provocative patch but given how
widely used *-user is downstream we should be clear about the current
state and hopefully encourage those who rely on it to step-up.
---
 MAINTAINERS | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index ee64a528c7f..1f313bba84f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4016,7 +4016,7 @@ Usermode Emulation
 ------------------
 Overall usermode emulation
 M: Riku Voipio <riku.voipio@iki.fi>
-S: Maintained
+S: Odd Fixes
 F: accel/tcg/user-exec*.c
 F: hw/core/cpu-user.c
 F: include/user/
@@ -4025,7 +4025,7 @@ F: common-user/
 BSD user
 M: Warner Losh <imp@bsdimp.com>
 R: Kyle Evans <kevans@freebsd.org>
-S: Maintained
+S: Odd Fixes
 F: bsd-user/
 F: configs/targets/*-bsd-user.mak
 F: tests/vm/*bsd
@@ -4034,7 +4034,7 @@ T: git https://github.com/qemu-bsd-user/qemu-bsd-user bsd-user-rebase-3.1
 Linux user
 M: Laurent Vivier <laurent@vivier.eu>
 R: Pierrick Bouvier <pierrick.bouvier@linaro.org>
-S: Maintained
+S: Odd Fixes
 F: linux-user/
 F: configs/targets/*linux-user.mak
 F: scripts/qemu-binfmt-conf.sh
-- 
2.47.3

[RFC PATCH v2 09/16] scripts/get_maintainer.py: minimal argument parsing

[Alex Bennée]

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 scripts/get_maintainer.py | 44 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 44 insertions(+)
 create mode 100755 scripts/get_maintainer.py

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
new file mode 100755
index 00000000000..2b8fc7ae9ee
--- /dev/null
+++ b/scripts/get_maintainer.py
@@ -0,0 +1,44 @@
+#!/usr/bin/env python
+#
+# get_maintainer.py: Print selected MAINTAINERS information
+#
+# usage: scripts/get_maintainer.py [OPTIONS] <patch>
+#        scripts/get_maintainer.py [OPTIONS] -f <file>
+#
+# (c) 2025, Alex Bennée <alex.bennee@linaro.org>
+#           based on get_maintainers.pl
+#
+# SPDX-License-Identifier: GPL-2.0-or-later
+
+from argparse import ArgumentParser, ArgumentTypeError
+from os import path
+from pathlib import Path
+
+
+def valid_file_path(arg):
+    """
+    Checks if arg exists and is a regular file or raises ArgumentTypeError.
+    """
+    if not path.exists(arg):
+        raise ArgumentTypeError(f"File '{arg}' does not exist.")
+    if not path.isfile(arg):
+        raise ArgumentTypeError(f"Path '{arg}' is not a regular file.")
+    return Path(path.abspath(arg))
+
+
+def main():
+    parser = ArgumentParser(description='Extract maintainer information. ')
+
+    # We can either specify patches or an individual file
+    group = parser.add_mutually_exclusive_group()
+    group.add_argument('patch', nargs='*', type=valid_file_path,
+                       help='path to patch file')
+    group.add_argument('-f', '--file', type=valid_file_path,
+                       help='path to source file')
+
+    args = parser.parse_args()
+
+
+
+if __name__ == '__main__':
+    main()
-- 
2.47.3

[RFC PATCH v2 10/16] scripts/get_maintainer.py: resolve the source path

[Alex Bennée]

We will need this to automagically find MAINTAINERS. Use the same
logic as the perl script by looking for expected files and
directories.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
v2
  - don't hack add_argument twice just to display default
  - whitespace fix
  - don't default to required
---
 scripts/get_maintainer.py | 74 +++++++++++++++++++++++++++++++++++++++
 1 file changed, 74 insertions(+)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index 2b8fc7ae9ee..c02bf4f5b0e 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -15,6 +15,60 @@
 from pathlib import Path
 
 
+#
+# Helper functions for dealing with the source path
+#
+
+
+def is_qemu_src_root(directory):
+    """
+    Checks if the given path appears to be the root of a QEMU source tree,
+    based on the presence of key files and directories.
+    """
+    if not path.isdir(directory):
+        return False
+
+    required_files = ['COPYING', 'MAINTAINERS', 'Makefile', 'VERSION']
+    required_dirs = ['docs', 'linux-user', 'system']
+
+    for f in required_files:
+        if not path.isfile(path.join(directory, f)):
+            return False
+    for d in required_dirs:
+        if not path.isdir(path.join(directory, d)):
+            return False
+    return True
+
+
+def find_src_root():
+    """
+    Walks up the directory tree from the script's location
+    to find the QEMU source root.
+    Returns the absolute path of the root directory if found, or None.
+    """
+    script_dir = path.dirname(path.abspath(__file__))
+    current_dir = script_dir
+
+    while True:
+        if is_qemu_src_root(current_dir):
+            return current_dir
+
+        # Move up to the parent directory
+        parent_dir = path.dirname(current_dir)
+
+        # If we reached the filesystem root and haven't found it, stop
+        if parent_dir == current_dir:
+            break
+
+        current_dir = parent_dir
+
+    return None
+
+#
+# Argument validation
+#
+
+
 def valid_file_path(arg):
     """
     Checks if arg exists and is a regular file or raises ArgumentTypeError.
@@ -26,7 +80,21 @@ def valid_file_path(arg):
     return Path(path.abspath(arg))
 
 
+def valid_src_root(arg):
+    """
+    Checks if arg is a valid QEMU source root or raise ArgumentTypeError.
+    """
+    abs_path = path.abspath(arg)
+    if not is_qemu_src_root(abs_path):
+        raise ArgumentTypeError(f"Path '{arg}' is not a valid QEMU source tree")
+    return abs_path
+
+
 def main():
+    """
+    Main entry point for the script.
+    """
+
     parser = ArgumentParser(description='Extract maintainer information. ')
 
     # We can either specify patches or an individual file
@@ -36,6 +104,12 @@ def main():
     group.add_argument('-f', '--file', type=valid_file_path,
                        help='path to source file')
 
+    # We need to know or be told where the root of the source tree is
+    src = find_src_root()
+
+    parser.add_argument('--src', type=valid_src_root, default=src,
+                        help=f'Root of QEMU source tree{" (default: " + src + ")" if src else ""}')
+
     args = parser.parse_args()
 
 
-- 
2.47.3

[RFC PATCH v2 11/16] scripts/get_maintainer.py: initial parsing of MAINTAINERS

[Alex Bennée]

Add the basic infrastructure to parse MAINTAINERS and generate a list
of MaintainerSection objects we can use later.

Add a --validate argument so we can use the script to ensure
MAINTAINERS is always parse-able in our CI.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>

---
v2
  - add __str__ function for formatting Person
---
 scripts/get_maintainer.py | 168 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 167 insertions(+), 1 deletion(-)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index c02bf4f5b0e..696a5b55d8d 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -10,9 +10,159 @@
 #
 # SPDX-License-Identifier: GPL-2.0-or-later
 
-from argparse import ArgumentParser, ArgumentTypeError
+from argparse import ArgumentParser, ArgumentTypeError, BooleanOptionalAction
 from os import path
 from pathlib import Path
+from enum import StrEnum, auto
+from re import compile as re_compile
+
+#
+# Subsystem MAINTAINER entries
+#
+# The MAINTAINERS file is an unstructured text file where the
+# important information is in lines that follow the form:
+#
+# X: some data
+#
+# where X is a documented tag and the data is variously an email,
+# path, regex or link. Other lines should be ignored except the
+# preceding non-blank or underlined line which represents the name of
+# the "subsystem" or general area of the project.
+#
+# A blank line denominates the end of a section.
+#
+
+tag_re = re_compile(r"^([A-Z]):")
+
+
+class UnhandledTag(Exception):
+    "Exception for unhandled tags"
+
+
+class BadStatus(Exception):
+    "Exception for unknown status"
+
+
+class Status(StrEnum):
+    "Maintenance status"
+
+    UNKNOWN = auto()
+    SUPPORTED = 'Supported'
+    MAINTAINED = 'Maintained'
+    ODD_FIXES = 'Odd Fixes'
+    ORPHAN = 'Orphan'
+    OBSOLETE = 'Obsolete'
+
+    @classmethod
+    def _missing_(cls, value):
+        # _missing_ is only invoked by the enum machinery if 'value' does not
+        # match any existing enum member's value.
+        # So, if we reach this point, 'value' is inherently invalid for this enum.
+        raise BadStatus(f"'{value}' is not a valid maintenance status.")
+
+
+person_re = re_compile(r"^(?P<name>[^<]+?)\s*<(?P<email>[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})>\s*(?:@(?P<handle>\w+))?$")
+
+
+class BadPerson(Exception):
+    "Exception for un-parsable person"
+
+
+class Person:
+    "Class representing a maintainer or reviewer and their details"
+
+    def __init__(self, info):
+        match = person_re.search(info)
+
+        if match is None:
+            raise BadPerson(f"Failed to parse {info}")
+
+        self.name = match.group('name')
+        self.email = match.group('email')
+
+    def __str__(self):
+        return f"{self.name} <{self.email}>"
+
+
+class MaintainerSection:
+    "Class representing a section of MAINTAINERS"
+
+    def _expand(self, pattern):
+        if pattern.endswith("/"):
+            return f"{pattern}*"
+        return pattern
+
+    def __init__(self, section, entries):
+        self.section = section
+        self.status = Status.UNKNOWN
+        self.maintainers = []
+        self.reviewers = []
+        self.files = []
+        self.files_exclude = []
+        self.trees = []
+        self.lists = []
+        self.web = []
+        self.keywords = []
+
+        for e in entries:
+            (tag, data) = e.split(": ", 2)
+
+            if tag == "M":
+                person = Person(data)
+                self.maintainers.append(person)
+            elif tag == "R":
+                person = Person(data)
+                self.reviewers.append(person)
+            elif tag == "S":
+                self.status = Status(data)
+            elif tag == "L":
+                self.lists.append(data)
+            elif tag == 'F':
+                pat = self._expand(data)
+                self.files.append(pat)
+            elif tag == 'W':
+                self.web.append(data)
+            elif tag == 'K':
+                self.keywords.append(data)
+            elif tag == 'T':
+                self.trees.append(data)
+            elif tag == 'X':
+                pat = self._expand(data)
+                self.files_exclude.append(pat)
+            else:
+                raise UnhandledTag(f"'{tag}' is not understood.")
+
+
+
+def read_maintainers(src):
+    """
+    Read the MAINTAINERS file, return a list of MaintainerSection objects.
+    """
+
+    mfile = path.join(src, 'MAINTAINERS')
+    entries = []
+
+    section = None
+    fields = []
+
+    with open(mfile, 'r', encoding='utf-8') as f:
+        for line in f:
+            if not line.strip():  # Blank line found, potential end of a section
+                if section:
+                    new_section = MaintainerSection(section, fields)
+                    entries.append(new_section)
+                    # reset for next section
+                    section = None
+                    fields = []
+            elif tag_re.match(line):
+                fields.append(line.strip())
+            else:
+                if line.startswith("-") or line.startswith("="):
+                    continue
+
+                section = line.strip()
+
+    return entries
 
 
 #
@@ -104,6 +254,12 @@ def main():
     group.add_argument('-f', '--file', type=valid_file_path,
                        help='path to source file')
 
+    # Validate MAINTAINERS
+    parser.add_argument('--validate',
+                        action=BooleanOptionalAction,
+                        default=None,
+                        help="Just validate MAINTAINERS file")
+
     # We need to know or be told where the root of the source tree is
     src = find_src_root()
 
@@ -112,6 +268,16 @@ def main():
 
     args = parser.parse_args()
 
+    try:
+        # Now we start by reading the MAINTAINERS file
+        maint_sections = read_maintainers(args.src)
+    except Exception as e:
+        print(f"Error: {e}")
+        exit(-1)
+
+    if args.validate:
+        print(f"loaded {len(maint_sections)} from MAINTAINERS")
+        exit(0)
 
 
 if __name__ == '__main__':
-- 
2.47.3

[RFC PATCH v2 12/16] scripts/get_maintainer.py: add support for -f

[Alex Bennée]

Now we have our sections we can add support for checking each file
against the maintainer list and gathering the ones we want. Finally we
can print the list out.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 scripts/get_maintainer.py | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index 696a5b55d8d..96875255b11 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -132,6 +132,32 @@ def __init__(self, section, entries):
             else:
                 raise UnhandledTag(f"'{tag}' is not understood.")
 
+    def __str__(self) -> str:
+        entries = []
+
+        for m in self.maintainers:
+            entries.append(f"{m.name} <{m.email}> (maintainer: {self.section})")
+
+        for r in self.reviewers:
+            entries.append(f"{r.name} <{r.email}> (reviewer: {self.section})")
+
+        for l in self.lists:
+            entries.append(f"{l} (open list: {self.section})")
+
+        return "\n".join(entries)
+
+    def is_file_covered(self, filename):
+        "Is filename covered by this maintainer section"
+
+        for fx in self.files_exclude:
+            if filename.match(fx):
+                return False
+
+        for f in self.files:
+            if filename.match(f):
+                return True
+
+        return False
 
 
 def read_maintainers(src):
@@ -279,6 +305,15 @@ def main():
         print(f"loaded {len(maint_sections)} from MAINTAINERS")
         exit(0)
 
+    relevent_maintainers = None
+
+    if args.file:
+        relevent_maintainers = [ms for ms in maint_sections if
+                                ms.is_file_covered(args.file)]
+
+    for rm in relevent_maintainers:
+        print(rm)
+
 
 if __name__ == '__main__':
     main()
-- 
2.47.3

[RFC PATCH v2 13/16] scripts/get_maintainer.py: add support reading patch files

[Alex Bennée]

Not so different from individual files, we just need to parse the
patch looking for the files and add them to the list. As we can parse
multiple patches we also need to ensure the final list of sections is
unique so we don't repeat ourselves.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 scripts/get_maintainer.py | 47 ++++++++++++++++++++++++++++++++++-----
 1 file changed, 42 insertions(+), 5 deletions(-)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index 96875255b11..f46d8f6e073 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -15,6 +15,7 @@
 from pathlib import Path
 from enum import StrEnum, auto
 from re import compile as re_compile
+from re import sub as re_sub
 
 #
 # Subsystem MAINTAINER entries
@@ -190,6 +191,29 @@ def read_maintainers(src):
 
     return entries
 
+#
+# Helper functions for dealing with patch files
+#
+patchfile_re = re_compile(r"\+\+\+\s+(\S+)")
+
+#TODO: also return a list of keyword hits for K:?
+def extract_filenames_from_patch(patchfile):
+    """
+    Read a patchfile and return a list of files which are modified by
+    the patch.
+    """
+    file_list = []
+
+    with open(patchfile, 'r', encoding='utf-8') as f:
+        for line in f:
+            m = patchfile_re.match(line)
+            if m:
+                # strip leading [ab]/
+                stripped = re_sub(r'^[^/]*/', '', m.group(1))
+                as_path = Path(path.abspath(stripped))
+                file_list.append(as_path)
+
+    return file_list
 
 #
 # Helper functions for dealing with the source path
@@ -305,14 +329,27 @@ def main():
         print(f"loaded {len(maint_sections)} from MAINTAINERS")
         exit(0)
 
-    relevent_maintainers = None
+    # Build array of Path objects representing the files
+    files = []
 
     if args.file:
-        relevent_maintainers = [ms for ms in maint_sections if
-                                ms.is_file_covered(args.file)]
+        files.append(args.file)
+
+    if args.patch:
+        for p in args.patch:
+            pfiles = extract_filenames_from_patch(p)
+            files.extend(pfiles)
+
+    # unique set of maintainer sections
+    maintained: set[MaintainerSection] = set()
+
+    for f in files:
+        fmaint = [ms for ms in maint_sections if ms.is_file_covered(f)]
+        for m in fmaint:
+            maintained.add(m)
 
-    for rm in relevent_maintainers:
-        print(rm)
+    for rm in maintained:
+        print(str(rm))
 
 
 if __name__ == '__main__':
-- 
2.47.3

[RFC PATCH v2 14/16] scripts/get_maintainer.py: add keyword (K:) support

[Alex Bennée]

We use the regex module to stay compatible with the Perl compatible
regex used in the MAINTAINERS file.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 scripts/get_maintainer.py | 36 +++++++++++++++++++++++++++---------
 1 file changed, 27 insertions(+), 9 deletions(-)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index f46d8f6e073..b41f5342876 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -16,6 +16,7 @@
 from enum import StrEnum, auto
 from re import compile as re_compile
 from re import sub as re_sub
+from regex import compile as prec_compile
 
 #
 # Subsystem MAINTAINER entries
@@ -124,7 +125,8 @@ def __init__(self, section, entries):
             elif tag == 'W':
                 self.web.append(data)
             elif tag == 'K':
-                self.keywords.append(data)
+                match = prec_compile(data)
+                self.keywords.append(match)
             elif tag == 'T':
                 self.trees.append(data)
             elif tag == 'X':
@@ -160,6 +162,15 @@ def is_file_covered(self, filename):
 
         return False
 
+    def patch_contains_keyword(self, patch_lines):
+        "Does patch contain keyword covered by this maintainer section"
+
+        for l in patch_lines:
+            for k in self.keywords:
+                if k.findall(l):
+                    return True
+
+        return False
 
 def read_maintainers(src):
     """
@@ -194,18 +205,22 @@ def read_maintainers(src):
 #
 # Helper functions for dealing with patch files
 #
+
+
 patchfile_re = re_compile(r"\+\+\+\s+(\S+)")
 
-#TODO: also return a list of keyword hits for K:?
-def extract_filenames_from_patch(patchfile):
+
+def process_patch_file(patchfile):
     """
-    Read a patchfile and return a list of files which are modified by
+    Read a patchfile and return the message as a string and a list of files which are modified by
     the patch.
     """
     file_list = []
+    msg = []
 
     with open(patchfile, 'r', encoding='utf-8') as f:
         for line in f:
+            msg.append(line)
             m = patchfile_re.match(line)
             if m:
                 # strip leading [ab]/
@@ -213,7 +228,7 @@ def extract_filenames_from_patch(patchfile):
                 as_path = Path(path.abspath(stripped))
                 file_list.append(as_path)
 
-    return file_list
+    return (msg, file_list)
 
 #
 # Helper functions for dealing with the source path
@@ -335,13 +350,16 @@ def main():
     if args.file:
         files.append(args.file)
 
+    # unique set of maintainer sections
+    maintained: set[MaintainerSection] = set()
+
     if args.patch:
         for p in args.patch:
-            pfiles = extract_filenames_from_patch(p)
+            (msg, pfiles) = process_patch_file(p)
             files.extend(pfiles)
-
-    # unique set of maintainer sections
-    maintained: set[MaintainerSection] = set()
+            kmaint = [ms for ms in maint_sections if ms.patch_contains_keyword(msg)]
+            for m in kmaint:
+                maintained.add(m)
 
     for f in files:
         fmaint = [ms for ms in maint_sections if ms.is_file_covered(f)]
-- 
2.47.3

[RFC PATCH v2 15/16] scripts/get_maintainer.py: implement basic git fallback support

[Alex Bennée]

Implement the basic --git fallback support which also needs
--git-since and the various knobs to control the minimum and maximum
signatures to look for.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 scripts/get_maintainer.py | 125 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 125 insertions(+)

diff --git a/scripts/get_maintainer.py b/scripts/get_maintainer.py
index b41f5342876..de229a20bc2 100755
--- a/scripts/get_maintainer.py
+++ b/scripts/get_maintainer.py
@@ -11,12 +11,16 @@
 # SPDX-License-Identifier: GPL-2.0-or-later
 
 from argparse import ArgumentParser, ArgumentTypeError, BooleanOptionalAction
+from dataclasses import dataclass
 from os import path
 from pathlib import Path
 from enum import StrEnum, auto
 from re import compile as re_compile
 from re import sub as re_sub
+from re import IGNORECASE
 from regex import compile as prec_compile
+from git import Repo
+from collections import Counter
 
 #
 # Subsystem MAINTAINER entries
@@ -230,6 +234,96 @@ def process_patch_file(patchfile):
 
     return (msg, file_list)
 
+#
+# Helpers for querying git
+#
+
+
+@dataclass
+class GitOptions:
+    repo: Repo
+    singers: bool
+    since: str
+    min_sig: int
+    max_maint: int
+    min_percent: int
+
+
+def rank_signers(git_opts, all_signers, total_commits):
+    """
+    Counts signer occurrences and returns a list of (Person, count, percent).
+    """
+    if total_commits == 0:
+        return []
+
+    # Count by email to handle duplicates/mailmap issues
+    counts = Counter(s.email for s in all_signers)
+
+    # Keep a map of email -> Person object for the most recent name used
+    email_to_person = {p.email: p for p in all_signers}
+
+    ranked_results = []
+
+    # Sort by count descending, then take the top N
+    for email, count in counts.most_common(git_opts.max_maint):
+        percent = min(100.0, (count / total_commits) * 100)
+        if percent >= git_opts.min_percent:
+            person = email_to_person[email]
+            ranked_results.append((person, count, percent))
+
+    return ranked_results
+
+
+# regex to extract name/email from *-by: tags
+sig_line_re = re_compile(r"^\s*[\w-]+-by:\s*(?P<person_info>.*)", IGNORECASE)
+
+
+def extract_signers(commit_message):
+    """
+    Return a list of Persons found in commit.
+    """
+    signers = []
+    for line in commit_message.splitlines():
+        match = sig_line_re.match(line)
+        if match:
+            try:
+                p = Person(match.group('person_info'))
+                signers.append(p)
+            except BadPerson:
+                continue
+    return signers
+
+
+def extract_from_git(git_opts, src_file):
+    """
+    Extract 'maintainers' from examining the git history of a file.
+    Return an array of Person/role tuples.
+    """
+    repo = git_opts.repo
+
+    # use the porcelain to fetch the log
+    hashes = repo.git.log('--follow', f"--since={git_opts.since}",
+                          "--format=%H", '--', src_file).splitlines()
+
+    if len(hashes) <= 0:
+        return []
+
+    commits = [repo.commit(h) for h in hashes]
+
+    all_signers = []
+
+    for c in commits:
+        all_signers.extend(extract_signers(f"{c.message}"))
+
+    ranked = rank_signers(git_opts, all_signers, len(commits))
+    results = []
+
+    for person, count, percent in ranked:
+        role = f"commit_signer: {count}/{len(commits)}={percent:.0f}%"
+        results.append((person, role))
+
+    return results
+
 #
 # Helper functions for dealing with the source path
 #
@@ -331,6 +425,22 @@ def main():
     parser.add_argument('--src', type=valid_src_root, default=src,
                         help=f'Root of QEMU source tree{" (default: " + src + ")" if src else ""}')
 
+    # Git Options
+    parser.add_argument('--git', action=BooleanOptionalAction,
+                        default=False,
+                        help="Include recent git *-by: signers (default: don't)")
+    parser.add_argument('--git-since', default="1-year-ago",
+                        help='git history to use when falling back (default: 1-year-ago)')
+    parser.add_argument('--git-fallback',
+                        action=BooleanOptionalAction, default=True,
+                        help='use git when no exact MAINTAINERS pattern (default: fallback)')
+    parser.add_argument('--git-min-signatures', default=1,
+                        help='number of signatures required (default: 1)')
+    parser.add_argument('--git-max-maintainers', default=5,
+                        help='maximum number of git derived maintainers to add (default: 5)')
+    parser.add_argument('--git-min-percent', default=5,
+                        help='minimum percentage of commits to tagged as a maintainer (default: 5)')
+
     args = parser.parse_args()
 
     try:
@@ -369,6 +479,21 @@ def main():
     for rm in maintained:
         print(str(rm))
 
+    # Git fallback
+    if args.git or (args.git_fallback and len(maintained) == 0):
+        repo = Repo(src)
+        git_opts = GitOptions(repo=repo, singers=args.git,
+                              since=args.git_since,
+                              min_sig=args.git_min_signatures,
+                              max_maint=args.git_max_maintainers,
+                              min_percent=args.git_min_percent)
+
+        for f in files:
+            gmaint = extract_from_git(git_opts, f)
+
+            for (person, role) in gmaint:
+                print(f"{person} ({role})")
+
 
 if __name__ == '__main__':
     main()
-- 
2.47.3

[RFC PATCH v2 16/16] gitlab: add a check-maintainers task

[Alex Bennée]

Now we have a more flexible get_maintainer script we can use it to
validate MAINTAINERS.

Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
---
 .gitlab-ci.d/static_checks.yml | 9 +++++++++
 1 file changed, 9 insertions(+)

diff --git a/.gitlab-ci.d/static_checks.yml b/.gitlab-ci.d/static_checks.yml
index 61fe2fa39ab..c74698ad948 100644
--- a/.gitlab-ci.d/static_checks.yml
+++ b/.gitlab-ci.d/static_checks.yml
@@ -23,6 +23,15 @@ check-dco:
   before_script:
     - apk -U add git
 
+check-maintainers:
+  extends: .base_job_template
+  stage: build
+  image: python:3.10-alpine
+  needs: []
+  script: scripts/get_maintainer.py --validate
+  variables:
+    GIT_DEPTH: 1
+
 check-python-minreqs:
   extends: .base_job_template
   stage: test
-- 
2.47.3

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 1242 bytes --]

On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> We should reflect the current status so users don't have unrealistic
> expectations of how quickly things can get reviewed and merged.
>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>

Reviewed-by: Warner Losh <imp@bsdimp.com>


> ---
>
> [AJB] I realise this is a slightly provocative patch but given how
> widely used *-user is downstream we should be clear about the current
> state and hopefully encourage those who rely on it to step-up.
>

For the bsd-user case this is likely correct. We run hot and cold about
being
proactive at fixing things, and we've been somewhat cold for a while now.

Part of the problem is that this submission process is very very heavyweight
compared to other projects I contribute to. Not sure what to do about that
since
there's a reluctance to move away from it. Or alternatively, I'm somehow
making
it too hard.

A lot of the upstreaming work that's stalled would be ideal to tell claude
to do,
but I'm unsure the project's stance on using claude to move code, and git
log
5 different trees to get the original author(s) of the code and make
trivial compile
tweaks.

Warner

[-- Attachment #2: Type: text/html, Size: 2032 bytes --]

Re: [RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[Pierrick Bouvier]

On 1/23/26 6:57 AM, Alex Bennée wrote:
> I wanted to look at adding gitlab tags to MAINTAINERS and baulked
> slightly at figuring out what I would need to change in the perl
> script to cleanly handle it.
> 
> While we imported the perl script from the kernel I'm fairly sure we
> don't use half the features it has and as us grey beards age out less
> people will be willing to tweak it. Consider this a proof-of-concept
> for discussion about if it is worth perusing this path.
> 
> For v2:
> 
>    - added the missing K: keyword support
>    - added basic --git fallback support
>    - picked up a few more MAINTAINER updates from list
>    - updated entries for Arm and *-user
> 
> I've CC'd the kernel maintainers for the script to see if they are
> interested in this work.
> 
> While the python script is still cooking I will send a PR on Monday
> with just the MAINTAINER updates which are reviewed/acked.
> 
> Alex.
> 
> Alex Bennée (13):
>    MAINTAINERS: fix missing names
>    MAINTAINERS: fix libvirt entry
>    MAINTAINERS: regularise the status fields
>    MAINTAINERS: update Arm to Supported status
>    MAINTAINERS: be realistic about *-user
>    scripts/get_maintainer.py: minimal argument parsing
>    scripts/get_maintainer.py: resolve the source path
>    scripts/get_maintainer.py: initial parsing of MAINTAINERS
>    scripts/get_maintainer.py: add support for -f
>    scripts/get_maintainer.py: add support reading patch files
>    scripts/get_maintainer.py: add keyword (K:) support
>    scripts/get_maintainer.py: implement basic git fallback support
>    gitlab: add a check-maintainers task
> 
> Mads Ynddal (1):
>    MAINTAINERS: remove myself as reviewer
> 
> Pierrick Bouvier (2):
>    MAINTAINERS: add maintainer for docs/
>    MAINTAINERS: add reviewer for linux-user
> 
>   MAINTAINERS                    |  31 +-
>   .gitlab-ci.d/static_checks.yml |   9 +
>   scripts/get_maintainer.py      | 499 +++++++++++++++++++++++++++++++++
>   3 files changed, 525 insertions(+), 14 deletions(-)
>   create mode 100755 scripts/get_maintainer.py
> 

Hi Alex,

it seems like you forgot to pull this patch also:
https://lore.kernel.org/qemu-devel/20260115202511.2709767-1-pierrick.bouvier@linaro.org/

Could you please include it in the current series to avoid an additional 
month of round trip?

Thanks,
Pierrick

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Alex Bennée]

Warner Losh <imp@bsdimp.com> writes:

(Cc sniping Paolo/Peter/Markus for AI discussion)

> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:
>
>  We should reflect the current status so users don't have unrealistic
>  expectations of how quickly things can get reviewed and merged.
>
>  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>
> Reviewed-by: Warner Losh <imp@bsdimp.com>
>  
>  ---
>
>  [AJB] I realise this is a slightly provocative patch but given how
>  widely used *-user is downstream we should be clear about the current
>  state and hopefully encourage those who rely on it to step-up.
>
> For the bsd-user case this is likely correct. We run hot and cold about being
> proactive at fixing things, and we've been somewhat cold for a while now.
>
> Part of the problem is that this submission process is very very heavyweight
> compared to other projects I contribute to. Not sure what to do about that since
> there's a reluctance to move away from it. Or alternatively, I'm somehow making
> it too hard.

We have discussed in the past allowing maintainers to directly submit
their PRs via GitLab which would be beneficial from a testing point of
view. To move this forward someone needs to propose the changes to our
policy documents so it can be discussed and merged.

However we still expect patches to go onto the mailing list for
review. The greybeards (like myself ;-) are very wedded to the inline
email workflow but if we could keep that interface while making use of
the GitLab UI for those that grew up knowing only the web maybe we could
make the project more friendly to new contributors.

I'd be interested in knowing where the pain points are for you because
modern tools like b4 make some of the grind (collecting tags and
applying patches from ML) a lot easier.

Usually the most difficult thing is getting email setup so you can
git-send-email or git-publish.

> A lot of the upstreaming work that's stalled would be ideal to tell claude to do,
> but I'm unsure the project's stance on using claude to move code, and git log
> 5 different trees to get the original author(s) of the code and make trivial compile
> tweaks.

There was some discussion at the maintainers summit about relaxing the
rules on AI submission for "mechanical" changes but it ran into the
weeds without any firm conclusion. We could certainly revisit it.

I think the concern about potential license pollution is a valid one but
this is more of a concern for "novel" changes made by AI. I've been more
relaxed on my personal FLOSS projects where I have allowed AI
contributions but made it clear that the submitter is expected to
understand whats going on. But being personal projects they are less
likely to be spammed to death by AI slop PRs which seems to be a growing
problem in the wider ecosystem.

>
> Warner 

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[Alex Bennée]

Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:

> On 1/23/26 6:57 AM, Alex Bennée wrote:
>> I wanted to look at adding gitlab tags to MAINTAINERS and baulked
>> slightly at figuring out what I would need to change in the perl
>> script to cleanly handle it.
>> While we imported the perl script from the kernel I'm fairly sure we
>> don't use half the features it has and as us grey beards age out less
>> people will be willing to tweak it. Consider this a proof-of-concept
>> for discussion about if it is worth perusing this path.
>> For v2:
>>    - added the missing K: keyword support
>>    - added basic --git fallback support
>>    - picked up a few more MAINTAINER updates from list
>>    - updated entries for Arm and *-user
>> I've CC'd the kernel maintainers for the script to see if they are
>> interested in this work.
>> While the python script is still cooking I will send a PR on Monday
>> with just the MAINTAINER updates which are reviewed/acked.
>> Alex.
>> Alex Bennée (13):
>>    MAINTAINERS: fix missing names
>>    MAINTAINERS: fix libvirt entry
>>    MAINTAINERS: regularise the status fields
>>    MAINTAINERS: update Arm to Supported status
>>    MAINTAINERS: be realistic about *-user
>>    scripts/get_maintainer.py: minimal argument parsing
>>    scripts/get_maintainer.py: resolve the source path
>>    scripts/get_maintainer.py: initial parsing of MAINTAINERS
>>    scripts/get_maintainer.py: add support for -f
>>    scripts/get_maintainer.py: add support reading patch files
>>    scripts/get_maintainer.py: add keyword (K:) support
>>    scripts/get_maintainer.py: implement basic git fallback support
>>    gitlab: add a check-maintainers task
>> Mads Ynddal (1):
>>    MAINTAINERS: remove myself as reviewer
>> Pierrick Bouvier (2):
>>    MAINTAINERS: add maintainer for docs/
>>    MAINTAINERS: add reviewer for linux-user
>>   MAINTAINERS                    |  31 +-
>>   .gitlab-ci.d/static_checks.yml |   9 +
>>   scripts/get_maintainer.py      | 499 +++++++++++++++++++++++++++++++++
>>   3 files changed, 525 insertions(+), 14 deletions(-)
>>   create mode 100755 scripts/get_maintainer.py
>> 
>
> Hi Alex,
>
> it seems like you forgot to pull this patch also:
> https://lore.kernel.org/qemu-devel/20260115202511.2709767-1-pierrick.bouvier@linaro.org/
>
> Could you please include it in the current series to avoid an
> additional month of round trip?

Hmm I did so a sweep and I didn't catch it, pulled now.
>
> Thanks,
> Pierrick

-- 
Alex Bennée
Virtualisation Tech Lead @ Linaro

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Daniel P. Berrangé]

On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
> On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org> wrote:
> 
> > We should reflect the current status so users don't have unrealistic
> > expectations of how quickly things can get reviewed and merged.
> >
> > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >
> 
> Reviewed-by: Warner Losh <imp@bsdimp.com>

snip
 
> A lot of the upstreaming work that's stalled would be ideal to tell claude
> to do,
> but I'm unsure the project's stance on using claude to move code, and git
> log
> 5 different trees to get the original author(s) of the code and make
> trivial compile
> tweaks.

The critical thing we don't want is such tools making changes to the
contents of source files.

Automating the moving around of files is a non-issue.

The use of AI for writing commit messages is arguably in scope of QEMU's
AI policy given that is part of "the contribution", but it is less serious
there, since commit messages don't have a copyright implication on what we
host & distribute.

More important is that the commit messages are accurate and well written.
LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
course the well known danger of hallucinating nonsense. IME that makes it
challenging to benefit from an LLM, due to review & re-writing overheads
you then incurr to validate and fix their output.

I'd be wary of relying on an AI to extract and report on authorship of
code. Accuracy is important there since it implies copyright ownership
associations. Likewise a Signed-off-by tag should be added by humans
only since it is a statement they are complying with the DCO policy.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[Joe Perches]

On Fri, 2026-01-23 at 14:57 +0000, Alex Bennée wrote:
> I wanted to look at adding gitlab tags to MAINTAINERS and baulked
> slightly at figuring out what I would need to change in the perl
> script to cleanly handle it.
> 
> While we imported the perl script from the kernel I'm fairly sure we
> don't use half the features it has and as us grey beards age out less
> people will be willing to tweak it. Consider this a proof-of-concept
> for discussion about if it is worth perusing this path.
> 
> For v2:
> 
>   - added the missing K: keyword support
>   - added basic --git fallback support
>   - picked up a few more MAINTAINER updates from list
>   - updated entries for Arm and *-user
> 
> I've CC'd the kernel maintainers for the script to see if they are
> interested in this work.

I think rewrites aren't particularly useful but, your time, your choices.

Perhaps the --interactive bit of the script isn't necessary to convert.
I don't know that anyone uses it.

Adding Florian Mickler who wrote the --interactive code to cc's
(15+ years ago now)

Re: [RFC PATCH v2 00/16] MAINTAINER updates plus conversion of get_maintainers.pl to python

[Pierrick Bouvier]

On 1/23/26 8:18 AM, Alex Bennée wrote:
> Pierrick Bouvier <pierrick.bouvier@linaro.org> writes:
> 
>> On 1/23/26 6:57 AM, Alex Bennée wrote:
>>> I wanted to look at adding gitlab tags to MAINTAINERS and baulked
>>> slightly at figuring out what I would need to change in the perl
>>> script to cleanly handle it.
>>> While we imported the perl script from the kernel I'm fairly sure we
>>> don't use half the features it has and as us grey beards age out less
>>> people will be willing to tweak it. Consider this a proof-of-concept
>>> for discussion about if it is worth perusing this path.
>>> For v2:
>>>     - added the missing K: keyword support
>>>     - added basic --git fallback support
>>>     - picked up a few more MAINTAINER updates from list
>>>     - updated entries for Arm and *-user
>>> I've CC'd the kernel maintainers for the script to see if they are
>>> interested in this work.
>>> While the python script is still cooking I will send a PR on Monday
>>> with just the MAINTAINER updates which are reviewed/acked.
>>> Alex.
>>> Alex Bennée (13):
>>>     MAINTAINERS: fix missing names
>>>     MAINTAINERS: fix libvirt entry
>>>     MAINTAINERS: regularise the status fields
>>>     MAINTAINERS: update Arm to Supported status
>>>     MAINTAINERS: be realistic about *-user
>>>     scripts/get_maintainer.py: minimal argument parsing
>>>     scripts/get_maintainer.py: resolve the source path
>>>     scripts/get_maintainer.py: initial parsing of MAINTAINERS
>>>     scripts/get_maintainer.py: add support for -f
>>>     scripts/get_maintainer.py: add support reading patch files
>>>     scripts/get_maintainer.py: add keyword (K:) support
>>>     scripts/get_maintainer.py: implement basic git fallback support
>>>     gitlab: add a check-maintainers task
>>> Mads Ynddal (1):
>>>     MAINTAINERS: remove myself as reviewer
>>> Pierrick Bouvier (2):
>>>     MAINTAINERS: add maintainer for docs/
>>>     MAINTAINERS: add reviewer for linux-user
>>>    MAINTAINERS                    |  31 +-
>>>    .gitlab-ci.d/static_checks.yml |   9 +
>>>    scripts/get_maintainer.py      | 499 +++++++++++++++++++++++++++++++++
>>>    3 files changed, 525 insertions(+), 14 deletions(-)
>>>    create mode 100755 scripts/get_maintainer.py
>>>
>>
>> Hi Alex,
>>
>> it seems like you forgot to pull this patch also:
>> https://lore.kernel.org/qemu-devel/20260115202511.2709767-1-pierrick.bouvier@linaro.org/
>>
>> Could you please include it in the current series to avoid an
>> additional month of round trip?
> 
> Hmm I did so a sweep and I didn't catch it, pulled now.
>>

Thanks.

>> Thanks,
>> Pierrick
> 

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 4045 bytes --]

On Fri, Jan 23, 2026 at 9:15 AM Alex Bennée <alex.bennee@linaro.org> wrote:

> Warner Losh <imp@bsdimp.com> writes:
>
> (Cc sniping Paolo/Peter/Markus for AI discussion)
>
> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> >  We should reflect the current status so users don't have unrealistic
> >  expectations of how quickly things can get reviewed and merged.
> >
> >  Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >
> > Reviewed-by: Warner Losh <imp@bsdimp.com>
> >
> >  ---
> >
> >  [AJB] I realise this is a slightly provocative patch but given how
> >  widely used *-user is downstream we should be clear about the current
> >  state and hopefully encourage those who rely on it to step-up.
> >
> > For the bsd-user case this is likely correct. We run hot and cold about
> being
> > proactive at fixing things, and we've been somewhat cold for a while now.
> >
> > Part of the problem is that this submission process is very very
> heavyweight
> > compared to other projects I contribute to. Not sure what to do about
> that since
> > there's a reluctance to move away from it. Or alternatively, I'm somehow
> making
> > it too hard.
>
> We have discussed in the past allowing maintainers to directly submit
> their PRs via GitLab which would be beneficial from a testing point of
> view. To move this forward someone needs to propose the changes to our
> policy documents so it can be discussed and merged.
>
> However we still expect patches to go onto the mailing list for
> review. The greybeards (like myself ;-) are very wedded to the inline
> email workflow but if we could keep that interface while making use of
> the GitLab UI for those that grew up knowing only the web maybe we could
> make the project more friendly to new contributors.
>
> I'd be interested in knowing where the pain points are for you because
> modern tools like b4 make some of the grind (collecting tags and
> applying patches from ML) a lot easier.
>

I've tried setting up b4 before. I'll have to try again.


> Usually the most difficult thing is getting email setup so you can
> git-send-email or git-publish.
>

The most difficult part for me is 'where the heck did google hide the
password
junk today' so I can turn on a password, do the submission, then kill the
password.
I really wish I could do OTP sometimes.


> > A lot of the upstreaming work that's stalled would be ideal to tell
> claude to do,
> > but I'm unsure the project's stance on using claude to move code, and
> git log
> > 5 different trees to get the original author(s) of the code and make
> trivial compile
> > tweaks.
>
> There was some discussion at the maintainers summit about relaxing the
> rules on AI submission for "mechanical" changes but it ran into the
> weeds without any firm conclusion. We could certainly revisit it.
>

Yea, it's not even mechanical changes. It's copying the work from one tree
to another
after that forked tree has been merged to the latest upstream... There's no
creativity
here at all. I'd be happy just having to write the commit messages... the
hard part is
the datamining to see who wrote things, and splitting out out function by
function
with dependencies for easy review...


> I think the concern about potential license pollution is a valid one but
> this is more of a concern for "novel" changes made by AI. I've been more
> relaxed on my personal FLOSS projects where I have allowed AI
> contributions but made it clear that the submitter is expected to
> understand whats going on. But being personal projects they are less
> likely to be spammed to death by AI slop PRs which seems to be a growing
> problem in the wider ecosystem.
>

Yea. we have a github pull request open, and we have problems from time to
time,
but have been swift to close ai chatbots and other slop we get.

Warner


> >
> > Warner
>
> --
> Alex Bennée
> Virtualisation Tech Lead @ Linaro
>

[-- Attachment #2: Type: text/html, Size: 5640 bytes --]

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 2510 bytes --]

On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <berrange@redhat.com>
wrote:

> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
> wrote:
> >
> > > We should reflect the current status so users don't have unrealistic
> > > expectations of how quickly things can get reviewed and merged.
> > >
> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> > >
> >
> > Reviewed-by: Warner Losh <imp@bsdimp.com>
>
> snip
>
> > A lot of the upstreaming work that's stalled would be ideal to tell
> claude
> > to do,
> > but I'm unsure the project's stance on using claude to move code, and git
> > log
> > 5 different trees to get the original author(s) of the code and make
> > trivial compile
> > tweaks.
>
> The critical thing we don't want is such tools making changes to the
> contents of source files.
>
> Automating the moving around of files is a non-issue.
>
> The use of AI for writing commit messages is arguably in scope of QEMU's
> AI policy given that is part of "the contribution", but it is less serious
> there, since commit messages don't have a copyright implication on what we
> host & distribute.
>
> More important is that the commit messages are accurate and well written.
> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
> course the well known danger of hallucinating nonsense. IME that makes it
> challenging to benefit from an LLM, due to review & re-writing overheads
> you then incurr to validate and fix their output.
>

Yea, the commit messages llm would generate is 'do function X' and I'd then
fill it in from there, changing everything except X.


> I'd be wary of relying on an AI to extract and report on authorship of
> code. Accuracy is important there since it implies copyright ownership
> associations. Likewise a Signed-off-by tag should be added by humans
> only since it is a statement they are complying with the DCO policy.
>

I'd be verifying everything done. Verification is relatively easy,
extraction is
the hard part. And the range of people it could be is tiny, so I'd know if
it
was making stuff up, or had gone off the rails...  And I'd have it add
something
like 'Supposed-author: ' that I'd change once I verified it. That's ugly
grunt work,
but ugly grunt work I can do in an hour or two rather than the dozens of
hours
it usually takes me to do the extraction...

Warner

[-- Attachment #2: Type: text/html, Size: 3513 bytes --]

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Konstantin Ryabitsev]

On Fri, Jan 23, 2026 at 03:09:24PM -0700, Warner Losh wrote:
> > I'd be interested in knowing where the pain points are for you because
> > modern tools like b4 make some of the grind (collecting tags and
> > applying patches from ML) a lot easier.
> 
> I've tried setting up b4 before. I'll have to try again.

I'll be happy to hear of any parts of the configuration process that weren't
obvious.

> > Usually the most difficult thing is getting email setup so you can
> > git-send-email or git-publish.
> >
> 
> The most difficult part for me is 'where the heck did google hide the
> password
> junk today' so I can turn on a password, do the submission, then kill the
> password.
> I really wish I could do OTP sometimes.

You can use the web submission endpoint with b4 submit.

-K

Re: [RFC PATCH v2 05/16] MAINTAINERS: add maintainer for docs/

[Philippe Mathieu-Daudé]

On 23/1/26 15:57, Alex Bennée wrote:
> From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> 
> I would like to help maintaining qemu documentation and I've been
> invited by Alex to apply as maintainer.
> 
> Files in docs/ that are already maintained will continue to be under
> their respective maintainer. The goal here is to have someone that can
> help on all other files that don't have an official maintainer.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> Acked-by: Daniel P. Berrangé <berrange@redhat.com>
> Acked-by: Thomas Huth <thuth@redhat.com>
> Acked-by: Alex Bennée <alex.bennee@linaro.org>
> Acked-by: Markus Armbruster <armbru@redhat.com>
> Message-ID: <20260115203529.2713193-1-pierrick.bouvier@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   MAINTAINERS | 5 +++++
>   1 file changed, 5 insertions(+)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [RFC PATCH v2 06/16] MAINTAINERS: update Arm to Supported status

[Philippe Mathieu-Daudé]

On 23/1/26 15:57, Alex Bennée wrote:
> We are involved in lots of areas of the QEMU code base but as I'm sure
> most developers will realise we are actively funded to support the Arm
> ecosystem for both emulation and virtualisation use-cases. Lets make
> that clear in MAINTAINERS to keep parity with the other Supported
> architectures.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   MAINTAINERS | 6 +++---
>   1 file changed, 3 insertions(+), 3 deletions(-)

Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [RFC PATCH v2 07/16] MAINTAINERS: add reviewer for linux-user

[Philippe Mathieu-Daudé]

On 23/1/26 15:57, Alex Bennée wrote:
> From: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> 
> I had interest in this area for some time, and would like to help
> reviewing it.
> 
> Signed-off-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>
> Acked-by: Laurent Vivier <laurent@vivier.eu>
> Reviewed-by: Richard Henderson <richard.henderson@linaro.org>
> Reviewed-by: Philippe Mathieu-Daudé <philmd@linaro.org>
> Message-ID: <20260115201712.2706663-1-pierrick.bouvier@linaro.org>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   MAINTAINERS | 1 +
>   1 file changed, 1 insertion(+)

Tested-by: Philippe Mathieu-Daudé <philmd@linaro.org>

Re: [RFC PATCH v2 01/16] MAINTAINERS: fix missing names

[Pierrick Bouvier]

On 1/23/26 6:57 AM, Alex Bennée wrote:
> The form is Name <email> so lets fix that up before we enforce it.
> 
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   MAINTAINERS | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Re: [RFC PATCH v2 04/16] MAINTAINERS: remove myself as reviewer

[Pierrick Bouvier]

On 1/23/26 6:57 AM, Alex Bennée wrote:
> From: Mads Ynddal <mads@ynddal.dk>
> 
> My work has changed focus, and I do not have the time to continue.
> 
> Signed-off-by: Mads Ynddal <mads@ynddal.dk>
> Message-ID: <20260121112725.40060-1-mads@ynddal.dk>
> Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> ---
>   MAINTAINERS | 3 ---
>   1 file changed, 3 deletions(-)
> 

Reviewed-by: Pierrick Bouvier <pierrick.bouvier@linaro.org>

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 3824 bytes --]

Just to follow up....

On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote:

>
>
> On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <berrange@redhat.com>
> wrote:
>
>> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
>> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
>> wrote:
>> >
>> > > We should reflect the current status so users don't have unrealistic
>> > > expectations of how quickly things can get reviewed and merged.
>> > >
>> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>> > >
>> >
>> > Reviewed-by: Warner Losh <imp@bsdimp.com>
>>
>> snip
>>
>> > A lot of the upstreaming work that's stalled would be ideal to tell
>> claude
>> > to do,
>> > but I'm unsure the project's stance on using claude to move code, and
>> git
>> > log
>> > 5 different trees to get the original author(s) of the code and make
>> > trivial compile
>> > tweaks.
>>
>> The critical thing we don't want is such tools making changes to the
>> contents of source files.
>>
>> Automating the moving around of files is a non-issue.
>>
>> The use of AI for writing commit messages is arguably in scope of QEMU's
>> AI policy given that is part of "the contribution", but it is less serious
>> there, since commit messages don't have a copyright implication on what we
>> host & distribute.
>>
>> More important is that the commit messages are accurate and well written.
>> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
>> course the well known danger of hallucinating nonsense. IME that makes it
>> challenging to benefit from an LLM, due to review & re-writing overheads
>> you then incurr to validate and fix their output.
>>
>
> Yea, the commit messages llm would generate is 'do function X' and I'd then
> fill it in from there, changing everything except X.
>
>
>> I'd be wary of relying on an AI to extract and report on authorship of
>> code. Accuracy is important there since it implies copyright ownership
>> associations. Likewise a Signed-off-by tag should be added by humans
>> only since it is a statement they are complying with the DCO policy.
>>
>
> I'd be verifying everything done. Verification is relatively easy,
> extraction is
> the hard part. And the range of people it could be is tiny, so I'd know if
> it
> was making stuff up, or had gone off the rails...  And I'd have it add
> something
> like 'Supposed-author: ' that I'd change once I verified it. That's ugly
> grunt work,
> but ugly grunt work I can do in an hour or two rather than the dozens of
> hours
> it usually takes me to do the extraction...
>

So, claude looks likeit's doing a passing fair job at this work. I plan on
submitting
a patch series for one of the minor files in the coming weeks (depending on
how much time I can find to work on it). Any guidance you can give me up
front?

Before I submit, I plan on auditing every single change to make sure claude
didn't introduce anything that's not in bsd-user's blitz branch. Make sure
the authors
are correct to the same level that I've been doing so far. And make sure
I've rewritten
all the commit messages.

One question I have, should include these lines
    🤖 Generated with [Claude Code](https://claude.com/claude-code)
    Co-Authored-By: Claude <noreply@anthropic.com>
it is adding to the commit messages or not? Claude generated this as a
series of
commits from the blitz branch to the master branch, but didn't actually
generate
any new code or fix any bugs. I'm happy to include them if you want, but
also
am weary about setting of a knee-jerk reaction that would be unhelpful since
it's responding to the 'slop' worries and not the merits of the current
work.

Comments?

Warner

[-- Attachment #2: Type: text/html, Size: 5358 bytes --]

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Warner Losh]

[-- Attachment #1: Type: text/plain, Size: 5484 bytes --]

On Mon, Feb 2, 2026 at 2:57 PM Warner Losh <imp@bsdimp.com> wrote:

> Just to follow up....
>
> On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote:
>
>>
>>
>> On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <berrange@redhat.com>
>> wrote:
>>
>>> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
>>> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
>>> wrote:
>>> >
>>> > > We should reflect the current status so users don't have unrealistic
>>> > > expectations of how quickly things can get reviewed and merged.
>>> > >
>>> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
>>> > >
>>> >
>>> > Reviewed-by: Warner Losh <imp@bsdimp.com>
>>>
>>> snip
>>>
>>> > A lot of the upstreaming work that's stalled would be ideal to tell
>>> claude
>>> > to do,
>>> > but I'm unsure the project's stance on using claude to move code, and
>>> git
>>> > log
>>> > 5 different trees to get the original author(s) of the code and make
>>> > trivial compile
>>> > tweaks.
>>>
>>> The critical thing we don't want is such tools making changes to the
>>> contents of source files.
>>>
>>> Automating the moving around of files is a non-issue.
>>>
>>> The use of AI for writing commit messages is arguably in scope of QEMU's
>>> AI policy given that is part of "the contribution", but it is less
>>> serious
>>> there, since commit messages don't have a copyright implication on what
>>> we
>>> host & distribute.
>>>
>>> More important is that the commit messages are accurate and well written.
>>> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
>>> course the well known danger of hallucinating nonsense. IME that makes it
>>> challenging to benefit from an LLM, due to review & re-writing overheads
>>> you then incurr to validate and fix their output.
>>>
>>
>> Yea, the commit messages llm would generate is 'do function X' and I'd
>> then
>> fill it in from there, changing everything except X.
>>
>>
>>> I'd be wary of relying on an AI to extract and report on authorship of
>>> code. Accuracy is important there since it implies copyright ownership
>>> associations. Likewise a Signed-off-by tag should be added by humans
>>> only since it is a statement they are complying with the DCO policy.
>>>
>>
>> I'd be verifying everything done. Verification is relatively easy,
>> extraction is
>> the hard part. And the range of people it could be is tiny, so I'd know
>> if it
>> was making stuff up, or had gone off the rails...  And I'd have it add
>> something
>> like 'Supposed-author: ' that I'd change once I verified it. That's ugly
>> grunt work,
>> but ugly grunt work I can do in an hour or two rather than the dozens of
>> hours
>> it usually takes me to do the extraction...
>>
>
> So, claude looks likeit's doing a passing fair job at this work. I plan on
> submitting
> a patch series for one of the minor files in the coming weeks (depending on
> how much time I can find to work on it). Any guidance you can give me up
> front?
>
> Before I submit, I plan on auditing every single change to make sure claude
> didn't introduce anything that's not in bsd-user's blitz branch. Make sure
> the authors
> are correct to the same level that I've been doing so far. And make sure
> I've rewritten
> all the commit messages.
>
> One question I have, should include these lines
>     🤖 Generated with [Claude Code](https://claude.com/claude-code)
>     Co-Authored-By: Claude <noreply@anthropic.com>
> it is adding to the commit messages or not? Claude generated this as a
> series of
> commits from the blitz branch to the master branch, but didn't actually
> generate
> any new code or fix any bugs. I'm happy to include them if you want, but
> also
> am weary about setting of a knee-jerk reaction that would be unhelpful
> since
> it's responding to the 'slop' worries and not the merits of the current
> work.
>
> Comments?
>

To not clutter up the mailing list, here's the changes. They are identical
to what's in the qemu-bsd-user blitz branch. I've not curated the commit
messages yet (they are what claude produced, but there's no copyright
issues with commit messages), but plan on doing so since glancing over them
right now I do see a few minor issues that need to be tweaked.

https://github.com/bsdimp/qemu/tree/bsd-user-claude

git diff master..bsd-user-claude --stat
 bsd-user/bsd-misc.c           | 222
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 bsd-user/bsd-misc.h           | 386
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 bsd-user/freebsd/os-syscall.c |  57 ++++++++++++++++++++++++++
 bsd-user/meson.build          |   1 +
 bsd-user/qemu-bsd.h           |  15 +++++++
 bsd-user/syscall_defs.h       |  67 +++++++++++++++++++++++++++++++
 common-user/safe-syscall.S    |   2 +-
 meson.build                   |  20 ++++-----
 8 files changed, 759 insertions(+), 11 deletions(-)

The last two are cherry-picks of something I wrote myself. The meson.build
is because inotify is now in libc, and I don't know how to express it. so I
figured if I did it wrong, somebody would help :).

Thanks in advance for any feedback you can provide.

Warner

[-- Attachment #2: Type: text/html, Size: 7474 bytes --]

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Daniel P. Berrangé]

On Mon, Feb 02, 2026 at 02:57:57PM -0700, Warner Losh wrote:
> Just to follow up....
> 
> On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote:
> 
> >
> >
> > On Fri, Jan 23, 2026 at 9:58 AM Daniel P. Berrangé <berrange@redhat.com>
> > wrote:
> >
> >> On Fri, Jan 23, 2026 at 08:12:33AM -0700, Warner Losh wrote:
> >> > On Fri, Jan 23, 2026 at 8:00 AM Alex Bennée <alex.bennee@linaro.org>
> >> wrote:
> >> >
> >> > > We should reflect the current status so users don't have unrealistic
> >> > > expectations of how quickly things can get reviewed and merged.
> >> > >
> >> > > Signed-off-by: Alex Bennée <alex.bennee@linaro.org>
> >> > >
> >> >
> >> > Reviewed-by: Warner Losh <imp@bsdimp.com>
> >>
> >> snip
> >>
> >> > A lot of the upstreaming work that's stalled would be ideal to tell
> >> claude
> >> > to do,
> >> > but I'm unsure the project's stance on using claude to move code, and
> >> git
> >> > log
> >> > 5 different trees to get the original author(s) of the code and make
> >> > trivial compile
> >> > tweaks.
> >>
> >> The critical thing we don't want is such tools making changes to the
> >> contents of source files.
> >>
> >> Automating the moving around of files is a non-issue.
> >>
> >> The use of AI for writing commit messages is arguably in scope of QEMU's
> >> AI policy given that is part of "the contribution", but it is less serious
> >> there, since commit messages don't have a copyright implication on what we
> >> host & distribute.
> >>
> >> More important is that the commit messages are accurate and well written.
> >> LLMs have a tendancy to be overly verbose about irrelevant stuff, and of
> >> course the well known danger of hallucinating nonsense. IME that makes it
> >> challenging to benefit from an LLM, due to review & re-writing overheads
> >> you then incurr to validate and fix their output.
> >>
> >
> > Yea, the commit messages llm would generate is 'do function X' and I'd then
> > fill it in from there, changing everything except X.
> >
> >
> >> I'd be wary of relying on an AI to extract and report on authorship of
> >> code. Accuracy is important there since it implies copyright ownership
> >> associations. Likewise a Signed-off-by tag should be added by humans
> >> only since it is a statement they are complying with the DCO policy.
> >>
> >
> > I'd be verifying everything done. Verification is relatively easy,
> > extraction is
> > the hard part. And the range of people it could be is tiny, so I'd know if
> > it
> > was making stuff up, or had gone off the rails...  And I'd have it add
> > something
> > like 'Supposed-author: ' that I'd change once I verified it. That's ugly
> > grunt work,
> > but ugly grunt work I can do in an hour or two rather than the dozens of
> > hours
> > it usually takes me to do the extraction...
> >
> 
> So, claude looks likeit's doing a passing fair job at this work. I plan on
> submitting
> a patch series for one of the minor files in the coming weeks (depending on
> how much time I can find to work on it). Any guidance you can give me up
> front?
> 
> Before I submit, I plan on auditing every single change to make sure claude
> didn't introduce anything that's not in bsd-user's blitz branch. Make sure
> the authors
> are correct to the same level that I've been doing so far. And make sure
> I've rewritten
> all the commit messages.
> 
> One question I have, should include these lines
>     🤖 Generated with [Claude Code](https://claude.com/claude-code)
>     Co-Authored-By: Claude <noreply@anthropic.com>

Commit message tags like this are considered to be referring to the
code in the commit body, so that would be potentially misleading.

Personally, I also don't like the concept of providing free advertizing
for commercial tools in commit messages.

If you've exclusively used it for commit metadata, then IMHO it would
be sufficient to just mention this in the cover letter description,
and explicitly say it had no part in writing the code, etc.

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Daniel P. Berrangé]

On Mon, Feb 02, 2026 at 05:49:44PM -0700, Warner Losh wrote:
> On Mon, Feb 2, 2026 at 2:57 PM Warner Losh <imp@bsdimp.com> wrote:
> 
> > Just to follow up....
> >
> > On Fri, Jan 23, 2026 at 3:14 PM Warner Losh <imp@bsdimp.com> wrote:
> > So, claude looks likeit's doing a passing fair job at this work. I plan on
> > submitting
> > a patch series for one of the minor files in the coming weeks (depending on
> > how much time I can find to work on it). Any guidance you can give me up
> > front?
> >
> > Before I submit, I plan on auditing every single change to make sure claude
> > didn't introduce anything that's not in bsd-user's blitz branch. Make sure
> > the authors
> > are correct to the same level that I've been doing so far. And make sure
> > I've rewritten
> > all the commit messages.
> >
> > One question I have, should include these lines
> >     🤖 Generated with [Claude Code](https://claude.com/claude-code)
> >     Co-Authored-By: Claude <noreply@anthropic.com>
> > it is adding to the commit messages or not? Claude generated this as a
> > series of
> > commits from the blitz branch to the master branch, but didn't actually
> > generate
> > any new code or fix any bugs. I'm happy to include them if you want, but
> > also
> > am weary about setting of a knee-jerk reaction that would be unhelpful
> > since
> > it's responding to the 'slop' worries and not the merits of the current
> > work.
> >
> > Comments?
> >
> 
> To not clutter up the mailing list, here's the changes. They are identical
> to what's in the qemu-bsd-user blitz branch. I've not curated the commit
> messages yet (they are what claude produced, but there's no copyright
> issues with commit messages), but plan on doing so since glancing over them
> right now I do see a few minor issues that need to be tweaked.

snip

> Thanks in advance for any feedback you can provide.

I glanced at the commit messages, and they look like that have avoided the
usual AI trap of being insanely verbose. They tell the "what" of the code
changes, but not so much the "why", which is common with AI since it has
no such insight.

That's not a problem per-se. The 'why' is optional for any commit. It is
applicable if there was something notable about the choices made in the
implementation that the author wants to call out to reviewers.

If the 'Generated-with/Co-authored-by' bits are removed, I think the
commit messages at least are fine to submit, if you consider them
accurate.

I'll assume all the other usual things are checked, eg that code compiles
& tests pass at each commit in the series, checkpatch.pl is clean or any
failures are jusifiably ignored as non-applicable/ false positives, etc

With regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|

Re: [RFC PATCH v2 08/16] MAINTAINERS: be realistic about *-user

[Markus Armbruster]

Daniel P. Berrangé <berrange@redhat.com> writes:

> On Mon, Feb 02, 2026 at 02:57:57PM -0700, Warner Losh wrote:

[...]

>> One question I have, should include these lines
>>     🤖 Generated with [Claude Code](https://claude.com/claude-code)
>>     Co-Authored-By: Claude <noreply@anthropic.com>
>
> Commit message tags like this are considered to be referring to the
> code in the commit body, so that would be potentially misleading.
>
> Personally, I also don't like the concept of providing free advertizing
> for commercial tools in commit messages.
>
> If you've exclusively used it for commit metadata, then IMHO it would
> be sufficient to just mention this in the cover letter description,
> and explicitly say it had no part in writing the code, etc.

+1