[tip:core/urgent] MAINTAINERS: Restore "L: linux-kernel@vger.kernel.org" entries

[tip-bot for Ingo Molnar]

Commit-ID: 62f45f9a202c318fd5fb43cd40ef687b7dd2825f
Gitweb: http://git.kernel.org/tip/62f45f9a202c318fd5fb43cd40ef687b7dd2825f
Author: Ingo Molnar <mi...@kernel.org>
AuthorDate: Tue, 21 Jan 2014 10:59:20 +0100
Committer: Ingo Molnar <mi...@kernel.org>
CommitDate: Tue, 21 Jan 2014 11:24:40 +0100

MAINTAINERS: Restore "L: linux-...@vger.kernel.org" entries

A couple of years ago all the "L: lkml" email list entries in
MAINTAINERS were removed and replaced with a 'the rest' entry
at the end of the file - under the theory that this is unnecessary
duplication and that people would find it intuitive:

b5472cddbe2c MAINTAINERS: remove L: linux-...@vger.kernel.org from all but "THE REST"

So it turns out that it's all but intuitive, not all people
use scripts/get_maintainer.pl to extract maintainer contact info,
some people read the MAINTAINERS file and see the lack of 'L:' entries
of various lkml-only subsystems and are sending patches to the
maintainers only, without Cc:-ing lkml. They arguably have a point.

In hindsight removing all the "L: lkml" entries was probably not
an overly good idea, not all mechanic duplication should be eliminated:
in files read by humans it's useful to have 'at a glance' summary for
all email addresses important to a subsystem's maintenance, in a single
place, without too many imported rules and assumptions.

So, to make the lkml fallback really apparent, add back 'L: lkml'
entries to all subsystem entries whose workflow I'm involved in.
This should at minimum be a per subsystem policy thing.

Acked-by: Peter Zijlstra <pet...@infradead.org>
Acked-by: Thomas Gleixner <tg...@linutronix.de>
Cc: Linus Torvalds <torv...@linux-foundation.org>
Cc: Andrew Morton <ak...@linux-foundation.org>
Cc: Alan Cox <al...@linux.intel.com>
Cc: Joe Perches <j...@perches.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Paul E. McKenney <pau...@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <ac...@redhat.com>
Link: http://lkml.kernel.org/n/tip-lhzlymtgmm...@git.kernel.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
MAINTAINERS | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index ce1645e..aff3763 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2191,6 +2191,7 @@ F: include/linux/clk.h
CLOCKSOURCE, CLOCKEVENT DRIVERS
M: Daniel Lezcano <daniel....@linaro.org>
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
F: drivers/clocksource
@@ -3985,6 +3986,7 @@ F: include/uapi/linux/hid*

