* Stefan Richter <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
