[PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

All files in drivers/firmware/google/ are identified as part of THE REST
according to MAINTAINERS, but they are really maintained by others.

Add a basic entry for drivers/firmware/google/ based on a simple statistics
on tags of commits in that directory:

  $ git log drivers/firmware/google/ | grep '\-by:' \
      | sort | uniq -c | sort -nr
     62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
     13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
     12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
     11     Reviewed-by: Julius Werner <jwerner@chromium.org>

There is no specific mailing list for this driver, based on observations
on the patch emails, and the git history suggests the driver is maintained.

This was identified with a small script that finds all files belonging to
THE REST according to the current MAINTAINERS file, and I investigated
upon its output.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a0f8115c92c..ed788804daab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7111,6 +7111,14 @@ S:	Supported
 F:	Documentation/networking/device_drivers/google/gve.rst
 F:	drivers/net/ethernet/google
 
+GOOGLE FIRMWARE
+M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+M:	Stephen Boyd <swboyd@chromium.org>
+R:	Guenter Roeck <groeck@chromium.org>
+R:	Julius Werner <jwerner@chromium.org>
+S:	Maintained
+F:	drivers/firmware/google/
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede@redhat.com>
 L:	platform-driver-x86@vger.kernel.org
-- 
2.17.1

[PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

All files in drivers/firmware/google/ are identified as part of THE REST
according to MAINTAINERS, but they are really maintained by others.

Add a basic entry for drivers/firmware/google/ based on a simple statistics
on tags of commits in that directory:

  $ git log drivers/firmware/google/ | grep '\-by:' \
      | sort | uniq -c | sort -nr
     62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
     13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
     12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
     11     Reviewed-by: Julius Werner <jwerner@chromium.org>

There is no specific mailing list for this driver, based on observations
on the patch emails, and the git history suggests the driver is maintained.

This was identified with a small script that finds all files belonging to
THE REST according to the current MAINTAINERS file, and I investigated
upon its output.

Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
---
 MAINTAINERS | 8 ++++++++
 1 file changed, 8 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index 3a0f8115c92c..ed788804daab 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7111,6 +7111,14 @@ S:	Supported
 F:	Documentation/networking/device_drivers/google/gve.rst
 F:	drivers/net/ethernet/google
 
+GOOGLE FIRMWARE
+M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
+M:	Stephen Boyd <swboyd@chromium.org>
+R:	Guenter Roeck <groeck@chromium.org>
+R:	Julius Werner <jwerner@chromium.org>
+S:	Maintained
+F:	drivers/firmware/google/
+
 GPD POCKET FAN DRIVER
 M:	Hans de Goede <hdegoede@redhat.com>
 L:	platform-driver-x86@vger.kernel.org
-- 
2.17.1

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Greg Kroah-Hartman]

On Sun, Mar 08, 2020 at 08:51:16PM +0100, Lukas Bulwahn wrote:
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
> 
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
> 
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
> 
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.
> 
> This was identified with a small script that finds all files belonging to
> THE REST according to the current MAINTAINERS file, and I investigated
> upon its output.
> 
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3a0f8115c92c..ed788804daab 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7111,6 +7111,14 @@ S:	Supported
>  F:	Documentation/networking/device_drivers/google/gve.rst
>  F:	drivers/net/ethernet/google
>  
> +GOOGLE FIRMWARE
> +M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>

No, sorry, I am not the maintainer of this.  I'll be glad to be the
person the maintainers send patches to to get into Linus's tree, but I
am not going to be responsible for stuff I know nothing about :)

thanks,

greg k-h

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Greg Kroah-Hartman]

On Sun, Mar 08, 2020 at 08:51:16PM +0100, Lukas Bulwahn wrote:
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
> 
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
> 
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
> 
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.
> 
> This was identified with a small script that finds all files belonging to
> THE REST according to the current MAINTAINERS file, and I investigated
> upon its output.
> 
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
> 
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3a0f8115c92c..ed788804daab 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7111,6 +7111,14 @@ S:	Supported
>  F:	Documentation/networking/device_drivers/google/gve.rst
>  F:	drivers/net/ethernet/google
>  
> +GOOGLE FIRMWARE
> +M:	Greg Kroah-Hartman <gregkh@linuxfoundation.org>

No, sorry, I am not the maintainer of this.  I'll be glad to be the
person the maintainers send patches to to get into Linus's tree, but I
am not going to be responsible for stuff I know nothing about :)

thanks,

greg k-h

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Sun, 2020-03-08 at 20:51 +0100, Lukas Bulwahn wrote:
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
> 
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
> 
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
> 
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.

The sign-off list is definitely not the MAINTAINER list
as that sign-off list can identify the upstreaming path
and not the actual maintainers.

You should instead try to identify the MAINTAINERS as authors
of the various patches rather than the sign-off list.

And even then you need to isolate the trivial changes from
the actual defect correction and significant features added.

And also time-limit the range of commits as people come and
go and only relatively recent changes should be analyzed.

For instance:

$ git log --since=2-years-ago --no-merges --pretty="%aN <%aE>	%s" -- drivers/firmware/google
Gustavo A. R. Silva <gustavo@embeddedor.com>    firmware: google: vpd: Replace zero-length array with flexible-array member
Gustavo A. R. Silva <gustavo@embeddedor.com>    firmware: google: memconsole: Replace zero-length array with flexible-array member
Arthur Heymans <arthur@aheymans.xyz>    firmware: google: Probe for a GSMI handler in firmware
Arthur Heymans <arthur@aheymans.xyz>    firmware: google: Unregister driver_info on failure and exit in gsmi
Patrick Rudolph <patrick.rudolph@9elements.com> firmware: google: Release devices before unregistering the bus
Brian Norris <briannorris@chromium.org> firmware: google: increment VPD key_len properly
Hung-Te Lin <hungte@chromium.org>       firmware: google: check if size is valid when decoding VPD data
Thomas Gleixner <tglx@linutronix.de>    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 287
Stephen Boyd <swboyd@chromium.org>      firmware: google: coreboot: Drop unnecessary headers
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Drop global func pointer
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Drop __iomem on memremap memory
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Use devm_memremap()
Stephen Boyd <swboyd@chromium.org>      firmware: google: Add a module_coreboot_driver() macro and use it
Thomas Gleixner <tglx@linutronix.de>    treewide: Add SPDX license identifier - Makefile/Kconfig
Thomas Gleixner <tglx@linutronix.de>    treewide: Add SPDX license identifier for more missed files
Stephen Boyd <swboyd@chromium.org>      firmware: vpd: Drop __iomem usage for memremap() memory
Furquan Shaikh <furquan@chromium.org>   gsmi: Add GSMI commands to log S0ix info
Duncan Laurie <dlaurie@chromium.org>    gsmi: Remove autoselected dependency on EFI and EFI_VARS
Duncan Laurie <dlaurie@chromium.org>    gsmi: Add coreboot to list of matching BIOS vendors
Duncan Laurie <dlaurie@chromium.org>    gsmi: Fix bug in append_to_eventlog sysfs handler
Colin Ian King <colin.king@canonical.com>       firmware: vpd: fix spelling mistake "partion" -> "partition"
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Only populate devices in coreboot_table_init()
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Remap RAM with memremap() instead of ioremap()
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Collapse platform drivers into bus core
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Make bus registration symmetric
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Unmap ioregion after device population
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Let OF core populate platform device
Colin Ian King <colin.king@canonical.com>       firmware: google: make structure gsmi_dev static
Anton Vasilyev <vasilyev@ispras.ru>     firmware: vpd: Fix section enabled flag on vpd_section_destroy
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Add coreboot framebuffer driver
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Remove unused coreboot_table_find
Samuel Holland <samuel@sholland.org>    firmware: vpd: Probe via coreboot bus
Samuel Holland <samuel@sholland.org>    firmware: memconsole: Probe via coreboot bus
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Expose the coreboot table as a bus

Thomas Gleixner did licensing changes treewide which
would have no maintainer role, Gustavo Silva did generic
style changes and Stephen Boyd is really the only party
here that has done fundamental changes.

It's not an easy problem, but adding

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Sun, 2020-03-08 at 20:51 +0100, Lukas Bulwahn wrote:
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
> 
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
> 
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
> 
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.

The sign-off list is definitely not the MAINTAINER list
as that sign-off list can identify the upstreaming path
and not the actual maintainers.

You should instead try to identify the MAINTAINERS as authors
of the various patches rather than the sign-off list.

And even then you need to isolate the trivial changes from
the actual defect correction and significant features added.

And also time-limit the range of commits as people come and
go and only relatively recent changes should be analyzed.

For instance:

