LKML Archive on
help / color / mirror / Atom feed
From: Ingo Molnar <>
To: Mikael Pettersson <>
Cc: Tino Keitel <>,,
	Linus Torvalds <>,
	Andrew Morton <>
Subject: Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini
Date: Mon, 28 Jan 2008 17:11:34 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

* Mikael Pettersson <> wrote:

> Ok, I can see how my overly terse statement could be interpreted in 
> this way, and I apologize for that.
> However, it _is_ a fact that there is a proliferation of specialized 
> mailing lists, and it is also a fact that many developers _only_ read 
> those lists. I'm in no way defending this behaviour, on the contrary I 
> probably dislike it as much as you do. But we can't ignore it.

i'm not worried about that aspect: those developers either write perfect 
code that never needs any tester or user assistance (in which case our 
discussion is moot), or if it's buggy then these developers will 
eventually be replaced with more capable people who are helping their 
testers and users more actively by reading lkml and responding there.

What we must not do is to give in to the splintering and laziness and 
actively _chase people away_ from lkml.

> I should of course have written something like "please cc: 
> <whateverlist>" instead of the stupid "wrong mailing" list comment.

yeah, thanks, that will do fine.

_Helping_ subsystem maintainers become aware of problems and 
cross-Cc:-ing to whatever preferred email alias they use (be that their 
own mailing list address or netdev@) is a necessary and positive feature 
of lkml: almost by definition the user has little idea about what is 
wrong with their kernel, and if the mail is unspecific enough or labeled 
incorrectly then it's easy for a maintainer to miss it. (It's already a 
very good first step when user know that the problem area is their 
kernel to begin with.)

Putting the "weight of initial discovery" on to the user on the other 
hand is actively harmful. It will only result in users picking the wrong 
list and being ignored there, upstream maintainers not getting a full 
picture about what kind of per subsystem bugs people are experiencing, 
etc., etc. The only thing that works in the long run is to make the 
private development email aliases _opt-in_ feature, and to always have a 
main body of information: lkml.


      parent reply	other threads:[~2008-01-28 16:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-28  0:29 Tino Keitel
2008-01-28  8:21 ` Mikael Pettersson
2008-01-28  8:48   ` Tino Keitel
2008-01-28 15:59     ` Stephen Hemminger
2008-01-28 12:55   ` Ingo Molnar
2008-01-28 13:37     ` Mikael Pettersson
2008-01-28 13:43       ` Tino Keitel
2008-01-28 14:12         ` Adrian Bunk
2008-01-28 15:22           ` Rafael J. Wysocki
2008-01-28 16:11       ` Ingo Molnar [this message]

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \
    --subject='Re: 2.6.24 regression: Wake On Lan in sky2 broken on Mac mini' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).