Date:   Thu, 22 Aug 2019 11:28:33 +0200
From:   Sebastian Duda <sebastian.duda@....de>
To:     "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

Hi Ted,

On 20.08.19 19:15, Theodore Y. Ts'o wrote:
> On Tue, Aug 20, 2019 at 03:56:24PM +0200, Sebastian Duda wrote:
>>
>> so the status of the files is inherited from the subsystem `INPUT MULTITOUCH
>> (MT) PROTOCOL`?
>>
>> Is it the same with the subsystem `NOKIA N900 POWER SUPPLY DRIVERS`
>> (respectively `POWER SUPPLY CLASS/SUBSYSTEM and DRIVERS`)?
> 
> Note that the definitions of "subsystems" is not necessarily precise.
> So assuming there is a strict subclassing and inheritance might not be
> a perfect assumption.  There are some files which have no official
> owner, and there are also some files which may be modified by more
> than one subsystem.
> 
> We certainly don't talk about "inheritance" when we talk about
> maintainers and sub-maintainers.  Furthermore, the relationships,
> processes, and workflows between a particular maintainer and their
> submaintainers can be unique to a particular maintainer.
> 
> We define these terms to be convenient for Linux development, and like
> many human institutions, they can be flexible and messy.  The goal was
> *not* define things so it would be convenient for academics writing
> papers --- like insects under glass.
> 
> Cheers,
> 
> 						- Ted
> 

This is completely understood. The purpose of the MAINTAINERS is to
determine the right recipients for a patch and the status should make
expectations on certain code parts clear to contributors and users.

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).
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.
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.
  - to a user that certain drivers are orphaned and one should not
expect open issues to be quickly fixed by others.

I am simply spending some time to identify the few entries that are
just a bit unclear and I try to improve the file by sending patches
for MAINTAINERS once I understood what it intends to say.

 From what the kernel community has been documenting in MAINTAINERS,
the organization of the Linux development is not messy at all:

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

The previous mail discussion helped to understand that.

I aim to provide patches for those few entries that can be improved;
it is hopefully not just an academic exercise, but actually serves to
support contributors and users using MAINTAINERS and get_maintainer.pl.

Kind regards
Sebastian

[1] MAINTAINERS without header, count matches of r'\n\n' + 1

Powered by blists - more mailing lists