Re: Status of Subsystems - MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO
Sebastian, On 20/08/2019 at 15:27, Sebastian Duda wrote: > Hello Andrei, > > 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 > `MICROCHIP SAMA5D2-COMPATIBLE PIOBU GPIO` where you're mentioned as > maintainer. > > Is it intended not to mention a status for your subsystems? > What is the current status of your subsystem? I've just removed this entry and merged it with other gpio/pinctrl driver's entry: https://lore.kernel.org/linux-arm-kernel/20190823083158.2649-1-nicolas.fe...@microchip.com/ Best regards, -- Nicolas Ferre
Re: Status of Subsystems
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
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 i...@metux.net -- +49-151-27565287
Re: Status of Subsystems
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
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 - TI BQ27XXX POWER SUPPLY DRIVER
On 8/20/19 10:00 AM, Sebastian Duda wrote: > Hello Andrew, > > 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 `TI > BQ27XXX POWER SUPPLY DRIVER` where you're mentioned as reviewer. > > Is it intended not to mention a status for your subsystems? > What is the current status of your subsystem? > 'TI BQ27XXX POWER SUPPLY DRIVER' is a driver, not a subsystem. It is part of the maintained 'Power supplies' subsystem, hence I only review patches for it, but am not the maintainer. Thanks, Andrew > Kind regards > Sebastian Duda
Re: Status of Subsystems
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 i...@metux.net -- +49-151-27565287
Re: Status of Subsystems
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
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-in...@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 MAINTAINERS-L: linux-in...@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 F: drivers/input/mouse/alps.* INPUT (KEYBOARD, MOUSE, JOYSTICK, TOUCHSCREEN) DRIVERS M: Dmitry Torokhov L: linux-in...@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 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
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-in...@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.ro...@gmail.com
Re: Status of Subsystems
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-in...@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
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-in...@vger.kernel.org. -- Pali Rohár pali.ro...@gmail.com
