lkml.org 
[lkml]   [2001]   [Dec]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectLKML signal to noise ratio-- improvement
Date
Hello All,
I have recently been reading new and archived posts regarding the wish for a
more organized development system for the kernel. Some people want
centralized version control and bug tracking, some want sophisticated tools
to accomplish something close to what we already have, some just don't feel
like investing the effort to devise a better system, and some insist the way
things are done are the best way to do them.

I happen to know there is a better way of doing things, because a major
complaint is the 'signal to noise ratio'. The proverb, "One man's trash is
another man's treasure" is a great way to think about the problem.

For instance, some people like discussing major reworks of the kernel, where
the change is not necessary. Hackers like to screw around in this area, and
most of the time developers and maintainers do not. In fact, developers and
maintainers rather appreciate bug and patch submissions, but do not
appreciate updating their kill lists.

I believe Alan Cox put it well when he said, "Did you have to change the
subject line. It makes it harder to kill file when people keep doing that,"
regarding the /proc reworking. Correct me if I am wrong, but he probably
does not want to hear the rework/overhaul discussions.

Since this is a mailing list, I don't believe the correct solution is to let
search tools evolve our problems away. If you read from an archive, that
would be acceptable, but if you subscribe it is not.

So, where am I going with this? Well, the solution is that lkml be split
into sublists, namely linux-kernel-bug, linux-kernel-patch,
linux-kernel-help, and linux-kernel-discussion (or perhaps -misc or
-general, although -discussion seems to encourage posting more, which IMHO
is a good thing). I like to think of it as a "non-invasive" solution. One
could have a symbolic "linux-kernel" which subscribes to all the lists so
the current lkml list of subscribers could be preserved.

Discussion related to bugs and patches would spawn from the posts of bugs
and patches in their respective lists, and misc ones would start and be
contained in the general -discussion list.

A bonus is the honey pot technique used to discover network viruses could be
used to kill spam from lkml. Presumably the advertisers would post to more
than one of the l-k lists, so if a post goes to more than one list within a
minute of eachother, delete them both. The list could generate and store
(for a minute) a checksum and maybe length for each message to compare to
new messages incoming on the other lists. So the message would be delayed a
minute before being sent, but less spam. Of course this requires extra
development/programming of the mailing system, so I consider it low-priority
compared to simply separating the list. It could be that vger already does
this, using the other lists; I don't know.

-Will

PS I am not subscribed anymore, so if you could CC responses to me, I'd
appreciate it.

_________________________________________________________________
Send and receive Hotmail on your mobile device: http://mobile.msn.com

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

\
 
 \ /
  Last update: 2005-03-22 13:14    [W:0.052 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site