Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1256866 > unrolled thread
| Started by | Lee Jones <lee.jones@linaro.org> |
|---|---|
| First post | 2015-10-27 16:50 +0100 |
| Last post | 2015-10-28 10:00 +0100 |
| Articles | 20 on this page of 49 — 8 participants |
Back to article view | Back to linux.kernel
[PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-27 16:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Sebastian Reichel <sre@kernel.org> - 2015-10-27 18:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-27 19:20 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Joe Perches <joe@perches.com> - 2015-10-27 19:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-28 02:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 09:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 10:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 10:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-28 10:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 11:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 12:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Joe Perches <joe@perches.com> - 2015-10-28 12:10 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 12:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 12:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 13:20 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Joe Perches <joe@perches.com> - 2015-10-28 13:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 13:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Joe Perches <joe@perches.com> - 2015-10-28 13:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 14:10 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 14:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 15:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 16:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-29 01:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-29 01:20 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-30 18:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-30 18:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Javier Martinez Canillas <javier@dowhile0.org> - 2015-10-28 15:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-28 10:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Uwe Kleine-König <u.kleine-koenig@pengutronix.de> - 2015-10-28 10:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 11:00 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-28 14:20 +0100
[PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-28 17:50 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Lee Jones <lee.jones@linaro.org> - 2015-10-28 18:10 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-28 18:10 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Lee Jones <lee.jones@linaro.org> - 2015-10-28 18:30 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-28 18:40 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Lee Jones <lee.jones@linaro.org> - 2015-10-28 18:50 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-28 19:00 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Lee Jones <lee.jones@linaro.org> - 2015-10-29 10:30 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-29 15:20 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Lee Jones <lee.jones@linaro.org> - 2015-10-29 17:20 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Joe Perches <joe@perches.com> - 2015-10-28 18:20 +0100
Re: [PATCH] get_maintainer: Add subsystem to reviewer output Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-29 00:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 11:20 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Krzysztof Kozlowski <k.kozlowski@samsung.com> - 2015-10-28 14:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 14:50 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com> - 2015-10-28 17:30 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Lee Jones <lee.jones@linaro.org> - 2015-10-28 17:40 +0100
Re: [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag Chanwoo Choi <cw00.choi@samsung.com> - 2015-10-28 10:00 +0100
Page 1 of 3 [1] 2 3 Next page →
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-27 16:50 +0100 |
| Subject | [PATCH] MAINTAINERS: Start using the 'reviewer' (R) tag |
| Message-ID | <qoeFB-6WP-29@gated-at.bofh.it> |
Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
have been able to tag specific people as Reviewers. These are key
individuals who are tasked with or volunteer to review code submitted
to a subsystem or specific file. However, according to MAINTAINERS
we have 1046 Maintainers and only a mere 22 Reviewers. I believe
these numbers to be incorrect, as many of these Maintainers are in
fact Reviewers.
I have taken the time to identify some of the Reviewers who pertain
to subsystems which I look after, and have changed their status from
Maintainer (collector of patches) to Reviewer (reviewer of code).
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
MAINTAINERS | 22 +++++++++++-----------
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 9de185d..07bc92f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -392,7 +392,7 @@ F: drivers/media/i2c/adp1653.c
F: include/media/adp1653.h
ADP5520 BACKLIGHT DRIVER WITH IO EXPANDER (ADP5520/ADP5501)
-M: Michael Hennerich <michael.hennerich@analog.com>
+R: Michael Hennerich <michael.hennerich@analog.com>
W: http://wiki.analog.com/ADP5520
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
@@ -411,7 +411,7 @@ F: drivers/input/keyboard/adp5588-keys.c
F: drivers/gpio/gpio-adp5588.c
ADP8860 BACKLIGHT DRIVER (ADP8860/ADP8861/ADP8863)
-M: Michael Hennerich <michael.hennerich@analog.com>
+R: Michael Hennerich <michael.hennerich@analog.com>
W: http://wiki.analog.com/ADP8860
W: http://ez.analog.com/community/linux-device-drivers
S: Supported
@@ -2049,8 +2049,8 @@ S: Maintained
F: drivers/net/wireless/b43legacy/
BACKLIGHT CLASS/SUBSYSTEM
-M: Jingoo Han <jingoohan1@gmail.com>
M: Lee Jones <lee.jones@linaro.org>
+R: Jingoo Han <jingoohan1@gmail.com>
S: Maintained
F: drivers/video/backlight/
F: include/linux/backlight.h
@@ -3364,7 +3364,7 @@ F: include/linux/dm-*.h
F: include/uapi/linux/dm-*.h
DIALOG SEMICONDUCTOR DRIVERS
-M: Support Opensource <support.opensource@diasemi.com>
+R: Support Opensource <support.opensource@diasemi.com>
W: http://www.dialog-semiconductor.com/products
S: Supported
F: Documentation/hwmon/da90??
@@ -5212,7 +5212,7 @@ S: Orphan
F: drivers/scsi/ips.*
ICH LPC AND GPIO DRIVER
-M: Peter Tyser <ptyser@xes-inc.com>
+R: Peter Tyser <ptyser@xes-inc.com>
S: Maintained
F: drivers/mfd/lpc_ich.c
F: drivers/gpio/gpio-ich.c
@@ -6855,7 +6855,7 @@ F: include/linux/mcb.h
F: Documentation/men-chameleon-bus.txt
MEN F21BMC (Board Management Controller)
-M: Andreas Werner <andreas.werner@men.de>
+R: Andreas Werner <andreas.werner@men.de>
S: Supported
F: drivers/mfd/menf21bmc.c
F: drivers/watchdog/menf21bmc_wdt.c
@@ -9009,8 +9009,8 @@ S: Maintained
F: drivers/video/fbdev/s3c-fb.c
SAMSUNG MULTIFUNCTION PMIC DEVICE DRIVERS
-M: Sangbeom Kim <sbkim73@samsung.com>
-M: Krzysztof Kozlowski <k.kozlowski@samsung.com>
+R: Sangbeom Kim <sbkim73@samsung.com>
+R: Krzysztof Kozlowski <k.kozlowski@samsung.com>
L: linux-kernel@vger.kernel.org
L: linux-samsung-soc@vger.kernel.org
S: Supported
@@ -10434,20 +10434,20 @@ F: sound/soc/codecs/lm49453*
F: sound/soc/codecs/isabelle*
TI LP855x BACKLIGHT DRIVER
-M: Milo Kim <milo.kim@ti.com>
+R: Milo Kim <milo.kim@ti.com>
S: Maintained
F: Documentation/backlight/lp855x-driver.txt
F: drivers/video/backlight/lp855x_bl.c
F: include/linux/platform_data/lp855x.h
TI LP8727 CHARGER DRIVER
-M: Milo Kim <milo.kim@ti.com>
+R: Milo Kim <milo.kim@ti.com>
S: Maintained
F: drivers/power/lp8727_charger.c
F: include/linux/platform_data/lp8727.h
TI LP8788 MFD DRIVER
-M: Milo Kim <milo.kim@ti.com>
+R: Milo Kim <milo.kim@ti.com>
S: Maintained
F: drivers/iio/adc/lp8788_adc.c
F: drivers/leds/leds-lp8788.c
--
1.9.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [next] | [standalone]
| From | Sebastian Reichel <sre@kernel.org> |
|---|---|
| Date | 2015-10-27 18:30 +0100 |
| Message-ID | <qogem-80v-1@gated-at.bofh.it> |
| In reply to | #1256866 |
[Multipart message — attachments visible in raw view] — view raw
Hi,
On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
> Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
> have been able to tag specific people as Reviewers. These are key
> individuals who are tasked with or volunteer to review code submitted
> to a subsystem or specific file. However, according to MAINTAINERS
> we have 1046 Maintainers and only a mere 22 Reviewers. I believe
> these numbers to be incorrect, as many of these Maintainers are in
> fact Reviewers.
>
> I have taken the time to identify some of the Reviewers who pertain
> to subsystems which I look after, and have changed their status from
> Maintainer (collector of patches) to Reviewer (reviewer of code).
[for drivers/power/*]
Acked-By: Sebastian Reichel <sre@kernel.org>
I think you should CC the people, which are changed from "M:" to
"R:", though.
-- Sebastian
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-27 19:20 +0100 |
| Message-ID | <qoh0J-5E-1@gated-at.bofh.it> |
| In reply to | #1256986 |
On Tue, 27 Oct 2015, Sebastian Reichel wrote:
> On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
> > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
> > have been able to tag specific people as Reviewers. These are key
> > individuals who are tasked with or volunteer to review code submitted
> > to a subsystem or specific file. However, according to MAINTAINERS
> > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
> > these numbers to be incorrect, as many of these Maintainers are in
> > fact Reviewers.
> >
> > I have taken the time to identify some of the Reviewers who pertain
> > to subsystems which I look after, and have changed their status from
> > Maintainer (collector of patches) to Reviewer (reviewer of code).
>
> [for drivers/power/*]
> Acked-By: Sebastian Reichel <sre@kernel.org>
Thanks.
> I think you should CC the people, which are changed from "M:" to
> "R:", though.
Yes, makes sense.
I'd like to collect some Maintainer Acks first though.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2015-10-27 19:50 +0100 |
| Message-ID | <qohtM-fK-19@gated-at.bofh.it> |
| In reply to | #1257105 |
On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
> On Tue, 27 Oct 2015, Sebastian Reichel wrote:
> > On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
> > > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
> > > have been able to tag specific people as Reviewers. These are key
> > > individuals who are tasked with or volunteer to review code submitted
> > > to a subsystem or specific file. However, according to MAINTAINERS
> > > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
> > > these numbers to be incorrect, as many of these Maintainers are in
> > > fact Reviewers.
Most entries in MAINTAINERS seem to be vanity entries than actual
active participants. A person typically writes a driver, adds a
MAINTAINER entry, then forgets about it and/or the hardware becomes
outdated.
> > > I have taken the time to identify some of the Reviewers who pertain
> > > to subsystems which I look after, and have changed their status from
> > > Maintainer (collector of patches) to Reviewer (reviewer of code).
> >
> > [for drivers/power/*]
> > Acked-By: Sebastian Reichel <sre@kernel.org>
>
> Thanks.
>
> > I think you should CC the people, which are changed from "M:" to
> > "R:", though.
>
> Yes, makes sense.
>
> I'd like to collect some Maintainer Acks first though.
I think people from organizations like Samsung are actual
maintainers not reviewers.
Their drivers are not thrown over a wall and forgotten.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2015-10-28 02:50 +0100 |
| Message-ID | <qoo2d-4uc-1@gated-at.bofh.it> |
| In reply to | #1257126 |
2015-10-28 3:44 GMT+09:00 Joe Perches <joe@perches.com>: > > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote: > > On Tue, 27 Oct 2015, Sebastian Reichel wrote:> > > > > I think you should CC the people, which are changed from "M:" to > > > "R:", though. > > > > Yes, makes sense. > > > > I'd like to collect some Maintainer Acks first though. > > I think people from organizations like Samsung are actual > maintainers not reviewers. > > Their drivers are not thrown over a wall and forgotten. At least for Samsung Multifunction PMIC drivers (and some of Maxim MUICs and PMICs) these are actively used by us in existing and new products. They are also continuously extended and actually maintained. This means that it is not only about review of new patches but also about caring that nothing will become broken. I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE DRIVERS" entry as is - maintainers. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 09:40 +0100 |
| Message-ID | <qour0-dw-19@gated-at.bofh.it> |
| In reply to | #1257561 |
On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
> On Tue, 27 Oct 2015, Sebastian Reichel wrote:
> > On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
> > > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
> > > have been able to tag specific people as Reviewers. These are key
> > > individuals who are tasked with or volunteer to review code submitted
> > > to a subsystem or specific file. However, according to MAINTAINERS
> > > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
> > > these numbers to be incorrect, as many of these Maintainers are in
> > > fact Reviewers.
Most entries in MAINTAINERS seem to be vanity entries than actual
active participants. A person typically writes a driver, adds a
MAINTAINER entry, then forgets about it and/or the hardware becomes
outdated.
This I agree with.
On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> 2015-10-28 3:44 GMT+09:00 Joe Perches <joe@perches.com>:
> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
> > > On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
> > > > I think you should CC the people, which are changed from "M:" to
> > > > "R:", though.
> > >
> > > Yes, makes sense.
> > >
> > > I'd like to collect some Maintainer Acks first though.
> >
> > I think people from organizations like Samsung are actual
> > maintainers not reviewers.
So this all hinges on how we are describing Maintainers and Reviewers.
My personal definition (until convinced otherwise) is that Reviewers
care about their particular subsystem and/or files. They conduct code
reviews to ensure nothing gets broken and the code base stays in best
possible state of worthiness. On the other hand Maintainers usually
conduct themselves as Reviewers but also have 'maintainership' duties
as well; such as applying patches, *maintaining*, testing, rebasing,
etc, an upstream branch and ultimately sending pull-requests to higher
level Maintainers i.e. Linus. Maintainers also have the ultimate say
(unless over-ruled by Linus etc) over what gets applied.
> > Their drivers are not thrown over a wall and forgotten.
>
> At least for Samsung Multifunction PMIC drivers (and some of Maxim
> MUICs and PMICs) these are actively used by us in existing and new
> products. They are also continuously extended and actually maintained.
> This means that it is not only about review of new patches but also
> about caring that nothing will become broken.
Exactly. This what I expect of any good code Reviewer.
> I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE
> DRIVERS" entry as is - maintainers.
But you aren't maintaining the driver i.e. you don't collect patches
and *maintain* them on an upstream branch. Granted some of you guys
are doing a great job of maintaining branches on your downstream or
BSP kernels, but conduct a Reviewer type role for upstream.
You guys are pushing back like this is some kind of demotion. That's
not the case at all. All it does is better describe the (very worthy)
function you *actually* provide.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Javier Martinez Canillas <javier@dowhile0.org> |
|---|---|
| Date | 2015-10-28 10:30 +0100 |
| Message-ID | <qovdn-Lu-1@gated-at.bofh.it> |
| In reply to | #1257797 |
Hello Lee,
On Wed, Oct 28, 2015 at 9:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
>> On Tue, 27 Oct 2015, Sebastian Reichel wrote:
>> > On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
>> > > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
>> > > have been able to tag specific people as Reviewers. These are key
>> > > individuals who are tasked with or volunteer to review code submitted
>> > > to a subsystem or specific file. However, according to MAINTAINERS
>> > > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
>> > > these numbers to be incorrect, as many of these Maintainers are in
>> > > fact Reviewers.
>
> Most entries in MAINTAINERS seem to be vanity entries than actual
> active participants. A person typically writes a driver, adds a
> MAINTAINER entry, then forgets about it and/or the hardware becomes
> outdated.
>
> This I agree with.
>
> On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
>> 2015-10-28 3:44 GMT+09:00 Joe Perches <joe@perches.com>:
>> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
>> > > On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
>> > > > I think you should CC the people, which are changed from "M:" to
>> > > > "R:", though.
>> > >
>> > > Yes, makes sense.
>> > >
>> > > I'd like to collect some Maintainer Acks first though.
>> >
>> > I think people from organizations like Samsung are actual
>> > maintainers not reviewers.
>
> So this all hinges on how we are describing Maintainers and Reviewers.
>
> My personal definition (until convinced otherwise) is that Reviewers
> care about their particular subsystem and/or files. They conduct code
> reviews to ensure nothing gets broken and the code base stays in best
> possible state of worthiness. On the other hand Maintainers usually
> conduct themselves as Reviewers but also have 'maintainership' duties
> as well; such as applying patches, *maintaining*, testing, rebasing,
> etc, an upstream branch and ultimately sending pull-requests to higher
> level Maintainers i.e. Linus. Maintainers also have the ultimate say
> (unless over-ruled by Linus etc) over what gets applied.
>
>> > Their drivers are not thrown over a wall and forgotten.
>>
I've a different definition. For me it depends on much do you care
about the component. For example I maintain a couple of drivers in the
kernel and Device Tree files for some boards that are important to me
but I also care about some other subsystems (i.e: Exynos SoC support)
and I act as a reviewer (although I'm not officially listed as
reviewer in the MAINTAINERS file).
We do have in fact different tags for each type of involvement so I
usually answer with a Reviewed-by tag if I review code for a subsystem
I care but I don't maintainer or answer with an Acked-by tag if I
review *and agree* with a patch for a component I maintain (so the
maintainer knows that is good to apply differently from the list if
needed).
Now, that doesn't mean that I provide a pull request for the drivers
or boards I maintain on every release since that will depend on the
number of patches posted for that component per release. So if there
are only a couple of patches, I think is easier for the subsystem
maintainer to pick those directly from the list but if there are a lot
of them, then the maintainer may ask me to prepare a branch to pull
and I've done in the past for drivers I maintain to be sure that the
patches in the list are applied in the right order, no needed patches
were missed, etc.
Another difference is that when I'm listed as a maintainer, I feel an
obligation to answer to the patches touching that component but that's
not the case for components I usually act as a reviewer, I may review
it if I have time but if I don't, I let other people to review it.
>> At least for Samsung Multifunction PMIC drivers (and some of Maxim
>> MUICs and PMICs) these are actively used by us in existing and new
>> products. They are also continuously extended and actually maintained.
>> This means that it is not only about review of new patches but also
>> about caring that nothing will become broken.
>
> Exactly. This what I expect of any good code Reviewer.
>
>> I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE
>> DRIVERS" entry as is - maintainers.
>
I agree with Krzysztof here, I would prefer to keep them as
maintainers if they are maintaining the drivers.
> But you aren't maintaining the driver i.e. you don't collect patches
> and *maintain* them on an upstream branch. Granted some of you guys
> are doing a great job of maintaining branches on your downstream or
> BSP kernels, but conduct a Reviewer type role for upstream.
>
> You guys are pushing back like this is some kind of demotion. That's
> not the case at all. All it does is better describe the (very worthy)
> function you *actually* provide.
>
But I think it makes description less accurate in fact, since without
$SUBJECT get_maintainers.pl reports for example:
Krzysztof Kozlowski <k.kozlowski@samsung.com> (supporter:MAXIM PMIC
AND MUIC DRIVERS FOR EXYNOS BASED BO...)
Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
and after the change:
Krzysztof Kozlowski <k.kozlowski@samsung.com> (reviewer)
Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
He also works for Samsung so the driver is not only maintained but
supported since he can actually take care of it as a part of his day
job (if I understood correctly).
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
>
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Javier Martinez Canillas <javier@dowhile0.org> |
|---|---|
| Date | 2015-10-28 10:30 +0100 |
| Message-ID | <qovdo-Lu-25@gated-at.bofh.it> |
| In reply to | #1257843 |
On Wed, Oct 28, 2015 at 10:21 AM, Javier Martinez Canillas <javier@dowhile0.org> wrote: > > We do have in fact different tags for each type of involvement so I > usually answer with a Reviewed-by tag if I review code for a subsystem > I care but I don't maintainer or answer with an Acked-by tag if I > review *and agree* with a patch for a component I maintain (so the > maintainer knows that is good to apply differently from the list if I wanted to write directly instead of differently. Sorry about the typo, I'm still with jetlag after a long trip. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Krzysztof Kozlowski <k.kozlowski@samsung.com> |
|---|---|
| Date | 2015-10-28 10:40 +0100 |
| Message-ID | <qovn4-OU-21@gated-at.bofh.it> |
| In reply to | #1257843 |
On 28.10.2015 18:21, Javier Martinez Canillas wrote: > Hello Lee, > (...) Let me only add something to certain part of your email... >> But you aren't maintaining the driver i.e. you don't collect patches >> and *maintain* them on an upstream branch. Granted some of you guys >> are doing a great job of maintaining branches on your downstream or >> BSP kernels, but conduct a Reviewer type role for upstream. >> >> You guys are pushing back like this is some kind of demotion. That's >> not the case at all. All it does is better describe the (very worthy) >> function you *actually* provide. >> > > But I think it makes description less accurate in fact, since without > $SUBJECT get_maintainers.pl reports for example: > > Krzysztof Kozlowski <k.kozlowski@samsung.com> (supporter:MAXIM PMIC > AND MUIC DRIVERS FOR EXYNOS BASED BO...) > Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD)) > > and after the change: > > Krzysztof Kozlowski <k.kozlowski@samsung.com> (reviewer) > Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD)) > > He also works for Samsung so the driver is not only maintained but > supported since he can actually take care of it as a part of his day > job (if I understood correctly). Oh, that's interesting semantic change. Yes, in that particular case, I added the "supported" tag on purpose - it's part of my job. It is connected with what I said in other reply - we have deep interest in these drivers. Not only "I will review the code if I have the time". No. I will devote my time to ensure that the code is working on our products. Best regards, Krzysztof -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 11:30 +0100 |
| Message-ID | <qow9s-1ly-9@gated-at.bofh.it> |
| In reply to | #1257843 |
On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
> On Wed, Oct 28, 2015 at 9:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
> >> On Tue, 27 Oct 2015, Sebastian Reichel wrote:
> >> > On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
> >> > > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
> >> > > have been able to tag specific people as Reviewers. These are key
> >> > > individuals who are tasked with or volunteer to review code submitted
> >> > > to a subsystem or specific file. However, according to MAINTAINERS
> >> > > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
> >> > > these numbers to be incorrect, as many of these Maintainers are in
> >> > > fact Reviewers.
> >
> > Most entries in MAINTAINERS seem to be vanity entries than actual
> > active participants. A person typically writes a driver, adds a
> > MAINTAINER entry, then forgets about it and/or the hardware becomes
> > outdated.
> >
> > This I agree with.
> >
> > On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
> >> 2015-10-28 3:44 GMT+09:00 Joe Perches <joe@perches.com>:
> >> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
> >> > > On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
> >> > > > I think you should CC the people, which are changed from "M:" to
> >> > > > "R:", though.
> >> > >
> >> > > Yes, makes sense.
> >> > >
> >> > > I'd like to collect some Maintainer Acks first though.
> >> >
> >> > I think people from organizations like Samsung are actual
> >> > maintainers not reviewers.
> >
> > So this all hinges on how we are describing Maintainers and Reviewers.
> >
> > My personal definition (until convinced otherwise) is that Reviewers
> > care about their particular subsystem and/or files. They conduct code
> > reviews to ensure nothing gets broken and the code base stays in best
> > possible state of worthiness. On the other hand Maintainers usually
> > conduct themselves as Reviewers but also have 'maintainership' duties
> > as well; such as applying patches, *maintaining*, testing, rebasing,
> > etc, an upstream branch and ultimately sending pull-requests to higher
> > level Maintainers i.e. Linus. Maintainers also have the ultimate say
> > (unless over-ruled by Linus etc) over what gets applied.
> >
> >> > Their drivers are not thrown over a wall and forgotten.
> >>
>
> I've a different definition. For me it depends on much do you care
> about the component. For example I maintain a couple of drivers in the
> kernel and Device Tree files for some boards that are important to me
> but I also care about some other subsystems (i.e: Exynos SoC support)
> and I act as a reviewer (although I'm not officially listed as
> reviewer in the MAINTAINERS file).
I wish to make this clear from the out-set. If you have no obligation
to review patches but do so occasionally anyway, that does not make
you the type of Reviewer that we're speaking about here. Anyone can
review any patch on the list that they wish to, which is lovely, but
it won't carry the same authority (for want of a better expression) as
if you were tagged as an official Reviewer in MAINTAINERS.
> We do have in fact different tags for each type of involvement so I
> usually answer with a Reviewed-by tag if I review code for a subsystem
> I care but I don't maintainer or answer with an Acked-by tag if I
> review *and agree* with a patch for a component I maintain (so the
> maintainer knows that is good to apply differently from the list if
> needed).
I think you need to re-read what those tags mean.
Documentation/SubmittingPatches
> Now, that doesn't mean that I provide a pull request for the drivers
> or boards I maintain on every release since that will depend on the
> number of patches posted for that component per release. So if there
> are only a couple of patches, I think is easier for the subsystem
> maintainer to pick those directly from the list but if there are a lot
> of them, then the maintainer may ask me to prepare a branch to pull
> and I've done in the past for drivers I maintain to be sure that the
> patches in the list are applied in the right order, no needed patches
> were missed, etc.
I have also submitted patches via a pull-request as a Submitter to
different subsystems. That does not mean I should automatically be
classed as a Maintainer.
> Another difference is that when I'm listed as a maintainer, I feel an
> obligation to answer to the patches touching that component but that's
> not the case for components I usually act as a reviewer, I may review
> it if I have time but if I don't, I let other people to review it.
Then, in the latter case you shouldn't be listed as a Reviewer in my
example. Anyone listed as a Reviewer in MAINTAINERS *does* have that
obligation. That's what it means. If Reviewers don't review, they
should be removed from MAINTAINERS.
> >> At least for Samsung Multifunction PMIC drivers (and some of Maxim
> >> MUICs and PMICs) these are actively used by us in existing and new
> >> products. They are also continuously extended and actually maintained.
> >> This means that it is not only about review of new patches but also
> >> about caring that nothing will become broken.
> >
> > Exactly. This what I expect of any good code Reviewer.
> >
> >> I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE
> >> DRIVERS" entry as is - maintainers.
>
> I agree with Krzysztof here, I would prefer to keep them as
> maintainers if they are maintaining the drivers.
But they're not. They're reviewing and caring like a good Reviewer
should.
> > But you aren't maintaining the driver i.e. you don't collect patches
> > and *maintain* them on an upstream branch. Granted some of you guys
> > are doing a great job of maintaining branches on your downstream or
> > BSP kernels, but conduct a Reviewer type role for upstream.
> >
> > You guys are pushing back like this is some kind of demotion. That's
> > not the case at all. All it does is better describe the (very worthy)
> > function you *actually* provide.
> >
>
> But I think it makes description less accurate in fact, since without
> $SUBJECT get_maintainers.pl reports for example:
>
> Krzysztof Kozlowski <k.kozlowski@samsung.com> (supporter:MAXIM PMIC
> AND MUIC DRIVERS FOR EXYNOS BASED BO...)
> Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
>
> and after the change:
>
> Krzysztof Kozlowski <k.kozlowski@samsung.com> (reviewer)
> Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
>
> He also works for Samsung so the driver is not only maintained but
> supported since he can actually take care of it as a part of his day
> job (if I understood correctly).
It's not the person that's supported, it's the driver. The driver
doesn't need to change state.
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Javier Martinez Canillas <javier@dowhile0.org> |
|---|---|
| Date | 2015-10-28 12:00 +0100 |
| Message-ID | <qowCu-1y1-17@gated-at.bofh.it> |
| In reply to | #1257885 |
Hello Lee,
On Wed, Oct 28, 2015 at 11:28 AM, Lee Jones <lee.jones@linaro.org> wrote:
> On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
>> On Wed, Oct 28, 2015 at 9:24 AM, Lee Jones <lee.jones@linaro.org> wrote:
>> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
>> >> On Tue, 27 Oct 2015, Sebastian Reichel wrote:
>> >> > On Tue, Oct 27, 2015 at 03:42:37PM +0000, Lee Jones wrote:
>> >> > > Since eafbaac ("MAINTAINERS: Add "R:" designated-reviewers tag") we
>> >> > > have been able to tag specific people as Reviewers. These are key
>> >> > > individuals who are tasked with or volunteer to review code submitted
>> >> > > to a subsystem or specific file. However, according to MAINTAINERS
>> >> > > we have 1046 Maintainers and only a mere 22 Reviewers. I believe
>> >> > > these numbers to be incorrect, as many of these Maintainers are in
>> >> > > fact Reviewers.
>> >
>> > Most entries in MAINTAINERS seem to be vanity entries than actual
>> > active participants. A person typically writes a driver, adds a
>> > MAINTAINER entry, then forgets about it and/or the hardware becomes
>> > outdated.
>> >
>> > This I agree with.
>> >
>> > On Wed, 28 Oct 2015, Krzysztof Kozlowski wrote:
>> >> 2015-10-28 3:44 GMT+09:00 Joe Perches <joe@perches.com>:
>> >> > On Tue, 2015-10-27 at 18:15 +0000, Lee Jones wrote:
>> >> > > On Tue, 27 Oct 2015, Sebastian Reichel wrote:> >
>> >> > > > I think you should CC the people, which are changed from "M:" to
>> >> > > > "R:", though.
>> >> > >
>> >> > > Yes, makes sense.
>> >> > >
>> >> > > I'd like to collect some Maintainer Acks first though.
>> >> >
>> >> > I think people from organizations like Samsung are actual
>> >> > maintainers not reviewers.
>> >
>> > So this all hinges on how we are describing Maintainers and Reviewers.
>> >
>> > My personal definition (until convinced otherwise) is that Reviewers
>> > care about their particular subsystem and/or files. They conduct code
>> > reviews to ensure nothing gets broken and the code base stays in best
>> > possible state of worthiness. On the other hand Maintainers usually
>> > conduct themselves as Reviewers but also have 'maintainership' duties
>> > as well; such as applying patches, *maintaining*, testing, rebasing,
>> > etc, an upstream branch and ultimately sending pull-requests to higher
>> > level Maintainers i.e. Linus. Maintainers also have the ultimate say
>> > (unless over-ruled by Linus etc) over what gets applied.
>> >
>> >> > Their drivers are not thrown over a wall and forgotten.
>> >>
>>
>> I've a different definition. For me it depends on much do you care
>> about the component. For example I maintain a couple of drivers in the
>> kernel and Device Tree files for some boards that are important to me
>> but I also care about some other subsystems (i.e: Exynos SoC support)
>> and I act as a reviewer (although I'm not officially listed as
>> reviewer in the MAINTAINERS file).
>
> I wish to make this clear from the out-set. If you have no obligation
> to review patches but do so occasionally anyway, that does not make
> you the type of Reviewer that we're speaking about here. Anyone can
> review any patch on the list that they wish to, which is lovely, but
> it won't carry the same authority (for want of a better expression) as
> if you were tagged as an official Reviewer in MAINTAINERS.
>
We agree on that.
>> We do have in fact different tags for each type of involvement so I
>> usually answer with a Reviewed-by tag if I review code for a subsystem
>> I care but I don't maintainer or answer with an Acked-by tag if I
>> review *and agree* with a patch for a component I maintain (so the
>> maintainer knows that is good to apply differently from the list if
>> needed).
>
> I think you need to re-read what those tags mean.
>
> Documentation/SubmittingPatches
>
I know that document of course but I went and read the tags
description again and I don't see how that document supports your
arguments. Can you please share the paragraphs you are referring to?
>> Now, that doesn't mean that I provide a pull request for the drivers
>> or boards I maintain on every release since that will depend on the
>> number of patches posted for that component per release. So if there
>> are only a couple of patches, I think is easier for the subsystem
>> maintainer to pick those directly from the list but if there are a lot
>> of them, then the maintainer may ask me to prepare a branch to pull
>> and I've done in the past for drivers I maintain to be sure that the
>> patches in the list are applied in the right order, no needed patches
>> were missed, etc.
>
> I have also submitted patches via a pull-request as a Submitter to
> different subsystems. That does not mean I should automatically be
> classed as a Maintainer.
>
Yes I agree that preparing pull requests doesn't make you a maintainer
but you are the one using maintain a branch / sending pull requests as
classification method. My point is that this is orthogonal to being a
maintainer or reviewer.
>> Another difference is that when I'm listed as a maintainer, I feel an
>> obligation to answer to the patches touching that component but that's
>> not the case for components I usually act as a reviewer, I may review
>> it if I have time but if I don't, I let other people to review it.
>
> Then, in the latter case you shouldn't be listed as a Reviewer in my
> example. Anyone listed as a Reviewer in MAINTAINERS *does* have that
> obligation. That's what it means. If Reviewers don't review, they
> should be removed from MAINTAINERS.
>
Again we agree on that, that's why I said that I'm *not* officially
listed as a reviewer for Exynos SoC patches since even when I'm
interested on that, I don't have time to review every single patch.
>> >> At least for Samsung Multifunction PMIC drivers (and some of Maxim
>> >> MUICs and PMICs) these are actively used by us in existing and new
>> >> products. They are also continuously extended and actually maintained.
>> >> This means that it is not only about review of new patches but also
>> >> about caring that nothing will become broken.
>> >
>> > Exactly. This what I expect of any good code Reviewer.
>> >
>> >> I would prefer to leave the "SAMSUNG MULTIFUNCTION PMIC DEVICE
>> >> DRIVERS" entry as is - maintainers.
>>
>> I agree with Krzysztof here, I would prefer to keep them as
>> maintainers if they are maintaining the drivers.
>
> But they're not. They're reviewing and caring like a good Reviewer
> should.
>
That's your opinion, as I said my opinion is that they are maintaining
it because they care that the drivers are in good shape, testing that
no regressions are introduced, fixing bugs, etc.
>> > But you aren't maintaining the driver i.e. you don't collect patches
>> > and *maintain* them on an upstream branch. Granted some of you guys
>> > are doing a great job of maintaining branches on your downstream or
>> > BSP kernels, but conduct a Reviewer type role for upstream.
>> >
>> > You guys are pushing back like this is some kind of demotion. That's
>> > not the case at all. All it does is better describe the (very worthy)
>> > function you *actually* provide.
>> >
>>
>> But I think it makes description less accurate in fact, since without
>> $SUBJECT get_maintainers.pl reports for example:
>>
>> Krzysztof Kozlowski <k.kozlowski@samsung.com> (supporter:MAXIM PMIC
>> AND MUIC DRIVERS FOR EXYNOS BASED BO...)
>> Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
>>
>> and after the change:
>>
>> Krzysztof Kozlowski <k.kozlowski@samsung.com> (reviewer)
>> Lee Jones <lee.jones@linaro.org> (supporter:MULTIFUNCTION DEVICES (MFD))
>>
>> He also works for Samsung so the driver is not only maintained but
>> supported since he can actually take care of it as a part of his day
>> job (if I understood correctly).
>
> It's not the person that's supported, it's the driver. The driver
> doesn't need to change state.
>
Yes, is the driver that is supported but by whom? In my opinion the
supporter should be the maintainer of the driver and that is what
get_maintainer.pl thinks as well.
So in summary, you think that the difference between a maintainer and
a reviewer is if a branch with fixes / new features are kept and pull
requests sent while I think that the difference is the level of
involvement someone has with a driver regardless of how patches ends
in the subsystem tree (picked directly by subsystem maintainers or
sent through pull requests).
Is the first time I heard your definition but maybe I'm the one that
is wrong so it would be great to get a consensus on that and get it
documented somewhere.
> --
> Lee Jones
> Linaro STMicroelectronics Landing Team Lead
> Linaro.org │ Open source software for ARM SoCs
> Follow Linaro: Facebook | Twitter | Blog
Best regards,
Javier
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2015-10-28 12:10 +0100 |
| Message-ID | <qowMb-1Rt-41@gated-at.bofh.it> |
| In reply to | #1257904 |
On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote: > (Lee) think(s) that the difference between a maintainer and > a reviewer is if a branch with fixes / new features are kept and pull > requests sent while I think that the difference is the level of > involvement someone has with a driver regardless of how patches ends > in the subsystem tree (picked directly by subsystem maintainers or > sent through pull requests). > > Is the first time I heard your definition but maybe I'm the one that > is wrong so it would be great to get a consensus on that and get it > documented somewhere. I think Lee is over-analyzing. From MAINTAINERS: M: Mail patches to: FullName <address@domain> R: Designated reviewer: FullName <address@domain> These reviewers should be CCed on patches. S: Status, one of the following: Supported: Someone is actually paid to look after this. Maintained: Someone actually looks after it. "looking after" doesn't mean upstreaming. The original threads for this were: http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html https://lkml.org/lkml/2014/6/2/446 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Javier Martinez Canillas <javier@dowhile0.org> |
|---|---|
| Date | 2015-10-28 12:30 +0100 |
| Message-ID | <qox5w-1Y5-31@gated-at.bofh.it> |
| In reply to | #1257910 |
Hello Joe, On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches <joe@perches.com> wrote: > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote: >> (Lee) think(s) that the difference between a maintainer and >> a reviewer is if a branch with fixes / new features are kept and pull >> requests sent while I think that the difference is the level of >> involvement someone has with a driver regardless of how patches ends >> in the subsystem tree (picked directly by subsystem maintainers or >> sent through pull requests). >> >> Is the first time I heard your definition but maybe I'm the one that >> is wrong so it would be great to get a consensus on that and get it >> documented somewhere. > > I think Lee is over-analyzing. > > From MAINTAINERS: > M: Mail patches to: FullName <address@domain> > R: Designated reviewer: FullName <address@domain> > These reviewers should be CCed on patches. > S: Status, one of the following: > Supported: Someone is actually paid to look after this. > Maintained: Someone actually looks after it. > > "looking after" doesn't mean upstreaming. > Agreed and upstreaming doesn't mean sending pull request, you can for example upstream the downstream changes for a driver you maintain by posting patches or ack patches others post and let the subsystem maintainer to pick those (even if you are listed as the driver maintainer in MAINTAINERS). So by following Lee's definition, then most drivers' maintainers should not be called maintainers since keeping a tree with patches for both fixes and new features, sending pull requests, etc is only justified for drivers that have a lot of changes per release. Is not worth it for drivers that are in "maintenance mode" where only bugs are fixed every once in a while or features are seldom added. > The original threads for this were: > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html > https://lkml.org/lkml/2014/6/2/446 > > Thanks for the pointer. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 12:40 +0100 |
| Message-ID | <qoxfc-21J-15@gated-at.bofh.it> |
| In reply to | #1257925 |
On Wed, 28 Oct 2015, Javier Martinez Canillas wrote: > Hello Joe, > > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches <joe@perches.com> wrote: > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote: > >> (Lee) think(s) that the difference between a maintainer and > >> a reviewer is if a branch with fixes / new features are kept and pull > >> requests sent while I think that the difference is the level of > >> involvement someone has with a driver regardless of how patches ends > >> in the subsystem tree (picked directly by subsystem maintainers or > >> sent through pull requests). > >> > >> Is the first time I heard your definition but maybe I'm the one that > >> is wrong so it would be great to get a consensus on that and get it > >> documented somewhere. > > > > I think Lee is over-analyzing. > > > > From MAINTAINERS: > > M: Mail patches to: FullName <address@domain> > > R: Designated reviewer: FullName <address@domain> > > These reviewers should be CCed on patches. > > S: Status, one of the following: > > Supported: Someone is actually paid to look after this. > > Maintained: Someone actually looks after it. > > > > "looking after" doesn't mean upstreaming. > > > > Agreed and upstreaming doesn't mean sending pull request, you can for > example upstream the downstream changes for a driver you maintain by > posting patches or ack patches others post and let the subsystem > maintainer to pick those (even if you are listed as the driver > maintainer in MAINTAINERS). > > So by following Lee's definition, then most drivers' maintainers > should not be called maintainers since keeping a tree with patches for > both fixes and new features, sending pull requests, etc is only > justified for drivers that have a lot of changes per release. Is not > worth it for drivers that are in "maintenance mode" where only bugs > are fixed every once in a while or features are seldom added. Exactly right. Although, it looks like M: doesn't even mean Maintainer. If it did, I would have made these points over and over until death (or until I got bored). However, as M: actually means "Mail patches to", there seems to be very little difference between that and "Designated reviewer" and makes me wonder why the R: tag was ever even introduced. I guess all of the other guys in the threads below also thought M: meant Maintainer, or else they would have just added poor old Josh as a "Mail patches to" recipient and been done with it. > > The original threads for this were: > > > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html > > https://lkml.org/lkml/2014/6/2/446 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 13:20 +0100 |
| Message-ID | <qoxRT-2uq-11@gated-at.bofh.it> |
| In reply to | #1257931 |
On Wed, 28 Oct 2015, Lee Jones wrote: > On Wed, 28 Oct 2015, Javier Martinez Canillas wrote: > > > Hello Joe, > > > > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches <joe@perches.com> wrote: > > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote: > > >> (Lee) think(s) that the difference between a maintainer and > > >> a reviewer is if a branch with fixes / new features are kept and pull > > >> requests sent while I think that the difference is the level of > > >> involvement someone has with a driver regardless of how patches ends > > >> in the subsystem tree (picked directly by subsystem maintainers or > > >> sent through pull requests). > > >> > > >> Is the first time I heard your definition but maybe I'm the one that > > >> is wrong so it would be great to get a consensus on that and get it > > >> documented somewhere. > > > > > > I think Lee is over-analyzing. > > > > > > From MAINTAINERS: > > > M: Mail patches to: FullName <address@domain> > > > R: Designated reviewer: FullName <address@domain> > > > These reviewers should be CCed on patches. > > > S: Status, one of the following: > > > Supported: Someone is actually paid to look after this. > > > Maintained: Someone actually looks after it. > > > > > > "looking after" doesn't mean upstreaming. > > > > > > > Agreed and upstreaming doesn't mean sending pull request, you can for > > example upstream the downstream changes for a driver you maintain by > > posting patches or ack patches others post and let the subsystem > > maintainer to pick those (even if you are listed as the driver > > maintainer in MAINTAINERS). > > > > So by following Lee's definition, then most drivers' maintainers > > should not be called maintainers since keeping a tree with patches for > > both fixes and new features, sending pull requests, etc is only > > justified for drivers that have a lot of changes per release. Is not > > worth it for drivers that are in "maintenance mode" where only bugs > > are fixed every once in a while or features are seldom added. > > Exactly right. > > Although, it looks like M: doesn't even mean Maintainer. If it did, I > would have made these points over and over until death (or until I got > bored). However, as M: actually means "Mail patches to", there seems > to be very little difference between that and "Designated reviewer" > and makes me wonder why the R: tag was ever even introduced. I guess > all of the other guys in the threads below also thought M: meant > Maintainer, or else they would have just added poor old Josh as a > "Mail patches to" recipient and been done with it. Ah, but wait. get_maintainer.pl *does* assume M means Maintainer doesn't it? Which is why this came about. So if we have a "Mail patches to" entry, get_maintainer.pl tells the user that this is a Maintainer, which (given that there are over 1000 unique M: entries and I know that there are no where near that many actual Maintainers) means that it's printing out incorrect information most of the time. So back to my original thought then, what can we do to rectify this situation and make the information printed more meaningful. Again, I'm back to using the R: tag appropriately. Any (technical, which aren't based on "but I really want to be listed as a Maintainer") thoughts? > > > The original threads for this were: > > > > > > http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000830.html > > > https://lkml.org/lkml/2014/6/2/446 -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2015-10-28 13:30 +0100 |
| Message-ID | <qoy1A-2xS-15@gated-at.bofh.it> |
| In reply to | #1257945 |
On Wed, 2015-10-28 at 12:14 +0000, Lee Jones wrote: > Ah, but wait. get_maintainer.pl *does* assume M means Maintainer > doesn't it? No, it looks at the "S:" line. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 13:30 +0100 |
| Message-ID | <qoy1A-2xS-13@gated-at.bofh.it> |
| In reply to | #1257946 |
On Wed, 28 Oct 2015, Joe Perches wrote: > On Wed, 2015-10-28 at 12:14 +0000, Lee Jones wrote: > > Ah, but wait. get_maintainer.pl *does* assume M means Maintainer > > doesn't it? > > No, it looks at the "S:" line. Right. Then assumes because the driver is 'supported' or 'maintained' that the person(s) listed in M: must be the Supporter(s) or the Maintainer(s). -- Lee Jones Linaro STMicroelectronics Landing Team Lead Linaro.org │ Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Joe Perches <joe@perches.com> |
|---|---|
| Date | 2015-10-28 13:50 +0100 |
| Message-ID | <qoykW-2Fh-15@gated-at.bofh.it> |
| In reply to | #1257947 |
On Wed, 2015-10-28 at 12:24 +0000, Lee Jones wrote: > On Wed, 28 Oct 2015, Joe Perches wrote: > > On Wed, 2015-10-28 at 12:14 +0000, Lee Jones wrote: > > > Ah, but wait. get_maintainer.pl *does* assume M means Maintainer > > > doesn't it? > > > > No, it looks at the "S:" line. > > Right. Then assumes because the driver is 'supported' or 'maintained' > that the person(s) listed in M: must be the Supporter(s) or the > Maintainer(s). Yup, except "assumes" isn't correct. It's your definition of maintainer that seems to be at odds with what's otherwise apparently commonly accepted. Any "M:" entry in a section where the "S:" line is maintained or supported is generally classified as a maintainer too. For instance: I think most accept that I am a maintainer of get_maintainer.pl. I wrote most of get_maintainer and I accept most but not all patches to it by acking some and nacking or otherwise requesting changes in others. I do not upstream it. I don't have a git tree at kernel.org and don't really need one. I rarely send pull requests. I generally upstream through Andrew Morton and he uses quilt. It's working well enough. The kernel summit thread from last year that initiated the "R:" line in MAINTAINERS was primarily focused on encouraging new patch review and honoring those that already take time to review. http://lists.linuxfoundation.org/pipermail/ksummit-discuss/2014-May/000764.html Knock your self out about clarifying how process should work. Generate consensus where necessary but don't try too hard. It's working reasonably well right now. Most people are able to maintain sanity by ignoring what's unimportant to them. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Javier Martinez Canillas <javier@dowhile0.org> |
|---|---|
| Date | 2015-10-28 14:10 +0100 |
| Message-ID | <qoyEj-329-65@gated-at.bofh.it> |
| In reply to | #1257945 |
Hello Lee, On Wed, Oct 28, 2015 at 1:14 PM, Lee Jones <lee.jones@linaro.org> wrote: > On Wed, 28 Oct 2015, Lee Jones wrote: > >> On Wed, 28 Oct 2015, Javier Martinez Canillas wrote: >> >> > Hello Joe, >> > >> > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches <joe@perches.com> wrote: >> > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote: >> > >> (Lee) think(s) that the difference between a maintainer and >> > >> a reviewer is if a branch with fixes / new features are kept and pull >> > >> requests sent while I think that the difference is the level of >> > >> involvement someone has with a driver regardless of how patches ends >> > >> in the subsystem tree (picked directly by subsystem maintainers or >> > >> sent through pull requests). >> > >> >> > >> Is the first time I heard your definition but maybe I'm the one that >> > >> is wrong so it would be great to get a consensus on that and get it >> > >> documented somewhere. >> > > >> > > I think Lee is over-analyzing. >> > > >> > > From MAINTAINERS: >> > > M: Mail patches to: FullName <address@domain> >> > > R: Designated reviewer: FullName <address@domain> >> > > These reviewers should be CCed on patches. >> > > S: Status, one of the following: >> > > Supported: Someone is actually paid to look after this. >> > > Maintained: Someone actually looks after it. >> > > >> > > "looking after" doesn't mean upstreaming. >> > > >> > >> > Agreed and upstreaming doesn't mean sending pull request, you can for >> > example upstream the downstream changes for a driver you maintain by >> > posting patches or ack patches others post and let the subsystem >> > maintainer to pick those (even if you are listed as the driver >> > maintainer in MAINTAINERS). >> > >> > So by following Lee's definition, then most drivers' maintainers >> > should not be called maintainers since keeping a tree with patches for >> > both fixes and new features, sending pull requests, etc is only >> > justified for drivers that have a lot of changes per release. Is not >> > worth it for drivers that are in "maintenance mode" where only bugs >> > are fixed every once in a while or features are seldom added. >> >> Exactly right. >> >> Although, it looks like M: doesn't even mean Maintainer. If it did, I >> would have made these points over and over until death (or until I got >> bored). However, as M: actually means "Mail patches to", there seems >> to be very little difference between that and "Designated reviewer" >> and makes me wonder why the R: tag was ever even introduced. I guess >> all of the other guys in the threads below also thought M: meant >> Maintainer, or else they would have just added poor old Josh as a >> "Mail patches to" recipient and been done with it. > > Ah, but wait. get_maintainer.pl *does* assume M means Maintainer > doesn't it? Which is why this came about. So if we have a "Mail > patches to" entry, get_maintainer.pl tells the user that this is a Joe already answered but I'll elaborate a little bit: "M:" means "Mail patches to" and "S:" means "Status" so what get_maintainers.pl is reports the person in "M:" printing the status of the file(s). So for example if the file has "S: Supported" then the person listed in "M:" is shown as "supporter" while if the status is "S: Maintained", the person is listed as "maintainer". There isn't a "Reviewed" status to specify files that are looked by "Designated reviewers", it can be added but I don't see the reason of it. > Maintainer, which (given that there are over 1000 unique M: entries > and I know that there are no where near that many actual Maintainers) > means that it's printing out incorrect information most of the time. > Well, that's correct according to your definition of maintainer (people with a tree that sends pull requests) but I can believe that there are 1K unique maintainers for different small components (without taking into account what components may be obsolete / not used anymore) even if these maintainers don't send pull request because the patch load is low and rely on subsystem maintainers to pick directly from the list with their Acks. For me the maintainer is that a) cares about the file and makes sure that things remain working, fix issues, reviews patches from others, etc b) is someone that actually understand the code in the files. A subsystem maintainer has the last word of what gets merged into the subsystem but may not be familiar with code under the subsystem and relies on the file / driver maintainer to Ack the patch as correct since that person is the one that knows the code. > So back to my original thought then, what can we do to rectify this > situation and make the information printed more meaningful. Again, > I'm back to using the R: tag appropriately. > > Any (technical, which aren't based on "but I really want to be listed > as a Maintainer") thoughts? > I haven't read a "but I really want to be listed as a maintainer" thought in this thread. I think the problem is the definition of what a maintainer in Linux really means. For you is someone that keeps a tree and sends pull request (for me that is what I call a subsystem maintainer) while for others it seems that maintainer means someone who care about a set of files, knows the code, makes sure that things keep working and Ack patches to those files when posted. Best regards, Javier -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
| From | Lee Jones <lee.jones@linaro.org> |
|---|---|
| Date | 2015-10-28 14:40 +0100 |
| Message-ID | <qoz7l-3cS-49@gated-at.bofh.it> |
| In reply to | #1257985 |
On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
> On Wed, Oct 28, 2015 at 1:14 PM, Lee Jones <lee.jones@linaro.org> wrote:
> > On Wed, 28 Oct 2015, Lee Jones wrote:
> >
> >> On Wed, 28 Oct 2015, Javier Martinez Canillas wrote:
> >>
> >> > Hello Joe,
> >> >
> >> > On Wed, Oct 28, 2015 at 12:06 PM, Joe Perches <joe@perches.com> wrote:
> >> > > On Wed, 2015-10-28 at 11:53 +0100, Javier Martinez Canillas wrote:
> >> > >> (Lee) think(s) that the difference between a maintainer and
> >> > >> a reviewer is if a branch with fixes / new features are kept and pull
> >> > >> requests sent while I think that the difference is the level of
> >> > >> involvement someone has with a driver regardless of how patches ends
> >> > >> in the subsystem tree (picked directly by subsystem maintainers or
> >> > >> sent through pull requests).
> >> > >>
> >> > >> Is the first time I heard your definition but maybe I'm the one that
> >> > >> is wrong so it would be great to get a consensus on that and get it
> >> > >> documented somewhere.
> >> > >
> >> > > I think Lee is over-analyzing.
> >> > >
> >> > > From MAINTAINERS:
> >> > > M: Mail patches to: FullName <address@domain>
> >> > > R: Designated reviewer: FullName <address@domain>
> >> > > These reviewers should be CCed on patches.
> >> > > S: Status, one of the following:
> >> > > Supported: Someone is actually paid to look after this.
> >> > > Maintained: Someone actually looks after it.
> >> > >
> >> > > "looking after" doesn't mean upstreaming.
> >> > >
> >> >
> >> > Agreed and upstreaming doesn't mean sending pull request, you can for
> >> > example upstream the downstream changes for a driver you maintain by
> >> > posting patches or ack patches others post and let the subsystem
> >> > maintainer to pick those (even if you are listed as the driver
> >> > maintainer in MAINTAINERS).
> >> >
> >> > So by following Lee's definition, then most drivers' maintainers
> >> > should not be called maintainers since keeping a tree with patches for
> >> > both fixes and new features, sending pull requests, etc is only
> >> > justified for drivers that have a lot of changes per release. Is not
> >> > worth it for drivers that are in "maintenance mode" where only bugs
> >> > are fixed every once in a while or features are seldom added.
> >>
> >> Exactly right.
> >>
> >> Although, it looks like M: doesn't even mean Maintainer. If it did, I
> >> would have made these points over and over until death (or until I got
> >> bored). However, as M: actually means "Mail patches to", there seems
> >> to be very little difference between that and "Designated reviewer"
> >> and makes me wonder why the R: tag was ever even introduced. I guess
> >> all of the other guys in the threads below also thought M: meant
> >> Maintainer, or else they would have just added poor old Josh as a
> >> "Mail patches to" recipient and been done with it.
> >
> > Ah, but wait. get_maintainer.pl *does* assume M means Maintainer
> > doesn't it? Which is why this came about. So if we have a "Mail
> > patches to" entry, get_maintainer.pl tells the user that this is a
>
> Joe already answered but I'll elaborate a little bit:
>
> "M:" means "Mail patches to" and "S:" means "Status" so what
> get_maintainers.pl is reports the person in "M:" printing the status
> of the file(s).
>
> So for example if the file has "S: Supported" then the person listed
> in "M:" is shown as "supporter" while if the status is "S:
> Maintained", the person is listed as "maintainer".
>
> There isn't a "Reviewed" status to specify files that are looked by
> "Designated reviewers", it can be added but I don't see the reason of
> it.
Not sure why you wrote all of this. We know *why* get_maintainer.pl
does what it does. What I'm saying is, that I personally believe this
is the wrong behaviour in what I'm *guessing* is the majority of the
time.
> > Maintainer, which (given that there are over 1000 unique M: entries
> > and I know that there are no where near that many actual Maintainers)
> > means that it's printing out incorrect information most of the time.
>
> Well, that's correct according to your definition of maintainer
> (people with a tree that sends pull requests) but I can believe that
> there are 1K unique maintainers for different small components
> (without taking into account what components may be obsolete / not
> used anymore) even if these maintainers don't send pull request
> because the patch load is low and rely on subsystem maintainers to
> pick directly from the list with their Acks.
Then they are not Maintainers. They are Reviewers who rely on
Maintainers. In your example above it's the Maintainers that are
Maintainers and the people who review the code are Reviewers. The
clues are in the words. ;)
> For me the maintainer is that a) cares about the file and makes sure
> that things remain working, fix issues, reviews patches from others,
> etc b) is someone that actually understand the code in the files. A
> subsystem maintainer has the last word of what gets merged into the
> subsystem but may not be familiar with code under the subsystem and
> relies on the file / driver maintainer to Ack the patch as correct
> since that person is the one that knows the code.
Then what is a Reviewer?
> > So back to my original thought then, what can we do to rectify this
> > situation and make the information printed more meaningful. Again,
> > I'm back to using the R: tag appropriately.
> >
> > Any (technical, which aren't based on "but I really want to be listed
> > as a Maintainer") thoughts?
> >
>
> I haven't read a "but I really want to be listed as a maintainer"
> thought in this thread.
If you had no vested interest in this, you would be able to see the
logic in what I'm saying. Again I'm *guess*, but I think there is
some emotional reasons for you pushing back so hard. I could always
be wrong though.
> I think the problem is the definition of what a maintainer in Linux
> really means. For you is someone that keeps a tree and sends pull
> request (for me that is what I call a subsystem maintainer)
Right. A Level 3 Maintainer sends pull-requests to a Level 2
Maintainer, who sends pull-requests to a Level 1 Maintainer, who sends
pull-requests to Linus. Maintainers at *all* levels collect patches
and Maintain them before sending on.
reiterate:
Reviewers care about particular driver(s)/domain(s) that they know
well. They provide solid reviews and possible testing (because they
are likely to have the h/w). They then provide Acked-by:s so that a
Maintainer can collect the patch.
> while for
> others it seems that maintainer means someone who care about a set of
> files, knows the code, makes sure that things keep working and Ack
> patches to those files when posted.
goto reiterate; ;)
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[toc] | [prev] | [next] | [standalone]
Page 1 of 3 [1] 2 3 Next page →
Back to top | Article view | linux.kernel
csiph-web