From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Lezcano Subject: Re: [PATCH] cpuidle: add maintainer entry Date: Thu, 25 Apr 2013 18:32:08 +0200 Message-ID: <51795A88.6020608@linaro.org> References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org> <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org> <5178D5EF.9090102@linaro.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Return-path: Received: from mail-wg0-f48.google.com ([74.125.82.48]:47541 "EHLO mail-wg0-f48.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755786Ab3DYQcN (ORCPT ); Thu, 25 Apr 2013 12:32:13 -0400 Received: by mail-wg0-f48.google.com with SMTP id f11so1561486wgh.15 for ; Thu, 25 Apr 2013 09:32:11 -0700 (PDT) In-Reply-To: Sender: linux-pm-owner@vger.kernel.org List-Id: linux-pm@vger.kernel.org To: Rob Herring Cc: Viresh Kumar , rjw@sisk.pl, Andrew Lunn , khilman@deeprootsystems.com, Benjamin Herrenschmidt , Linus Walleij , Nicolas Ferre , Paul Mackerras , josephl@nvidia.com, Kukjin Kim , Stephen Warren , magnus.damm@gmail.com, Jean-Christophe Plagniol-Villard , lenb@kernel.org, linaro-kernel@lists.linaro.org, Jason Cooper , Arnd Bergmann , linux-pm@vger.kernel.org, nsekhar@ti.com, Rob Herring , 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 On 04/25/2013 05:50 PM, Rob Herring wrote: > On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano > wrote: >> On 04/25/2013 08:49 AM, Viresh Kumar wrote: >>> On 25 April 2013 12:15, Daniel Lezcano = 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 upstream= ing >>>> and to the driver maintainer for acked-by. >>>> >>>> If you add an entry in MAINTAINERS like: >>>> >>>> ARM/CALXEDA HIGHBANK ARCHITECTURE >>>> M: Rob Herring >>>> L: linux-arm-kernel@lists.infradead.org (moderated for non-su= bscribers) >>>> S: Maintained >>>> F: arch/arm/mach-highbank/ >>>> +F: drivers/cpuidle/cpuidle-calxeda.c >>>> >>>> That will add confusion while we are trying to clarify the situati= on >>>> with a single entry point for the patches submission. If someone w= ants >>>> 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 linu= x-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 t= he >> maintainer of the driver before taking the patches. >=20 > It not a maintainer's job to solicit acks. It is the submitter's job > to Cc the correct people. The maintainer should only check for > necessary CC/acks and bitch at the submitter if they did not use > get_maintainers.pl. Ok, I was saying exactly the same, but it was misphrased. I meant, we can be confident Rafael won't accept patches if they are no= t acked by the correct people. > Perhaps the MAINTAINERS file needs to be distributed to scale better > or we need a way to put the maintainer data into the source and be > usable by get_maintainers.pl. Yep, the latter could be a good idea. >>> 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 ent= ry for >>> this driver rather than merging it with arch/ entries. >> >> Yes, actually it was an example to show the confusion we could be fa= cing. >=20 > I'm confused about what is the confusion... --=20 Linaro.org =E2=94=82 Open source software for= ARM SoCs =46ollow Linaro: Facebook | Twitter | Blog From mboxrd@z Thu Jan 1 00:00:00 1970 From: daniel.lezcano@linaro.org (Daniel Lezcano) Date: Thu, 25 Apr 2013 18:32:08 +0200 Subject: [PATCH] cpuidle: add maintainer entry In-Reply-To: References: <1366810463-17495-1-git-send-email-daniel.lezcano@linaro.org> <51781B48.30208@gmail.com> <5178D0EF.3090004@linaro.org> <5178D5EF.9090102@linaro.org> Message-ID: <51795A88.6020608@linaro.org> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 04/25/2013 05:50 PM, Rob Herring wrote: > On Thu, Apr 25, 2013 at 2:06 AM, Daniel Lezcano > wrote: >> On 04/25/2013 08:49 AM, Viresh Kumar wrote: >>> On 25 April 2013 12:15, Daniel Lezcano 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 >>>> 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. > > It not a maintainer's job to solicit acks. It is the submitter's job > to Cc the correct people. The maintainer should only check for > necessary CC/acks and bitch at the submitter if they did not use > get_maintainers.pl. Ok, I was saying exactly the same, but it was misphrased. I meant, we can be confident Rafael won't accept patches if they are not acked by the correct people. > Perhaps the MAINTAINERS file needs to be distributed to scale better > or we need a way to put the maintainer data into the source and be > usable by get_maintainers.pl. Yep, the latter could be a good idea. >>> 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. > > I'm confused about what is the confusion... -- Linaro.org ? Open source software for ARM SoCs Follow Linaro: Facebook | Twitter | Blog