Status of Subsystems

Status of Subsystems

[Sebastian Duda]

Hello Pali,

in my master thesis, I'm using the association of subsystems to 
maintainers/reviewers and its status given in the MAINTAINERS file.
During the research I noticed that there are several subsystems without 
a status in the maintainers file. One of them is the subsystem `ALPS 
PS/2 TOUCHPAD DRIVER` where you're mentioned as reviewer.

Is it intended not to mention a status for your subsystems?
What is the current status of these systems?

Kind regards
Sebastian Duda

Re: Status of Subsystems

[Pali Rohár]

On Tuesday 20 August 2019 15:05:51 Sebastian Duda wrote:
> Hello Pali,
> 
> in my master thesis, I'm using the association of subsystems to
> maintainers/reviewers and its status given in the MAINTAINERS file.
> During the research I noticed that there are several subsystems without a
> status in the maintainers file. One of them is the subsystem `ALPS PS/2
> TOUCHPAD DRIVER` where you're mentioned as reviewer.
> 
> Is it intended not to mention a status for your subsystems?
> What is the current status of these systems?
> 
> Kind regards
> Sebastian Duda

Hi Sebastian! ALPS PS/2 is a driver for ALPS touchpad. They can be
found on more laptops. And ALPS PS/2 itself is not separate subsystem.
It is just driver which is part of kernel input subsystem with mailing
list linux-input@vger.kernel.org.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Status of Subsystems

[Sebastian Duda]

On 20.08.19 15:14, Pali Rohár wrote:
> On Tuesday 20 August 2019 15:05:51 Sebastian Duda wrote:
>> Hello Pali,
>>
>> in my master thesis, I'm using the association of subsystems to
>> maintainers/reviewers and its status given in the MAINTAINERS file.
>> During the research I noticed that there are several subsystems without a
>> status in the maintainers file. One of them is the subsystem `ALPS PS/2
>> TOUCHPAD DRIVER` where you're mentioned as reviewer.
>>
>> Is it intended not to mention a status for your subsystems?
>> What is the current status of these systems?
>>
>> Kind regards
>> Sebastian Duda
> 
> Hi Sebastian! ALPS PS/2 is a driver for ALPS touchpad. They can be
> found on more laptops. And ALPS PS/2 itself is not separate subsystem.
> It is just driver which is part of kernel input subsystem with mailing
> list linux-input@vger.kernel.org.
> 
Hi Pali,

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`)?

Kind regards
Sebastian Duda

Re: Status of Subsystems

[Pali Rohár]

On Tuesday 20 August 2019 15:56:24 Sebastian Duda wrote:
> On 20.08.19 15:14, Pali Rohár wrote:
> > On Tuesday 20 August 2019 15:05:51 Sebastian Duda wrote:
> > > Hello Pali,
> > > 
> > > in my master thesis, I'm using the association of subsystems to
> > > maintainers/reviewers and its status given in the MAINTAINERS file.
> > > During the research I noticed that there are several subsystems without a
> > > status in the maintainers file. One of them is the subsystem `ALPS PS/2
> > > TOUCHPAD DRIVER` where you're mentioned as reviewer.
> > > 
> > > Is it intended not to mention a status for your subsystems?
> > > What is the current status of these systems?
> > > 
> > > Kind regards
> > > Sebastian Duda
> > 
> > Hi Sebastian! ALPS PS/2 is a driver for ALPS touchpad. They can be
> > found on more laptops. And ALPS PS/2 itself is not separate subsystem.
> > It is just driver which is part of kernel input subsystem with mailing
> > list linux-input@vger.kernel.org.
> > 
> Hi Pali,
> 
> 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`)?
> 
> Kind regards
> Sebastian Duda

Hi Sebastian, by status you mean if driver are maintained or orphaned?
I think that definition of it applies from subsystem itself too. But
maintainers of correspondent subsystem would tell you definite answer if
they want to maintain these drivers or not. I should be there marked as
reviewer and I'm reviewing patches for these drivers if I see them in my
mailbox.

-- 
Pali Rohár
pali.rohar@gmail.com

Re: Status of Subsystems

[Joe Perches]

On Tue, 2019-08-20 at 15:56 +0200, Sebastian Duda wrote:
> On 20.08.19 15:14, Pali Rohár wrote:
> > On Tuesday 20 August 2019 15:05:51 Sebastian Duda wrote:
> > > Hello Pali,
> > > 
> > > in my master thesis, I'm using the association of subsystems to
> > > maintainers/reviewers and its status given in the MAINTAINERS file.
> > > During the research I noticed that there are several subsystems without a
> > > status in the maintainers file. One of them is the subsystem `ALPS PS/2
> > > TOUCHPAD DRIVER` where you're mentioned as reviewer.
> > > 
> > > Is it intended not to mention a status for your subsystems?
> > > What is the current status of these systems?
> > > 
> > > Kind regards
> > > Sebastian Duda
> > 
> > Hi Sebastian! ALPS PS/2 is a driver for ALPS touchpad. They can be
> > found on more laptops. And ALPS PS/2 itself is not separate subsystem.
> > It is just driver which is part of kernel input subsystem with mailing
> > list linux-input@vger.kernel.org.
> > 
> Hi Pali,
> 
> so the status of the files is inherited from the subsystem `INPUT 
> MULTITOUCH (MT) PROTOCOL`?

