From: Daniel Lezcano <daniel.lezcano@linaro.org>
To: Viresh Kumar <viresh.kumar@linaro.org>
Cc: Rob Herring <robherring2@gmail.com>,
rjw@sisk.pl, andrew@lunn.ch, khilman@deeprootsystems.com,
benh@kernel.crashing.org, linus.walleij@linaro.org,
nicolas.ferre@atmel.com, paulus@samba.org, josephl@nvidia.com,
kgene.kim@samsung.com, swarren@wwwdotorg.org,
magnus.damm@gmail.com, plagnioj@jcrosoft.com, lenb@kernel.org,
linaro-kernel@lists.linaro.org, jason@lakedaemon.net,
arnd@arndb.de, linux-pm@vger.kernel.org, nsekhar@ti.com,
rob.herring@calxeda.com, horms@verge.net.au, ben-linux@fluff.org,
horms+renesas@verge.net.au, linux@maxim.org.za,
linux-arm-kernel@lists.infradead.org, kernel@pengutronix.de
Subject: Re: [PATCH] cpuidle: add maintainer entry
Date: Thu, 25 Apr 2013 09:06:23 +0200 [thread overview]
Message-ID: <5178D5EF.9090102@linaro.org> (raw)
In-Reply-To: <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
On 04/25/2013 08:49 AM, Viresh Kumar wrote:
> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>
>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>
>> It should contains the upstream maintainer for the subsystem, and
>> optionally a co-maintainer.
>>
>> The MAINTAINERS file gives informations about the patch submission path.
>>
>> The file's header should contain the maintainer of the driver, so the
>> submitted patches will go to the subsystem maintainer for upstreaming
>> and to the driver maintainer for acked-by.
>>
>> If you add an entry in MAINTAINERS like:
>>
>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>> M: Rob Herring <rob.herring@calxeda.com>
>> L: linux-arm-kernel@lists.infradead.org (moderated for non-subscribers)
>> S: Maintained
>> F: arch/arm/mach-highbank/
>> +F: drivers/cpuidle/cpuidle-calxeda.c
>>
>> That will add confusion while we are trying to clarify the situation
>> with a single entry point for the patches submission. If someone wants
>> to submit a patch for this driver, it will look at the MAINTAINERS file
>> and won't know if it should send the patch against arm-soc or linux-pm.
>
> I though otherwise. We can add entry in MAINTAINERS for any module.
> Module can be a framework/architecture or a single driver.
IMO, there are too much drivers for that. It is simpler for someone to
read the MAINTAINERS file to find the cpuidle drivers goes through
linux-pm. I think we can trust Rafael to ask for the acked-by from the
maintainer of the driver before taking the patches.
> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
> wrong as it adds to confusion and so there should be a separate entry for
> this driver rather than merging it with arch/ entries.
Yes, actually it was an example to show the confusion we could be facing.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org │ Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
WARNING: multiple messages have this Message-ID (diff)
From: daniel.lezcano@linaro.org (Daniel Lezcano)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] cpuidle: add maintainer entry
Date: Thu, 25 Apr 2013 09:06:23 +0200 [thread overview]
Message-ID: <5178D5EF.9090102@linaro.org> (raw)
In-Reply-To: <CAKohpo=Ct7WCBSOqmgk8asVyXWa5o+jqpTwaQgxKVm_XNLfnMA@mail.gmail.com>
On 04/25/2013 08:49 AM, Viresh Kumar wrote:
> On 25 April 2013 12:15, Daniel Lezcano <daniel.lezcano@linaro.org> wrote:
>> On 04/24/2013 07:50 PM, Rob Herring wrote:
>
>>> Shouldn't MAINTAINERS contain the driver maintainers too?
>>
>> It should contains the upstream maintainer for the subsystem, and
>> optionally a co-maintainer.
>>
>> The MAINTAINERS file gives informations about the patch submission path.
>>
>> The file's header should contain the maintainer of the driver, so the
>> submitted patches will go to the subsystem maintainer for upstreaming
>> and to the driver maintainer for acked-by.
>>
>> If you add an entry in MAINTAINERS like:
>>
>> ARM/CALXEDA HIGHBANK ARCHITECTURE
>> M: Rob Herring <rob.herring@calxeda.com>
>> L: linux-arm-kernel at lists.infradead.org (moderated for non-subscribers)
>> S: Maintained
>> F: arch/arm/mach-highbank/
>> +F: drivers/cpuidle/cpuidle-calxeda.c
>>
>> That will add confusion while we are trying to clarify the situation
>> with a single entry point for the patches submission. If someone wants
>> to submit a patch for this driver, it will look at the MAINTAINERS file
>> and won't know if it should send the patch against arm-soc or linux-pm.
>
> I though otherwise. We can add entry in MAINTAINERS for any module.
> Module can be a framework/architecture or a single driver.
IMO, there are too much drivers for that. It is simpler for someone to
read the MAINTAINERS file to find the cpuidle drivers goes through
linux-pm. I think we can trust Rafael to ask for the acked-by from the
maintainer of the driver before taking the patches.
> Adding entry for cpuidle driver of a architecture as you wrote for calxeda is
> wrong as it adds to confusion and so there should be a separate entry for
> this driver rather than merging it with arch/ entries.
Yes, actually it was an example to show the confusion we could be facing.
Thanks
-- Daniel
--
<http://www.linaro.org/> Linaro.org ? Open source software for ARM SoCs
Follow Linaro: <http://www.facebook.com/pages/Linaro> Facebook |
<http://twitter.com/#!/linaroorg> Twitter |
<http://www.linaro.org/linaro-blog/> Blog
next prev parent reply other threads:[~2013-04-25 7:06 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-04-24 13:34 [PATCH] cpuidle: add maintainer entry Daniel Lezcano
2013-04-24 13:34 ` Daniel Lezcano
2013-04-24 13:55 ` Jason Cooper
2013-04-24 13:55 ` Jason Cooper
2013-04-24 14:23 ` Andrew Lunn
2013-04-24 14:23 ` Andrew Lunn
2013-04-24 16:55 ` Kevin Hilman
2013-04-24 16:55 ` Kevin Hilman
2013-04-25 12:09 ` Linus Walleij
2013-04-25 12:09 ` Linus Walleij
2013-04-25 18:27 ` Rafael J. Wysocki
2013-04-25 18:27 ` Rafael J. Wysocki
2013-04-26 8:32 ` Linus Walleij
2013-04-26 8:32 ` Linus Walleij
2013-04-26 10:53 ` Daniel Lezcano
2013-04-26 10:53 ` Daniel Lezcano
2013-04-24 17:50 ` Rob Herring
2013-04-24 17:50 ` Rob Herring
2013-04-25 6:45 ` Daniel Lezcano
2013-04-25 6:45 ` Daniel Lezcano
2013-04-25 6:49 ` Viresh Kumar
2013-04-25 6:49 ` Viresh Kumar
2013-04-25 7:06 ` Daniel Lezcano [this message]
2013-04-25 7:06 ` Daniel Lezcano
2013-04-25 15:50 ` Rob Herring
2013-04-25 15:50 ` Rob Herring
2013-04-25 16:32 ` Daniel Lezcano
2013-04-25 16:32 ` Daniel Lezcano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5178D5EF.9090102@linaro.org \
--to=daniel.lezcano@linaro.org \
--cc=andrew@lunn.ch \
--cc=arnd@arndb.de \
--cc=ben-linux@fluff.org \
--cc=benh@kernel.crashing.org \
--cc=horms+renesas@verge.net.au \
--cc=horms@verge.net.au \
--cc=jason@lakedaemon.net \
--cc=josephl@nvidia.com \
--cc=kernel@pengutronix.de \
--cc=kgene.kim@samsung.com \
--cc=khilman@deeprootsystems.com \
--cc=lenb@kernel.org \
--cc=linaro-kernel@lists.linaro.org \
--cc=linus.walleij@linaro.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-pm@vger.kernel.org \
--cc=linux@maxim.org.za \
--cc=magnus.damm@gmail.com \
--cc=nicolas.ferre@atmel.com \
--cc=nsekhar@ti.com \
--cc=paulus@samba.org \
--cc=plagnioj@jcrosoft.com \
--cc=rjw@sisk.pl \
--cc=rob.herring@calxeda.com \
--cc=robherring2@gmail.com \
--cc=swarren@wwwdotorg.org \
--cc=viresh.kumar@linaro.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.