HIGH-RESOLUTION TIMERS, CLOCKEVENTS, DYNTICKS
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Maintained
F: Documentation/timers/
@@ -4655,6 +4657,7 @@ F: net/irda/
IRQ SUBSYSTEM
M: Thomas Gleixner <tg...@linutronix.de>
S: Maintained
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
F: kernel/irq/
F: drivers/irqchip/
@@ -5285,6 +5288,7 @@ F: drivers/media/usb/dvb-usb-v2/lmedm04*
LOCKDEP AND LOCKSTAT
M: Peter Zijlstra <pet...@infradead.org>
M: Ingo Molnar <mi...@redhat.com>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git core/locking
S: Maintained
F: Documentation/lockdep*.txt
@@ -6581,6 +6585,7 @@ M: Peter Zijlstra <a.p.zi...@chello.nl>
M: Paul Mackerras <pau...@samba.org>
M: Ingo Molnar <mi...@redhat.com>
M: Arnaldo Carvalho de Melo <ac...@ghostprotocols.net>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git perf/core
S: Supported
F: kernel/events/*
@@ -6704,6 +6709,7 @@ F: drivers/scsi/pm8001/

POSIX CLOCKS and TIMERS
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
F: fs/timerfd.c
@@ -7099,6 +7105,7 @@ F: drivers/net/wireless/ray*
RCUTORTURE MODULE
M: Josh Triplett <jo...@freedesktop.org>
M: "Paul E. McKenney" <pau...@linux.vnet.ibm.com>
+L: linux-...@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: Documentation/RCU/torture.txt
@@ -7106,6 +7113,7 @@ F: kernel/rcu/torture.c

RCUTORTURE TEST FRAMEWORK
M: "Paul E. McKenney" <pau...@linux.vnet.ibm.com>
+L: linux-...@vger.kernel.org
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
F: tools/testing/selftests/rcutorture
@@ -7129,6 +7137,7 @@ F: net/rds/
READ-COPY UPDATE (RCU)
M: Dipankar Sarma <dipa...@in.ibm.com>
M: "Paul E. McKenney" <pau...@linux.vnet.ibm.com>
+L: linux-...@vger.kernel.org
W: http://www.rdrop.com/users/paulmck/RCU/
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
@@ -7432,6 +7441,7 @@ F: drivers/mmc/host/dw_mmc*
TIMEKEEPING, CLOCKSOURCE CORE, NTP
M: John Stultz <john....@linaro.org>
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
F: include/linux/clocksource.h
@@ -7457,6 +7467,7 @@ F: drivers/watchdog/sc1200wdt.c
SCHEDULER
M: Ingo Molnar <mi...@redhat.com>
M: Peter Zijlstra <pet...@infradead.org>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git sched/core
S: Maintained
F: kernel/sched/
@@ -7823,6 +7834,7 @@ F: mm/sl?b.c
SLEEPABLE READ-COPY UPDATE (SRCU)
M: Lai Jiangshan <la...@cn.fujitsu.com>
M: "Paul E. McKenney" <pau...@linux.vnet.ibm.com>
+L: linux-...@vger.kernel.org
W: http://www.rdrop.com/users/paulmck/RCU/
S: Supported
T: git git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu.git
@@ -9531,6 +9543,7 @@ M: Thomas Gleixner <tg...@linutronix.de>
M: Ingo Molnar <mi...@redhat.com>
M: "H. Peter Anvin" <h...@zytor.com>
M: x...@kernel.org
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/core
S: Maintained
F: Documentation/x86/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Joe Perches]

On Tue, 2014-01-21 at 07:49 -0800, tip-bot for Ingo Molnar wrote:

> MAINTAINERS: Restore "L: linux-...@vger.kernel.org" entries
>
> A couple of years ago all the "L: lkml" email list entries in
> MAINTAINERS were removed and replaced with a 'the rest' entry
> at the end of the file - under the theory that this is unnecessary
> duplication and that people would find it intuitive:

You are politicking with the commentary.
Intuition had nothing to do with the removal,

The idea was to avoid having an L: lkml line for
each of more than 1200 sections so people wouldn't
think that any section that didn't have an lkml
entry shouldn't need to have lkml on the cc list
for a patch.

Also, SubmittingPatches had and still has:

6) Select your CC (e-mail carbon copy) list.

Unless you have a reason NOT to do so, CC linux-...@vger.kernel.org.

Arguably, that same info should be added to the
MAINTAINERS header instead of each section.

> b5472cddbe2c MAINTAINERS: remove L: linux-...@vger.kernel.org from all but "THE REST"
>
> So it turns out that it's all but intuitive, not all people
> use scripts/get_maintainer.pl to extract maintainer contact info,
> some people read the MAINTAINERS file and see the lack of 'L:' entries
> of various lkml-only subsystems and are sending patches to the
> maintainers only, without Cc:-ing lkml. They arguably have a point.

shrug, I think it would be better if people
used get_maintainer more often.

MAINTAINERS already says:

PLEASE CC: the maintainers and mailing lists that are generated
by scripts/get_maintainer.pl.

Maybe duplicating the SubmittingPatches block into
the MAINTAINERS intro is good enough.

> diff --git a/MAINTAINERS b/MAINTAINERS
[]

> @@ -4655,6 +4657,7 @@ F: net/irda/
> IRQ SUBSYSTEM
> M: Thomas Gleixner <tg...@linutronix.de>
> S: Maintained
> +L: linux-...@vger.kernel.org

If this is done, can you please standardize on
placing the L: line immediately after the M: line
and before the S: line as was done for all the
other added lines.

Thanks.

[Ingo Molnar]

* Joe Perches <j...@perches.com> wrote:

> Also, SubmittingPatches had and still has:
>
> 6) Select your CC (e-mail carbon copy) list.
>
> Unless you have a reason NOT to do so, CC linux-...@vger.kernel.org.
>
> Arguably, that same info should be added to the
> MAINTAINERS header instead of each section.

You have cut out my main argument from you reply and have ignored it:

>> In hindsight removing all the "L: lkml" entries was probably not
>> an overly good idea, not all mechanic duplication should be
>> eliminated: in files read by humans it's useful to have 'at a
>> glance' summary for all email addresses important to a subsystem's
>> maintenance, in a single place, without too many imported rules
>> and assumptions.

Which is not a very honest way to conduct discussions :-(

That section replies to most of your arguments.

> > b5472cddbe2c MAINTAINERS: remove L: linux-...@vger.kernel.org from all but "THE REST"
> >
> > So it turns out that it's all but intuitive, not all people
> > use scripts/get_maintainer.pl to extract maintainer contact info,
> > some people read the MAINTAINERS file and see the lack of 'L:' entries
> > of various lkml-only subsystems and are sending patches to the
> > maintainers only, without Cc:-ing lkml. They arguably have a point.
>
> shrug, I think it would be better if people
> used get_maintainer more often.

People are people, they'll use well constructed human-readable sources
of information like the MAINTAINERS file just fine.

> MAINTAINERS already says:

That's irrelevant really, reality tells us that good people are
looking at the entries and are using them as-is. For such things
technology should adapt to people, not the other way around.

> > diff --git a/MAINTAINERS b/MAINTAINERS
> []
> > @@ -4655,6 +4657,7 @@ F: net/irda/
> > IRQ SUBSYSTEM
> > M: Thomas Gleixner <tg...@linutronix.de>
> > S: Maintained
> > +L: linux-...@vger.kernel.org
>
> If this is done, can you please standardize on
> placing the L: line immediately after the M: line
> and before the S: line as was done for all the
> other added lines.

Good point, fixed.

Thanks,

Ingo

[tip-bot for Ingo Molnar]

Commit-ID: 981c3a4ff8596a9dcd2b058ee12d6749639c32a5
Gitweb: http://git.kernel.org/tip/981c3a4ff8596a9dcd2b058ee12d6749639c32a5

Author: Ingo Molnar <mi...@kernel.org>
AuthorDate: Tue, 21 Jan 2014 10:59:20 +0100
Committer: Ingo Molnar <mi...@kernel.org>

CommitDate: Wed, 22 Jan 2014 13:25:55 +0100

MAINTAINERS: Restore "L: linux-...@vger.kernel.org" entries

A couple of years ago all the "L: lkml" email list entries in
MAINTAINERS were removed and replaced with a 'the rest' entry
at the end of the file - under the theory that this is unnecessary
duplication and that people would find it intuitive:

b5472cddbe2c MAINTAINERS: remove L: linux-...@vger.kernel.org from all but "THE REST"

So it turns out that it's all but intuitive, not all people
use scripts/get_maintainer.pl to extract maintainer contact info,
some people read the MAINTAINERS file and see the lack of 'L:' entries
of various lkml-only subsystems and are sending patches to the
maintainers only, without Cc:-ing lkml. They arguably have a point.

In hindsight removing all the "L: lkml" entries was probably not
an overly good idea, not all mechanic duplication should be eliminated:
in files read by humans it's useful to have 'at a glance' summary for
all email addresses important to a subsystem's maintenance, in a single
place, without too many imported rules and assumptions.

So, to make the lkml fallback really apparent, add back 'L: lkml'
entries to all subsystem entries whose workflow I'm involved in.
This should at minimum be a per subsystem policy thing.

Acked-by: Peter Zijlstra <pet...@infradead.org>
Acked-by: Thomas Gleixner <tg...@linutronix.de>
Cc: Linus Torvalds <torv...@linux-foundation.org>
Cc: Andrew Morton <ak...@linux-foundation.org>
Cc: Alan Cox <al...@linux.intel.com>
Cc: Joe Perches <j...@perches.com>
Cc: "H. Peter Anvin" <h...@zytor.com>
Cc: Paul E. McKenney <pau...@linux.vnet.ibm.com>
Cc: Arnaldo Carvalho de Melo <ac...@redhat.com>
Link: http://lkml.kernel.org/n/tip-lhzlymtgmm...@git.kernel.org
Signed-off-by: Ingo Molnar <mi...@kernel.org>
---
MAINTAINERS | 13 +++++++++++++
1 file changed, 13 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS

index ce1645e..e048de5 100644

--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2191,6 +2191,7 @@ F: include/linux/clk.h
CLOCKSOURCE, CLOCKEVENT DRIVERS
M: Daniel Lezcano <daniel....@linaro.org>
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Supported
F: drivers/clocksource
@@ -3985,6 +3986,7 @@ F: include/uapi/linux/hid*

HIGH-RESOLUTION TIMERS, CLOCKEVENTS, DYNTICKS
M: Thomas Gleixner <tg...@linutronix.de>
+L: linux-...@vger.kernel.org
T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git timers/core
S: Maintained
F: Documentation/timers/

@@ -4654,6 +4656,7 @@ F: net/irda/

IRQ SUBSYSTEM
M: Thomas Gleixner <tg...@linutronix.de>

+L: linux-...@vger.kernel.org
S: Maintained

T: git git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git irq/core
F: kernel/irq/

[Joe Perches]

On Wed, 2014-01-22 at 13:27 +0100, Ingo Molnar wrote:
> * Joe Perches <j...@perches.com> wrote:

[]

> You have cut out my main argument from you reply and have ignored it:

Not ignored. Threaded email works fine.

Your main argument is that some people don't cc lkml
because section entries don't specify it explicitly.

My main argument, which you elided, is that some people
will not cc lkml because they will see some sections
with L: entries with lkml and others without, and will
therefore _not_ cc lkml instead.

So I think the rule should be either every section has
an lkml entry or no section does.

Pick one.

Mixing styles just causes a different type of error.

> Which is not a very honest way to conduct discussions :-(

[]

> > MAINTAINERS already says:
>
> That's irrelevant really, reality tells us that good people are
> looking at the entries and are using them as-is. For such things
> technology should adapt to people, not the other way around.

If you are going to complain about "honesty in
argumentation", try it yourself.

Be an exemplar.

Describing a previous change as being made for
intuitions sake when it wasn't, isn't.

cheers, Joe

[Mark Brown]

On Wed, Jan 22, 2014 at 05:02:24AM -0800, Joe Perches wrote:
> On Wed, 2014-01-22 at 13:27 +0100, Ingo Molnar wrote:
> > * Joe Perches <j...@perches.com> wrote:

> > You have cut out my main argument from you reply and have ignored it:

> Not ignored. Threaded email works fine.

> Your main argument is that some people don't cc lkml
> because section entries don't specify it explicitly.

> My main argument, which you elided, is that some people
> will not cc lkml because they will see some sections
> with L: entries with lkml and others without, and will
> therefore _not_ cc lkml instead.

> So I think the rule should be either every section has
> an lkml entry or no section does.

> Pick one.

> Mixing styles just causes a different type of error.

The other option is that we just don't worry if people CC lkml or not -
for things with a dedicated list it's not super critical that people CC
to lkml and in practice doing so would make it even harder to work with
than it is at the minute. If they want to do so that's fine and it
shouldn't be a problem but at this point it's questionable if this is
something that we actively want to encourge.

In practice this is exactly what's been happening for years anyway so
it's not something I'd expect to be controversial.

[Joe Perches]

On Wed, 2014-01-22 at 16:09 +0000, Mark Brown wrote:
> On Wed, Jan 22, 2014 at 05:02:24AM -0800, Joe Perches wrote:
> > So I think the rule should be either every section has
> > an lkml entry or no section does.

[]

> The other option is that we just don't worry if people CC lkml or not -
> for things with a dedicated list it's not super critical that people CC
> to lkml

true

> and in practice doing so would make it even harder to work with
> than it is at the minute.

How? What is "it" here?

> If they want to do so that's fine and it
> shouldn't be a problem but at this point it's questionable if this is
> something that we actively want to encourge.
>
> In practice this is exactly what's been happening for years anyway so
> it's not something I'd expect to be controversial.

Perhaps the biggest benefit of cc'ing lkml is
a centralized repository of proposed patches in
https://patchwork.kernel.org/project/LKML/list/

A secondary benefit (sometimes it's just a bother)
is that you get a smallish readership that comments
on semi-frequent code defects and style nits that
enhances overall code quality.

But today, many patches do not hit lkml at all.

netdev, many of the specific arch types, staging,
etc, have separate lists and many patches aren't
cc'd to lkml.

Maybe that's not a bad thing. Dunno.

I can't think of an easy way to figure out how
often emailed patches are using lists generated by
get_maintainer so I've no idea if this matters.

Perhaps the best argument to cc lkml is still this:

https://lkml.org/lkml/2009/5/27/44

On Tue, 2009-05-26 at 23:00 -0700, Andrew Morton wrote:
> Most subsystem maintainers shed patches like a hobo does dandruff. If
> it is cc'ed to lkml then there is a decent chance that I will see it
> and will un-lose it.
>
> This happens probably 100 or more times per kernel release.

[Ingo Molnar]

* Joe Perches <j...@perches.com> wrote:

> Your main argument is that some people don't cc lkml
> because section entries don't specify it explicitly.

No, my main argument continues to be that having a 'at a glance'
contact summary _in a single place_ is eminently useful to humans,
because it's so simple:

>> In hindsight removing all the "L: lkml" entries was probably not
>> an overly good idea, not all mechanic duplication should be
>> eliminated: in files read by humans it's useful to have 'at a
>> glance' summary for all email addresses important to a subsystem's
>> maintenance, in a single place, without too many imported rules
>> and assumptions.

No amount of rules written elsewhere can counter that simple concept!

> My main argument, which you elided, is that some people
> will not cc lkml because they will see some sections
> with L: entries with lkml and others without, and will
> therefore _not_ cc lkml instead.

That continues to be an invalid argument for two main reasons:

1) People tend to think local and are not very good at importing
context when on unfamiliar terrain.

2) The 'problem' you outline can be solved with technology by simply
adding back the proper lkml entries. The number of eyeballs
looking at MAINTAINERS is probably at least two orders of
magnitude higher than the number of changes done to that file, so
it's worth having a good summary for every entry. Or at least
it's worth having it for the subsystems I care about.

The problem _I_ outlined, that people won't Cc: lkml if they don't see
it in the MAINTAINERS entry could only be solved by changing people's
behavior, which approach in my experience rarely works.

> So I think the rule should be either every section has
> an lkml entry or no section does.
>
> Pick one.

No, you continue to misunderstand my argument. I think the rule should
be for you to honestly read and reply to arguments when they are
presented to you, especially when done twice in a row. You never even
_acknowledged_ my main point, let alone countered it successfully.
Hence you came up with this false 'conclusion' prematurely and
presented it with baseless, cocky self-confidence.

What an annoyingly unproductive waste of time.

Thanks,

Ingo

[Joe Perches]

On Wed, 2014-01-22 at 18:36 +0100, Ingo Molnar wrote:
> * Joe Perches <j...@perches.com> wrote:
>
> > Your main argument is that some people don't cc lkml
> > because section entries don't specify it explicitly.
>
> No, my main argument continues to be that having a 'at a glance'
> contact summary _in a single place_ is eminently useful to humans,
> because it's so simple:

I don't doubt simplicity is good.

> You never even
> _acknowledged_ my main point, let alone countered it successfully.

There's no 'counter' to it.

You simply don't seem to agree that some people will
choose _not_ to cc lkml when some sections have it and
others sections don't.

> Hence you came up with this false 'conclusion' prematurely and
> presented it with baseless, cocky self-confidence.

> What an annoyingly unproductive waste of time.

Any discussion where someone disagrees with you seems
to end with you asserting that. I doubt it's true.

> Thanks,

Anytime.

cheers, Joe

[Mark Brown]

On Wed, Jan 22, 2014 at 09:30:23AM -0800, Joe Perches wrote:
> On Wed, 2014-01-22 at 16:09 +0000, Mark Brown wrote:

> > and in practice doing so would make it even harder to work with
> > than it is at the minute.

> How? What is "it" here?

linux-kernel, it's rather hig volume.

> > In practice this is exactly what's been happening for years anyway so
> > it's not something I'd expect to be controversial.

> Perhaps the biggest benefit of cc'ing lkml is
> a centralized repository of proposed patches in
> https://patchwork.kernel.org/project/LKML/list/

Which isn't triumphantly usable as a result.

> Perhaps the best argument to cc lkml is still this:

> https://lkml.org/lkml/2009/5/27/44

That's one of the reasons one might choose to CC lkml, yes. But equally
well it doesn't need to be the default for everything and usually
someone is watching the subsystem lists.

[Joe Perches]

On Wed, 2014-01-22 at 18:06 +0000, Mark Brown wrote:
> On Wed, Jan 22, 2014 at 09:30:23AM -0800, Joe Perches wrote:
> > Perhaps the biggest benefit of cc'ing lkml is
> > a centralized repository of proposed patches in
> > https://patchwork.kernel.org/project/LKML/list/
>
> Which isn't triumphantly usable as a result.

True, the current search mechanism isn't ideal as it
seems to only search titles and the robots.txt file
there doesn't allow spidering.

Anyway I do think having the ability to search for
previously proposed patches to a particular file in a
single place useful but not absolutely mandatory.