$ git log --since=2-years-ago --no-merges --pretty="%aN <%aE>	%s" -- drivers/firmware/google
Gustavo A. R. Silva <gustavo@embeddedor.com>    firmware: google: vpd: Replace zero-length array with flexible-array member
Gustavo A. R. Silva <gustavo@embeddedor.com>    firmware: google: memconsole: Replace zero-length array with flexible-array member
Arthur Heymans <arthur@aheymans.xyz>    firmware: google: Probe for a GSMI handler in firmware
Arthur Heymans <arthur@aheymans.xyz>    firmware: google: Unregister driver_info on failure and exit in gsmi
Patrick Rudolph <patrick.rudolph@9elements.com> firmware: google: Release devices before unregistering the bus
Brian Norris <briannorris@chromium.org> firmware: google: increment VPD key_len properly
Hung-Te Lin <hungte@chromium.org>       firmware: google: check if size is valid when decoding VPD data
Thomas Gleixner <tglx@linutronix.de>    treewide: Replace GPLv2 boilerplate/reference with SPDX - rule 287
Stephen Boyd <swboyd@chromium.org>      firmware: google: coreboot: Drop unnecessary headers
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Drop global func pointer
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Drop __iomem on memremap memory
Stephen Boyd <swboyd@chromium.org>      firmware: google: memconsole: Use devm_memremap()
Stephen Boyd <swboyd@chromium.org>      firmware: google: Add a module_coreboot_driver() macro and use it
Thomas Gleixner <tglx@linutronix.de>    treewide: Add SPDX license identifier - Makefile/Kconfig
Thomas Gleixner <tglx@linutronix.de>    treewide: Add SPDX license identifier for more missed files
Stephen Boyd <swboyd@chromium.org>      firmware: vpd: Drop __iomem usage for memremap() memory
Furquan Shaikh <furquan@chromium.org>   gsmi: Add GSMI commands to log S0ix info
Duncan Laurie <dlaurie@chromium.org>    gsmi: Remove autoselected dependency on EFI and EFI_VARS
Duncan Laurie <dlaurie@chromium.org>    gsmi: Add coreboot to list of matching BIOS vendors
Duncan Laurie <dlaurie@chromium.org>    gsmi: Fix bug in append_to_eventlog sysfs handler
Colin Ian King <colin.king@canonical.com>       firmware: vpd: fix spelling mistake "partion" -> "partition"
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Only populate devices in coreboot_table_init()
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Remap RAM with memremap() instead of ioremap()
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Collapse platform drivers into bus core
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Make bus registration symmetric
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Unmap ioregion after device population
Stephen Boyd <swboyd@chromium.org>      firmware: coreboot: Let OF core populate platform device
Colin Ian King <colin.king@canonical.com>       firmware: google: make structure gsmi_dev static
Anton Vasilyev <vasilyev@ispras.ru>     firmware: vpd: Fix section enabled flag on vpd_section_destroy
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Add coreboot framebuffer driver
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Remove unused coreboot_table_find
Samuel Holland <samuel@sholland.org>    firmware: vpd: Probe via coreboot bus
Samuel Holland <samuel@sholland.org>    firmware: memconsole: Probe via coreboot bus
Samuel Holland <samuel@sholland.org>    firmware: coreboot: Expose the coreboot table as a bus

Thomas Gleixner did licensing changes treewide which
would have no maintainer role, Gustavo Silva did generic
style changes and Stephen Boyd is really the only party
here that has done fundamental changes.

It's not an easy problem, but adding

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Guenter Roeck]

On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
>
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
>
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
>
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.
>
> This was identified with a small script that finds all files belonging to
> THE REST according to the current MAINTAINERS file, and I investigated
> upon its output.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3a0f8115c92c..ed788804daab 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7111,6 +7111,14 @@ S:       Supported
>  F:     Documentation/networking/device_drivers/google/gve.rst
>  F:     drivers/net/ethernet/google
>
> +GOOGLE FIRMWARE
> +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> +M:     Stephen Boyd <swboyd@chromium.org>
> +R:     Guenter Roeck <groeck@chromium.org>
> +R:     Julius Werner <jwerner@chromium.org>
> +S:     Maintained
> +F:     drivers/firmware/google/
> +

FWIW, I would not mind stepping up as maintainer if needed, but I
think we should strongly discourage this kind of auto-assignment of
maintainers and/or reviewers.

Guenter

>  GPD POCKET FAN DRIVER
>  M:     Hans de Goede <hdegoede@redhat.com>
>  L:     platform-driver-x86@vger.kernel.org
> --
> 2.17.1
>

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Guenter Roeck]

On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
>
> All files in drivers/firmware/google/ are identified as part of THE REST
> according to MAINTAINERS, but they are really maintained by others.
>
> Add a basic entry for drivers/firmware/google/ based on a simple statistics
> on tags of commits in that directory:
>
>   $ git log drivers/firmware/google/ | grep '\-by:' \
>       | sort | uniq -c | sort -nr
>      62     Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>      13     Reviewed-by: Guenter Roeck <groeck@chromium.org>
>      12     Signed-off-by: Stephen Boyd <swboyd@chromium.org>
>      11     Reviewed-by: Julius Werner <jwerner@chromium.org>
>
> There is no specific mailing list for this driver, based on observations
> on the patch emails, and the git history suggests the driver is maintained.
>
> This was identified with a small script that finds all files belonging to
> THE REST according to the current MAINTAINERS file, and I investigated
> upon its output.
>
> Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> ---
>  MAINTAINERS | 8 ++++++++
>  1 file changed, 8 insertions(+)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 3a0f8115c92c..ed788804daab 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -7111,6 +7111,14 @@ S:       Supported
>  F:     Documentation/networking/device_drivers/google/gve.rst
>  F:     drivers/net/ethernet/google
>
> +GOOGLE FIRMWARE
> +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> +M:     Stephen Boyd <swboyd@chromium.org>
> +R:     Guenter Roeck <groeck@chromium.org>
> +R:     Julius Werner <jwerner@chromium.org>
> +S:     Maintained
> +F:     drivers/firmware/google/
> +

FWIW, I would not mind stepping up as maintainer if needed, but I
think we should strongly discourage this kind of auto-assignment of
maintainers and/or reviewers.

Guenter

