Message-ID: <e222bc6c-aff0-899c-b113-47f7f1798fe1@metux.net>
Date:   Thu, 22 Aug 2019 14:49:29 +0200
From:   "Enrico Weigelt, metux IT consult" <lkml@...ux.net>
To:     Sebastian Duda <sebastian.duda@....de>,
        "Theodore Y. Ts'o" <tytso@....edu>,
        Pali Rohár <pali.rohar@...il.com>,
        linux-kernel@...r.kernel.org, lukas.bulwahn@...il.com
Subject: Re: Status of Subsystems

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@...ux.net -- +49-151-27565287

Powered by blists - more mailing lists