linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Stefan Richter <stefanr@s5r6.in-berlin.de>
Cc: "Giacomo A. Catenazzi" <cate@cateee.net>,
	"Rafael J. Wysocki" <rjw@sisk.pl>,
	Valdis.Kletnieks@vt.edu,
	Linus Torvalds <torvalds@linux-foundation.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	David Miller <davem@davemloft.net>
Subject: Re: using LKML for subsystem development
Date: Fri, 1 Feb 2008 10:40:57 +0100	[thread overview]
Message-ID: <20080201094057.GA27910@elte.hu> (raw)
In-Reply-To: <479B42C4.7020507@s5r6.in-berlin.de>


(a late reply - the merge window made me ignore this thread ;-)

* Stefan Richter <stefanr@s5r6.in-berlin.de> wrote:

> > (or if that's still too much, follow the time-deferred lkml updates 
> > of lwn.net)
> > 
> > Realize it: it's _far_ easier to filter down a too verbose source of 
> > information, than to put scattered, inaccessible pieces of 
> > information back together. It's far easier to get a cup of water 
> > from the open firehose than it is to gather the drops once they 
> > spilled on the ground.
> 
> Correct.

so you agree with me on this one? Even though you clearly do not realize 
it, you've in essence conceded my whole point.

The "off-lkml" practice makes us lose information, in a largely 
irreversible way - and that's the end of the argument. Q.E.D.

just let me show you an example of the conflict of logic in your 
argument:

> [ people ]
>
>   - who are afraid of subscribing to a high-volume mailinglist (even 
>     if they have the technical means at their disposal to manage that 
>     volume),

on one side you have people who are _willing_ to participate, who'd like 
to help out, who'd like to follow the development of Linux, but cannot 
for some areas because it's split into 150 small mailing lists with no 
coherent way to access and manage them.

on the other side you talk about people who are 'afraid' of 
participating in Linux development, even though "they have the technical 
means at their disposal to manage that volume". I.e., they "could" 
participate, but they "dont want to" - for time constraints or just 
excuses like "it's difficult to filter".

and your solution: you advocate destroying information by pulling it off 
lkml for the sake of the _second_ group of people? That's perverse.

all the other arguments you say are just totally immaterial. Yes, we 
could and should make lkml a better place (you could have volunteered to 
summarize lkml discussions of your favorite topic on a separate list, 
you could forward interesting topics to people you know dont read all of 
it, etc. etc.,) but your proposed solution of _destroying lkml_ by 
pulling off development into those lists is just about the most stupid 
solution a person could have come up with.

	Ingo

  reply	other threads:[~2008-02-01  9:41 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-01-24 23:17 Linux 2.6.24 Linus Torvalds
2008-01-24 23:41 ` Linus Torvalds
2008-01-25  9:10   ` Giacomo A. Catenazzi
2008-01-25  9:58     ` Valdis.Kletnieks
2008-01-25 11:58       ` Rafael J. Wysocki
2008-01-25 12:34         ` Giacomo A. Catenazzi
2008-01-25 23:50           ` Stefan Richter
2008-01-26  0:42             ` using LKML for subsystem development (was Re: Linux 2.6.24) Stefan Richter
2008-01-26  3:28               ` Valdis.Kletnieks
2008-01-26 13:31                 ` using LKML for subsystem development Stefan Richter
2008-01-27  7:37                   ` Valdis.Kletnieks
2008-01-26 11:28               ` using LKML for subsystem development (was Re: Linux 2.6.24) Ingo Molnar
2008-01-26 14:07                 ` using LKML for subsystem development David Miller
2008-01-26 14:45                   ` Stefan Richter
2008-01-26 14:25                 ` Stefan Richter
2008-02-01  9:40                   ` Ingo Molnar [this message]
2008-02-01 19:53                     ` Stefan Richter
2008-01-26  3:19             ` Linux 2.6.24 Valdis.Kletnieks
2008-01-25 11:35     ` Ingo Molnar
2008-01-25 10:11 ` [PATCH] linux-2.6.24/drivers/hid/hid-input.c Philipp Matthias Hahn
2008-01-25 10:30   ` Jiri Kosina
2008-02-03 12:35 ` Linux 2.6.24 Jan Engelhardt

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=20080201094057.GA27910@elte.hu \
    --to=mingo@elte.hu \
    --cc=Valdis.Kletnieks@vt.edu \
    --cc=cate@cateee.net \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=stefanr@s5r6.in-berlin.de \
    --cc=torvalds@linux-foundation.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 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).