>  GPD POCKET FAN DRIVER
>  M:     Hans de Goede <hdegoede@redhat.com>
>  L:     platform-driver-x86@vger.kernel.org
> --
> 2.17.1
>

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > All files in drivers/firmware/google/ are identified as part of THE REST
> > according to MAINTAINERS, but they are really maintained by others.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > @@ -7111,6 +7111,14 @@ S:       Supported
> >  F:     Documentation/networking/device_drivers/google/gve.rst
> >  F:     drivers/net/ethernet/google
> > 
> > +GOOGLE FIRMWARE
> > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > +M:     Stephen Boyd <swboyd@chromium.org>
> > +R:     Guenter Roeck <groeck@chromium.org>
> > +R:     Julius Werner <jwerner@chromium.org>
> > +S:     Maintained
> > +F:     drivers/firmware/google/
> > +
> 
> FWIW, I would not mind stepping up as maintainer if needed, but I
> think we should strongly discourage this kind of auto-assignment of
> maintainers and/or reviewers.

Auto assignment should definitely _not_ be done.

This is an RFC proposal though.

Sometimes it's better to not produce an RFC as
a patch, but maybe just show a proposed section
and ask if is appropriate may be a better style
going forward.

Maybe just emailing Greg, Stephen, Guenter and
Julius (cc'ing LKML) asking something like the
below would be better:

----------------------------------------------------

Hey all.

Files in drivers/firmware/google/ do not seem to
have a listed MAINTAINER.

Would a section entry in MAINTAINERS like this be
appropriate?

GOOGLE FIRMWARE
M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M:     Stephen Boyd <swboyd@chromium.org>
R:     Guenter Roeck <groeck@chromium.org>
R:     Julius Werner <jwerner@chromium.org>
S:     Maintained
F:     drivers/firmware/google/

Is there a git tree somewhere that should be added?
What would be the
status of this proposed section?
Does someone really look after it at
all?

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > All files in drivers/firmware/google/ are identified as part of THE REST
> > according to MAINTAINERS, but they are really maintained by others.
[]
> > diff --git a/MAINTAINERS b/MAINTAINERS
[]
> > @@ -7111,6 +7111,14 @@ S:       Supported
> >  F:     Documentation/networking/device_drivers/google/gve.rst
> >  F:     drivers/net/ethernet/google
> > 
> > +GOOGLE FIRMWARE
> > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > +M:     Stephen Boyd <swboyd@chromium.org>
> > +R:     Guenter Roeck <groeck@chromium.org>
> > +R:     Julius Werner <jwerner@chromium.org>
> > +S:     Maintained
> > +F:     drivers/firmware/google/
> > +
> 
> FWIW, I would not mind stepping up as maintainer if needed, but I
> think we should strongly discourage this kind of auto-assignment of
> maintainers and/or reviewers.

Auto assignment should definitely _not_ be done.

This is an RFC proposal though.

Sometimes it's better to not produce an RFC as
a patch, but maybe just show a proposed section
and ask if is appropriate may be a better style
going forward.

Maybe just emailing Greg, Stephen, Guenter and
Julius (cc'ing LKML) asking something like the
below would be better:

----------------------------------------------------

Hey all.

Files in drivers/firmware/google/ do not seem to
have a listed MAINTAINER.

Would a section entry in MAINTAINERS like this be
appropriate?

GOOGLE FIRMWARE
M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
M:     Stephen Boyd <swboyd@chromium.org>
R:     Guenter Roeck <groeck@chromium.org>
R:     Julius Werner <jwerner@chromium.org>
S:     Maintained
F:     drivers/firmware/google/

Is there a git tree somewhere that should be added?
What would be the
status of this proposed section?
Does someone really look after it at
all?

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Sun, 8 Mar 2020, Joe Perches wrote:

> On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > according to MAINTAINERS, but they are really maintained by others.
> []
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > > @@ -7111,6 +7111,14 @@ S:       Supported
> > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > >  F:     drivers/net/ethernet/google
> > > 
> > > +GOOGLE FIRMWARE
> > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > +R:     Guenter Roeck <groeck@chromium.org>
> > > +R:     Julius Werner <jwerner@chromium.org>
> > > +S:     Maintained
> > > +F:     drivers/firmware/google/
> > > +
> > 
> > FWIW, I would not mind stepping up as maintainer if needed, but I
> > think we should strongly discourage this kind of auto-assignment of
> > maintainers and/or reviewers.
> 
> Auto assignment should definitely _not_ be done.
> 
> This is an RFC proposal though.
> 
> Sometimes it's better to not produce an RFC as
> a patch, but maybe just show a proposed section
> and ask if is appropriate may be a better style
> going forward.
>

Please interpret the RFC patch similar to an email as Joe wrote below, 
simply reaching out to you.

There is no auto-assignment intended, nor did I expect the patch to be 
picked up on the first attempt of uneducated guessing.

There are currently around 3,000 files identified being part of THE REST;
so they are all assigned to Linus and LKML.

To confirm that they actually are maintained by someone else and reflect 
that in MAINTAINERS, a bit of educated guessing who to contact and to 
which entry to add the files to is required.

I am starting with the "bigger" clustered files in drivers, and then try 
to look at files in include and Documentation/ABI/.

Here is a rough statistics on how many files from each directory are in
THE REST:

   1368 include
    566 tools
    327 lib
    321 Documentation
    100 drivers
     91 kernel
     84 scripts
     75 samples
     13 ipc
     13 init
      8 usr
      2 arch
      1 virt

 
> Maybe just emailing Greg, Stephen, Guenter and
> Julius (cc'ing LKML) asking something like the
> below would be better:
> 
> ----------------------------------------------------
> 
> Hey all.
> 
> Files in drivers/firmware/google/ do not seem to
> have a listed MAINTAINER.
> 
> Would a section entry in MAINTAINERS like this be
> appropriate?
> 
> GOOGLE FIRMWARE
> M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> M:     Stephen Boyd <swboyd@chromium.org>
> R:     Guenter Roeck <groeck@chromium.org>
> R:     Julius Werner <jwerner@chromium.org>
> S:     Maintained
> F:     drivers/firmware/google/
> 
> Is there a git tree somewhere that should be added?
> What would be the
> status of this proposed section?
> Does someone really look after it at
> all?
> 

Thanks for the proposal; I was not sure about the best way to reach out to 
others on suggesting to add new entries.

In the future, I will simply send out emails, as those above, when 
suggesting to add new entries.

Thanks for the feedback and sorry for the churn. Once most files are 
assigned, it is much easier to follow when someone missed to adjust the 
MAINTAINERS file and send out a friendly hint. I hope that is worth the 
initial churn for some people at the beginning of this clean-up.

Lukas

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Sun, 8 Mar 2020, Joe Perches wrote:

> On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > according to MAINTAINERS, but they are really maintained by others.
> []
> > > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > > @@ -7111,6 +7111,14 @@ S:       Supported
> > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > >  F:     drivers/net/ethernet/google
> > > 
> > > +GOOGLE FIRMWARE
> > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > +R:     Guenter Roeck <groeck@chromium.org>
> > > +R:     Julius Werner <jwerner@chromium.org>
> > > +S:     Maintained
> > > +F:     drivers/firmware/google/
> > > +
> > 
> > FWIW, I would not mind stepping up as maintainer if needed, but I
> > think we should strongly discourage this kind of auto-assignment of
> > maintainers and/or reviewers.
> 
> Auto assignment should definitely _not_ be done.
> 
> This is an RFC proposal though.
> 
> Sometimes it's better to not produce an RFC as
> a patch, but maybe just show a proposed section
> and ask if is appropriate may be a better style
> going forward.
>

Please interpret the RFC patch similar to an email as Joe wrote below, 
simply reaching out to you.

There is no auto-assignment intended, nor did I expect the patch to be 
picked up on the first attempt of uneducated guessing.

There are currently around 3,000 files identified being part of THE REST;
so they are all assigned to Linus and LKML.

To confirm that they actually are maintained by someone else and reflect 
that in MAINTAINERS, a bit of educated guessing who to contact and to 
which entry to add the files to is required.

I am starting with the "bigger" clustered files in drivers, and then try 
to look at files in include and Documentation/ABI/.

Here is a rough statistics on how many files from each directory are in
THE REST:

   1368 include
    566 tools
    327 lib
    321 Documentation
    100 drivers
     91 kernel
     84 scripts
     75 samples
     13 ipc
     13 init
      8 usr
      2 arch
      1 virt

 
> Maybe just emailing Greg, Stephen, Guenter and
> Julius (cc'ing LKML) asking something like the
> below would be better:
> 
> ----------------------------------------------------
> 
> Hey all.
> 
> Files in drivers/firmware/google/ do not seem to
> have a listed MAINTAINER.
> 
> Would a section entry in MAINTAINERS like this be
> appropriate?
> 
> GOOGLE FIRMWARE
> M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> M:     Stephen Boyd <swboyd@chromium.org>
> R:     Guenter Roeck <groeck@chromium.org>
> R:     Julius Werner <jwerner@chromium.org>
> S:     Maintained
> F:     drivers/firmware/google/
> 
> Is there a git tree somewhere that should be added?
> What would be the
> status of this proposed section?
> Does someone really look after it at
> all?
> 

Thanks for the proposal; I was not sure about the best way to reach out to 
others on suggesting to add new entries.

In the future, I will simply send out emails, as those above, when 
suggesting to add new entries.

Thanks for the feedback and sorry for the churn. Once most files are 
assigned, it is much easier to follow when someone missed to adjust the 
MAINTAINERS file and send out a friendly hint. I hope that is worth the 
initial churn for some people at the beginning of this clean-up.

Lukas

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Greg Kroah-Hartman]

On Mon, Mar 09, 2020 at 07:32:10AM +0100, Lukas Bulwahn wrote:
> 
> 
> On Sun, 8 Mar 2020, Joe Perches wrote:
> 
> > On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > > according to MAINTAINERS, but they are really maintained by others.
> > []
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > []
> > > > @@ -7111,6 +7111,14 @@ S:       Supported
> > > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > > >  F:     drivers/net/ethernet/google
> > > > 
> > > > +GOOGLE FIRMWARE
> > > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > > +R:     Guenter Roeck <groeck@chromium.org>
> > > > +R:     Julius Werner <jwerner@chromium.org>
> > > > +S:     Maintained
> > > > +F:     drivers/firmware/google/
> > > > +
> > > 
> > > FWIW, I would not mind stepping up as maintainer if needed, but I
> > > think we should strongly discourage this kind of auto-assignment of
> > > maintainers and/or reviewers.
> > 
> > Auto assignment should definitely _not_ be done.
> > 
> > This is an RFC proposal though.
> > 
> > Sometimes it's better to not produce an RFC as
> > a patch, but maybe just show a proposed section
> > and ask if is appropriate may be a better style
> > going forward.
> >
> 
> Please interpret the RFC patch similar to an email as Joe wrote below, 
> simply reaching out to you.
> 
> There is no auto-assignment intended, nor did I expect the patch to be 
> picked up on the first attempt of uneducated guessing.
> 
> There are currently around 3,000 files identified being part of THE REST;
> so they are all assigned to Linus and LKML.
> 
> To confirm that they actually are maintained by someone else and reflect 
> that in MAINTAINERS, a bit of educated guessing who to contact and to 
> which entry to add the files to is required.
> 
> I am starting with the "bigger" clustered files in drivers, and then try 
> to look at files in include and Documentation/ABI/.
> 
> Here is a rough statistics on how many files from each directory are in
> THE REST:
> 
>    1368 include
>     566 tools
>     327 lib
>     321 Documentation
>     100 drivers
>      91 kernel
>      84 scripts
>      75 samples
>      13 ipc
>      13 init
>       8 usr
>       2 arch
>       1 virt

When you use the get_maintainer.pl script, it should find reasonable
people/lists for those files, so why not just stick with that?  Trying
to classify all of the kernel files to have MAINTAINERS entries seems
like a loosing proposition as there are file that no one has touched in
years.

thanks,

greg k-h

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Greg Kroah-Hartman]

On Mon, Mar 09, 2020 at 07:32:10AM +0100, Lukas Bulwahn wrote:
> 
> 
> On Sun, 8 Mar 2020, Joe Perches wrote:
> 
> > On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > > according to MAINTAINERS, but they are really maintained by others.
> > []
> > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > []
> > > > @@ -7111,6 +7111,14 @@ S:       Supported
> > > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > > >  F:     drivers/net/ethernet/google
> > > > 
> > > > +GOOGLE FIRMWARE
> > > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > > +R:     Guenter Roeck <groeck@chromium.org>
> > > > +R:     Julius Werner <jwerner@chromium.org>
> > > > +S:     Maintained
> > > > +F:     drivers/firmware/google/
> > > > +
> > > 
> > > FWIW, I would not mind stepping up as maintainer if needed, but I
> > > think we should strongly discourage this kind of auto-assignment of
> > > maintainers and/or reviewers.
> > 
> > Auto assignment should definitely _not_ be done.
> > 
> > This is an RFC proposal though.
> > 
> > Sometimes it's better to not produce an RFC as
> > a patch, but maybe just show a proposed section
> > and ask if is appropriate may be a better style
> > going forward.
> >
> 
> Please interpret the RFC patch similar to an email as Joe wrote below, 
> simply reaching out to you.
> 
> There is no auto-assignment intended, nor did I expect the patch to be 
> picked up on the first attempt of uneducated guessing.
> 
> There are currently around 3,000 files identified being part of THE REST;
> so they are all assigned to Linus and LKML.
> 
> To confirm that they actually are maintained by someone else and reflect 
> that in MAINTAINERS, a bit of educated guessing who to contact and to 
> which entry to add the files to is required.
> 
> I am starting with the "bigger" clustered files in drivers, and then try 
> to look at files in include and Documentation/ABI/.
> 
> Here is a rough statistics on how many files from each directory are in
> THE REST:
> 
>    1368 include
>     566 tools
>     327 lib
>     321 Documentation
>     100 drivers
>      91 kernel
>      84 scripts
>      75 samples
>      13 ipc
>      13 init
>       8 usr
>       2 arch
>       1 virt

When you use the get_maintainer.pl script, it should find reasonable
people/lists for those files, so why not just stick with that?  Trying
to classify all of the kernel files to have MAINTAINERS entries seems
like a loosing proposition as there are file that no one has touched in
years.

thanks,

greg k-h

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Mon, 9 Mar 2020, Greg Kroah-Hartman wrote:

> On Mon, Mar 09, 2020 at 07:32:10AM +0100, Lukas Bulwahn wrote:
> > 
> > 
> > On Sun, 8 Mar 2020, Joe Perches wrote:
> > 
> > > On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > > > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > > > according to MAINTAINERS, but they are really maintained by others.
> > > []
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > []
> > > > > @@ -7111,6 +7111,14 @@ S:       Supported
> > > > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > > > >  F:     drivers/net/ethernet/google
> > > > > 
> > > > > +GOOGLE FIRMWARE
> > > > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > > > +R:     Guenter Roeck <groeck@chromium.org>
> > > > > +R:     Julius Werner <jwerner@chromium.org>
> > > > > +S:     Maintained
> > > > > +F:     drivers/firmware/google/
> > > > > +
> > > > 
> > > > FWIW, I would not mind stepping up as maintainer if needed, but I
> > > > think we should strongly discourage this kind of auto-assignment of
> > > > maintainers and/or reviewers.
> > > 
> > > Auto assignment should definitely _not_ be done.
> > > 
> > > This is an RFC proposal though.
> > > 
> > > Sometimes it's better to not produce an RFC as
> > > a patch, but maybe just show a proposed section
> > > and ask if is appropriate may be a better style
> > > going forward.
> > >
> > 
> > Please interpret the RFC patch similar to an email as Joe wrote below, 
> > simply reaching out to you.
> > 
> > There is no auto-assignment intended, nor did I expect the patch to be 
> > picked up on the first attempt of uneducated guessing.
> > 
> > There are currently around 3,000 files identified being part of THE REST;
> > so they are all assigned to Linus and LKML.
> > 
> > To confirm that they actually are maintained by someone else and reflect 
> > that in MAINTAINERS, a bit of educated guessing who to contact and to 
> > which entry to add the files to is required.
> > 
> > I am starting with the "bigger" clustered files in drivers, and then try 
> > to look at files in include and Documentation/ABI/.
> > 
> > Here is a rough statistics on how many files from each directory are in
> > THE REST:
> > 
> >    1368 include
> >     566 tools
> >     327 lib
> >     321 Documentation
> >     100 drivers
> >      91 kernel
> >      84 scripts
> >      75 samples
> >      13 ipc
> >      13 init
> >       8 usr
> >       2 arch
> >       1 virt
> 
> When you use the get_maintainer.pl script, it should find reasonable
> people/lists for those files, so why not just stick with that?  Trying
> to classify all of the kernel files to have MAINTAINERS entries seems
> like a loosing proposition as there are file that no one has touched in
> years.

I would at least hope that there are some quick wins with some cases that 
are pretty obvious to be added to existing entries. A first scan suggested 
that it should not take too much detective work to figure it out for some 
of those files.

For files that have not been touched in years---which I hope are not the 
majority of the cases---it would be nice to see if I can find out that 
these files are part of a entry/subsystem that actually maintains them, 
but did not need to touch them in years, or if these files are orphaned 
(or even meaningless left-overs) but nobody noticed because it was never 
made explicit in the MAINTAINERS file.

After those quick wins, getting this done for ALL files could turn out to 
be impossible, and just checking for future changes and reacting to those 
is the better approach to ensure that new files have an entry in  
MAINTAINERS, but I guess I will find out how much is quickly and easily 
allocated to a MAINTAINERS entry and what cannot be determined as outsider 
and relying on get_maintainer.pl is more reliable than getting a 
confirmation for a dedicated entry in MAINTAINERS.

If the feedback is consistently discouraging to update existing entries 
with additions for currently non-assigned files, I will stop figuring out 
the changes and relying on get_maintainers.pl without making use of any 
data from the MAINTAINERS file for those cases remains the best option, 
just as it is today.

I am willing to investigate if this point can be improved in the 
MAINTAINERS file. If it is all good, as it is right now, or it simply 
cannot be improved without a lot of attention from many developers, 
everything can stay as-is and I will look into other topics.

Lukas

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Mon, 9 Mar 2020, Greg Kroah-Hartman wrote:

> On Mon, Mar 09, 2020 at 07:32:10AM +0100, Lukas Bulwahn wrote:
> > 
> > 
> > On Sun, 8 Mar 2020, Joe Perches wrote:
> > 
> > > On Sun, 2020-03-08 at 15:32 -0700, Guenter Roeck wrote:
> > > > On Sun, Mar 8, 2020 at 12:51 PM Lukas Bulwahn <lukas.bulwahn@gmail.com> wrote:
> > > > > All files in drivers/firmware/google/ are identified as part of THE REST
> > > > > according to MAINTAINERS, but they are really maintained by others.
> > > []
> > > > > diff --git a/MAINTAINERS b/MAINTAINERS
> > > []
> > > > > @@ -7111,6 +7111,14 @@ S:       Supported
> > > > >  F:     Documentation/networking/device_drivers/google/gve.rst
> > > > >  F:     drivers/net/ethernet/google
> > > > > 
> > > > > +GOOGLE FIRMWARE
> > > > > +M:     Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> > > > > +M:     Stephen Boyd <swboyd@chromium.org>
> > > > > +R:     Guenter Roeck <groeck@chromium.org>
> > > > > +R:     Julius Werner <jwerner@chromium.org>
> > > > > +S:     Maintained
> > > > > +F:     drivers/firmware/google/
> > > > > +
> > > > 
> > > > FWIW, I would not mind stepping up as maintainer if needed, but I
> > > > think we should strongly discourage this kind of auto-assignment of
> > > > maintainers and/or reviewers.
> > > 
> > > Auto assignment should definitely _not_ be done.
> > > 
> > > This is an RFC proposal though.
> > > 
> > > Sometimes it's better to not produce an RFC as
> > > a patch, but maybe just show a proposed section
> > > and ask if is appropriate may be a better style
> > > going forward.
> > >
> > 
> > Please interpret the RFC patch similar to an email as Joe wrote below, 
> > simply reaching out to you.
> > 
> > There is no auto-assignment intended, nor did I expect the patch to be 
> > picked up on the first attempt of uneducated guessing.
> > 
> > There are currently around 3,000 files identified being part of THE REST;
> > so they are all assigned to Linus and LKML.
> > 
> > To confirm that they actually are maintained by someone else and reflect 
> > that in MAINTAINERS, a bit of educated guessing who to contact and to 
> > which entry to add the files to is required.
> > 
> > I am starting with the "bigger" clustered files in drivers, and then try 
> > to look at files in include and Documentation/ABI/.
> > 
> > Here is a rough statistics on how many files from each directory are in
> > THE REST:
> > 
> >    1368 include
> >     566 tools
> >     327 lib
> >     321 Documentation
> >     100 drivers
> >      91 kernel
> >      84 scripts
> >      75 samples
> >      13 ipc
> >      13 init
> >       8 usr
> >       2 arch
> >       1 virt
> 
> When you use the get_maintainer.pl script, it should find reasonable
> people/lists for those files, so why not just stick with that?  Trying
> to classify all of the kernel files to have MAINTAINERS entries seems
> like a loosing proposition as there are file that no one has touched in
> years.

I would at least hope that there are some quick wins with some cases that 
are pretty obvious to be added to existing entries. A first scan suggested 
that it should not take too much detective work to figure it out for some 
of those files.

For files that have not been touched in years---which I hope are not the 
majority of the cases---it would be nice to see if I can find out that 
these files are part of a entry/subsystem that actually maintains them, 
but did not need to touch them in years, or if these files are orphaned 
(or even meaningless left-overs) but nobody noticed because it was never 
made explicit in the MAINTAINERS file.

After those quick wins, getting this done for ALL files could turn out to 
be impossible, and just checking for future changes and reacting to those 
is the better approach to ensure that new files have an entry in  
MAINTAINERS, but I guess I will find out how much is quickly and easily 
allocated to a MAINTAINERS entry and what cannot be determined as outsider 
and relying on get_maintainer.pl is more reliable than getting a 
confirmation for a dedicated entry in MAINTAINERS.

If the feedback is consistently discouraging to update existing entries 
with additions for currently non-assigned files, I will stop figuring out 
the changes and relying on get_maintainers.pl without making use of any 
data from the MAINTAINERS file for those cases remains the best option, 
just as it is today.

I am willing to investigate if this point can be improved in the 
MAINTAINERS file. If it is all good, as it is right now, or it simply 
cannot be improved without a lot of attention from many developers, 
everything can stay as-is and I will look into other topics.

Lukas

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Mon, 2020-03-09 at 22:03 +0100, Lukas Bulwahn wrote:
> I am starting with the "bigger" clustered files in drivers, and then try 
> > > to look at files in include and Documentation/ABI/.

If you want to spend the time tracking stuff down,
it may be best to to
start with include/

> > > Here is a rough statistics on how many files from each directory are in
> > > THE REST:
> > > 
> > >    1368 include

There are very likely some files there that should
actually be listed as part of a subsystem.

> > >     327 lib

Not many that aren't trivial or ancient.

> > >     321 Documentation

Probably a few

> > >     100 drivers

What's not already maintained is probably ancient.

Everything else may not matter much.

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Joe Perches]

On Mon, 2020-03-09 at 22:03 +0100, Lukas Bulwahn wrote:
> I am starting with the "bigger" clustered files in drivers, and then try 
> > > to look at files in include and Documentation/ABI/.

If you want to spend the time tracking stuff down,
it may be best to to
start with include/

> > > Here is a rough statistics on how many files from each directory are in
> > > THE REST:
> > > 
> > >    1368 include

There are very likely some files there that should
actually be listed as part of a subsystem.

> > >     327 lib

Not many that aren't trivial or ancient.

> > >     321 Documentation

Probably a few

> > >     100 drivers

What's not already maintained is probably ancient.

Everything else may not matter much.

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Mon, 9 Mar 2020, Joe Perches wrote:

> On Mon, 2020-03-09 at 22:03 +0100, Lukas Bulwahn wrote:
> > I am starting with the "bigger" clustered files in drivers, and then try 
> > > > to look at files in include and Documentation/ABI/.
> 
> If you want to spend the time tracking stuff down,
> it may be best to to
> start with include/
>

Thanks for the guidance. I will do that, and we will see if others 
appreciate that or not.


Lukas

Re: [PATCH RFC] MAINTAINERS: include GOOGLE FIRMWARE entry

[Lukas Bulwahn]

On Mon, 9 Mar 2020, Joe Perches wrote:

> On Mon, 2020-03-09 at 22:03 +0100, Lukas Bulwahn wrote:
> > I am starting with the "bigger" clustered files in drivers, and then try 
> > > > to look at files in include and Documentation/ABI/.
> 
> If you want to spend the time tracking stuff down,
> it may be best to to
> start with include/
>

Thanks for the guidance. I will do that, and we will see if others 
appreciate that or not.


Lukas