Not really, no.

It's inherited from

MAINTAINERS-INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS
MAINTAINERS-M:  Dmitry Torokhov <dmitry.torokhov@gmail.com>
MAINTAINERS-L:  linux-input@vger.kernel.org
MAINTAINERS-Q:  http://patchwork.kernel.org/project/linux-input/list/
MAINTAINERS-T:  git git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
MAINTAINERS-S:  Maintained
MAINTAINERS:F:  drivers/input/
MAINTAINERS-F:  include/linux/input.h
MAINTAINERS-F:  include/uapi/linux/input.h
MAINTAINERS-F:  include/uapi/linux/input-event-codes.h
MAINTAINERS-F:  include/linux/input/
MAINTAINERS-F:  Documentation/devicetree/bindings/input/
MAINTAINERS-F:  Documentation/devicetree/bindings/serio/
MAINTAINERS-F:  Documentation/input/

You could see this via

$ ./scripts/get_maintainer.pl -f --sections drivers/input/mouse/alps.c
ALPS PS/2 TOUCHPAD DRIVER
R:	Pali Rohár <pali.rohar@gmail.com>
F:	drivers/input/mouse/alps.*

INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS
M:	Dmitry Torokhov <dmitry.torokhov@gmail.com>
L:	linux-input@vger.kernel.org
Q:	http://patchwork.kernel.org/project/linux-input/list/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input.git
S:	Maintained
F:	drivers/input/
F:	include/linux/input.h
F:	include/uapi/linux/input.h
F:	include/uapi/linux/input-event-codes.h
F:	include/linux/input/
F:	Documentation/devicetree/bindings/input/
F:	Documentation/devicetree/bindings/serio/
F:	Documentation/input/

THE REST
M:	Linus Torvalds <torvalds@linux-foundation.org>
L:	linux-kernel@vger.kernel.org
Q:	http://patchwork.kernel.org/project/LKML/list/
T:	git git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
S:	Buried alive in reporters
F:	*
F:	*/

Re: Status of Subsystems

[Theodore Y. Ts'o]

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

Re: Status of Subsystems

[Enrico Weigelt, metux IT consult]

On 20.08.19 19:15, Theodore Y. Ts'o wrote:

Hi,

> There are some files which have no official
> owner, and there are also some files which may be modified by more
> than one subsystem.

hmm, wouldn't it be better to alway have explicit maintainers ?

I recall some discussion few weeks ago on some of my patches, where it
turned out that amm acts as fallback for a lot of code that doesn't have
a maintainer.

@Sebastian: maybe you could also create reports for quickly identifying
those cases.

> We certainly don't talk about "inheritance" when we talk about
> maintainers and sub-maintainers. 

What's the exact definition of the term "sub-maintainer" ?

Somebody who's maintaining some defined part of something bigger
(eg. a driver within some subsystem, some platform within some
arch, etc) or kinda deputee maintainer ?

> Furthermore, the relationships,
> processes, and workflows between a particular maintainer and their
> submaintainers can be unique to a particular maintainer.

Can we somehow find some (semi-formal) description for those
relationships and workflows, so it's easier to learn about them
when some is new to some particular area ?

(I'd volounteer maintaining such documentation, if the individual
maintainers feed me the necessary information ;-)).


--mtx

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

Re: Status of Subsystems

[Sebastian Duda]

Hi,

below is a list of files explicitly mentioned twice (or more) in the 
MAINTAINERS file.

Kind regards
Sebastian

On 21.08.19 14:10, Enrico Weigelt, metux IT consult wrote:
> On 20.08.19 19:15, Theodore Y. Ts'o wrote:
> 
> Hi,
> 
>> There are some files which have no official
>> owner, and there are also some files which may be modified by more
>> than one subsystem.
> 
> hmm, wouldn't it be better to alway have explicit maintainers ?
> 
> I recall some discussion few weeks ago on some of my patches, where it
> turned out that amm acts as fallback for a lot of code that doesn't have
> a maintainer.
> 
> @Sebastian: maybe you could also create reports for quickly identifying
> those cases.
> 
>> We certainly don't talk about "inheritance" when we talk about
>> maintainers and sub-maintainers. 
> 
> What's the exact definition of the term "sub-maintainer" ?
> 
> Somebody who's maintaining some defined part of something bigger
> (eg. a driver within some subsystem, some platform within some
> arch, etc) or kinda deputee maintainer ?
> 
>> Furthermore, the relationships,
>> processes, and workflows between a particular maintainer and their
>> submaintainers can be unique to a particular maintainer.
> 
> Can we somehow find some (semi-formal) description for those
> relationships and workflows, so it's easier to learn about them
> when some is new to some particular area ?
> 
> (I'd volounteer maintaining such documentation, if the individual
> maintainers feed me the necessary information ;-)).
> 
> 
> --mtx
> 

