Re: using LKML for subsystem development (was Re: Linux 2.6.24)

[Ingo Molnar]

* Stefan Richter <stefanr@xxxxxxxxxxxxxxxxx> wrote:

> [...] How will subscribers of LKML decide which discussion threads in 
> the huge amount of traffic are worth to glance at?  Each of us has 
> only a limited amount of time for LKML consumption.

uhm. How do you decide which of the 10000 git commits per upstream 
kernel release (more than 100 a day) you'll look at?

easy: you download the full git tree from Linus, to have all the 
information in one place, but you then you use filters, because you are 
not interested in the whole 9 million lines of kernel code.

You use filters such as:

   git-log drivers/net/

Note what you dont get: you dont get to download just drivers/net and 
nothing else. It makes no sense in isolation because this is a single 
kernel codebase that is released as one logical unit. Everyone who finds 
a bug in the kernel can be assumed to have access to the full kernel 
source. If we talk about the "upstream kernel", we all can rely on all 
of us having access to the full body of information we do development 
on. This unified information base is _powerful_ stuff.

and by logical extension, the public development "metadata" of that 
unified source tree should be ... just as easily accessible. Such as ... 
a single forum of discussion - an email list for example.

People who dont want to follow the whole, will ... filter.

For example they will only open the threads they are interested in.

Or you dont even have to read all the subjects: you can filter on "net" 
subjects for example, that filter took 2 seconds to apply for my mailer, 
on 37119 mails in my lkml folder, and this reduced the number of 
messages to 3959 - about 10% of the total size.

Or filter on _people_. The "domain experts" you are interested in. 
Filter on all mails from David S. Miller if you are interested in 
networking topics. You'll have a really good grasp of what's going on in 
that area, without having to invest too much time.

Or subscribe to lwn.net who do weekly updates with links to lkml. If you 
dont have the time, you might have the money to pay people who have the 
time to do work for you. (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. 
Sure, it all seems easier if you get everything presented on a nice 
little mailing list, with just the right people subscribed - but that 
isolation is the same kind of "closed source" thinking that causes so 
many problems in computing today.

lkml is about using this whole "open development" idea and pushing it to 
its logical conclusion. "Domain experts" hiding away in caves is just a 
fancy excuse for something much different and it can be really harmful 
to the end result (the kernel's quality). Most of the subsystems already 
do their development on lkml, but it could be further improved upon.

	Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/