linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Enrico Weigelt, metux IT consult" <lkml@metux.net>
To: "Sebastian Duda" <sebastian.duda@fau.de>,
	"Theodore Y. Ts'o" <tytso@mit.edu>,
	"Pali Rohár" <pali.rohar@gmail.com>,
	linux-kernel@vger.kernel.org, lukas.bulwahn@gmail.com
Subject: Re: Status of Subsystems
Date: Thu, 22 Aug 2019 14:49:29 +0200	[thread overview]
Message-ID: <e222bc6c-aff0-899c-b113-47f7f1798fe1@metux.net> (raw)
In-Reply-To: <475ea59c-8942-c19d-c660-164fcb44d179@fau.de>

On 22.08.19 11:28, Sebastian Duda wrote:

Hello Sabastian,


> We have seen some incidents of developers sending patches to wrong
> recipients, missing recipients or sending patches to orphaned
> subsystems. Consequently, some of those patches never make it to a
> reviewer or a maintainer (or only after some further adjustments on
> the list of recipients).

yes, I've stumpled into this myself :(

Do you see any chance for some tool-based assistance ?

Few ideas coming into my mind:

a) kernel.org ops could collect bouncing addresses and match them
    against the MAINTAINERS file. Maybe post an alert with specific
    syntax (so it's easy to filter/monitor), so we can look around
    how to reach the missing folks (already did so myself). Sometimes
    those messages reach the missing folks by some other channel.

b) automatic scan/report for duplicate or unclaimed files.
    maybe this topic just needs more awareness.

    IMHO, every file should have a maintainer, because just posting to
    lkml globally has high risk of getting unnoticed.

c) automatic report of potentially unmaintained areas, so


By the way: if you prefer a more personal conversation, feel free to
call me (I'm settled @Schwabach)

I'm already keen on reading your thesis paper. (and if there's a public
presentation, I'd like to be there). You've picked a very good, useful
topic - we need more of that :)

> Whereas that cannot be avoided entirely, as it is a human, social and
> flexible process and not everything can be encoded in simple rules,
> the maintainer, reviewer, list information in MAINTAINERS and
> get_maintainer.pl does a good job at assisting that these hickups
> happen rather seldomly.

Yes, but it can only work well with good data. So it's good that you
take care of that. And if you can improve the performance of this
script, I'd highly welcome that.

I'd like to recommend you as the maintainer of the MAINTAINERS file ;-)

> Similarly, the status can already indicate:
>   - to a contributor fixing an issues or providing a patch, that the
> code is possibly already orphaned and not maintained, set expectations
> on the possible responses, or to focus on other parts of the code.

Orphaned code IMHO deserves it's own discussion. Maybe we should have
some comments on why exactly orphaned/obsolete but still there (just no
maintainer anymore ? obsoleted by something else ? ...).

> The MAINTAINERS files contains 2088 entries [1].
> 12 of these entries have no status and fall into different categories:
> - Additionally Reviewed
>    - ALPS PS/2 TOUCHPAD DRIVER
>    - NOKIA N900 POWER SUPPLY DRIVERS
>    - RENESAS ETHERNET DRIVERS
>    - SPMI SUBSYSTEM
>    - TI BQ27XXX POWER SUPPLY DRIVER
> - Maintained
>    - ABI/API
>    - ACPI APEI
>    - CONTROL GROUP - BLOCK IO CONTROLLER (BLKIO)
>    - I2C/SMBUS ISMT DRIVER
>    - IFE PROTOCOL
>    - MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
> - Obsolete
>    - NETWORKING [WIRELESS]
>      This is an old entry, which can be omitted

There're also some with status "Orphaned / Obsolete" - did you already
catch them ?

--mtx

-- 
Enrico Weigelt, metux IT consult
Free software and Linux embedded engineering
info@metux.net -- +49-151-27565287

      reply	other threads:[~2019-08-22 12:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-20 13:05 Status of Subsystems Sebastian Duda
2019-08-20 13:14 ` Pali Rohár
2019-08-20 13:56   ` Sebastian Duda
2019-08-20 14:05     ` Pali Rohár
2019-08-20 14:09     ` Joe Perches
2019-08-20 17:15     ` Theodore Y. Ts'o
2019-08-21 12:10       ` Enrico Weigelt, metux IT consult
2019-08-22 10:54         ` Sebastian Duda
2019-08-22 14:08         ` Theodore Y. Ts'o
2019-08-22  9:28       ` Sebastian Duda
2019-08-22 12:49         ` Enrico Weigelt, metux IT consult [this message]

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=e222bc6c-aff0-899c-b113-47f7f1798fe1@metux.net \
    --to=lkml@metux.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lukas.bulwahn@gmail.com \
    --cc=pali.rohar@gmail.com \
    --cc=sebastian.duda@fau.de \
    --cc=tytso@mit.edu \
    /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).