Documentation/security/keys/trusted-encrypted.rst
drivers/power/supply/bq27xxx_battery.c
tools/power/acpi/
include/linux/lockd/
net/sunrpc/
drivers/i2c/busses/i2c-qcom-geni.c
drivers/block/virtio_blk.c
Documentation/devicetree/bindings/mfd/atmel-usart.txt
Documentation/i2c/busses/i2c-ali1563
include/linux/hippidevice.h
Documentation/PCI/pci-error-recovery.rst
include/linux/vga*
fs/nfs_common/
include/linux/pm.h
drivers/crypto/virtio/
include/linux/mlx5/
drivers/media/tuners/tda8290.*
drivers/crypto/nx/Kconfig
arch/x86/include/asm/pvclock-abi.h
drivers/scsi/53c700*
fs/lockd/
drivers/staging/iio/
drivers/i2c/busses/i2c-omap.c
Documentation/admin-guide/ras.rst
include/acpi/
drivers/staging/greybus/spi.c
drivers/base/power/
include/uapi/linux/media.h
include/uapi/linux/cciss*.h
include/linux/suspend.h
include/uapi/linux/uvcvideo.h
include/trace/events/xdp.h
drivers/staging/greybus/spilib.c
include/linux/cfag12864b.h
Documentation/devicetree/bindings/arm/renesas.yaml
include/linux/soc/renesas/
Documentation/scsi/NinjaSCSI.txt
include/linux/sunrpc/
drivers/crypto/nx/Makefile
drivers/gpu/vga/
include/linux/platform_data/i2c-omap.h
drivers/power/supply/bq27xxx_battery_i2c.c
drivers/mtd/nand/raw/ingenic/
drivers/i2c/busses/i2c-ali1563.c
drivers/soc/renesas/
include/uapi/linux/sunrpc/
drivers/md/Makefile
include/linux/power/bq27xxx_battery.h
include/linux/dmaengine.h
drivers/gpio/gpio-intel-mid.c
drivers/dma/
include/uapi/linux/ivtv*
kernel/power/
drivers/gpio/gpio-ich.c
drivers/net/ethernet/ibm/ibmvnic.*
include/linux/netdevice.h
include/linux/mlx4/
drivers/net/ethernet/ibm/ibmveth.*
drivers/media/platform/mtk-vpu/
drivers/dma/dma-jz4780.c
include/uapi/linux/meye.h
include/uapi/linux/netdevice.h
arch/arm/plat-omap/
include/linux/freezer.h
include/linux/cciss*.h
Documentation/gpu/
drivers/md/Kconfig
include/linux/cpu_cooling.h
include/linux/pwm_backlight.h
arch/mips/include/asm/mach-loongson64/

Re: Status of Subsystems

[Theodore Y. Ts'o]

On Wed, Aug 21, 2019 at 02:10:13PM +0200, Enrico Weigelt, metux IT consult wrote:
> 
> > We certainly don't talk about "inheritance" when we talk about
> > maintainers and sub-maintainers.
> 
> What's the exact definition of the term "sub-maintainer" ?
> 
> Somebody who's maintaining some defined part of something bigger
> (eg. a driver within some subsystem, some platform within some
> arch, etc) or kinda deputee maintainer ?

"It varies".  That was my whole point.

And there are some files, such as fs/fs-writeback.c which is rarely
touched by Al Viro (the fs maintainer) and mm/page-writeback.c (which
is rarely touched by the MM maintainers).  Both of these files are
related to writeback of buffered writeback, and the people who touch
are a smaller set of file system maintainers, and discussions
generally happen on linux-fsdevel.

Which git trees these changes go up through are also not necessarily
as specified by the maintainers files, for a number of reasons,
including avoiding git merge conflicts.

There is a desire to document more of these branch specific issues
(for example, the Networking branch has very specific times when
patches will be accepted for review) but that's a work in progress.
And I think a lot of people have been nervous about documenting
things, since once documented, there are process mavens will say, "you
documented it as FOO" and now you are doing BAR and complain that it's
a process violation, when in fact all rules have exceptions, and
sometimes those exceptions and when they get invoked are complicated.
Worse yet is when the documentation isn't precisely correct, and then
they get taken as gospel truth.

That doesn't mean we shouldn't document them, but a lot of care needs
to be taken.  It's also hard because the people who know the processes
the best are also some of the more busy people, and the downside if
the processes aren't documented *precisely* with most exceptions
documented, etc., are the same people.  (See the discussion over what
does "Reviewed-by" mean, and what meaning attaches to it as an example
where IMHO how it was used, and how it was documented, were not the
same thing.)

Cheers,

					- Ted

Re: Status of Subsystems

[Sebastian Duda]

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

Re: Status of Subsystems

[Enrico Weigelt, metux IT consult]

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