Re: LKML signal to noise ratio-- improvement

["Mark Harrop" <mharrop@iprimus.com.au>]

I appreciate you thinking along this line, but I think it won't work in the
long run..why ?

What I have noticed on other lists where there a -general, -devel, etc., is
that people end up cc'ing to the other lists, and people who are on all list
get everything 2 or 3 times, and those who are not on all lists might miss
something when 1 person did not continue to cc to the other list !!

Then the moderator has to step in and ask everyone not to cc and stay on
topic !

I'm sure everyone on this list has had that experience before ???

I think this is one that never gets solved.

My opinion is that I rather get it all, and just delete what I don't want.
Yeah, it takes time and bandwidth, but at least I know I will get EVERYTHING
I want, and NOTHING I dodn't want, because I AM IN CHARGE ;-)

Either way, keep up the good work people; you are helping so many with your
free time !


Cheers!
Mark Harrop

mharrop@iprimus.com.au

    `\|||/
      (@@)
ooO_(_)_Ooo___________________________
_____|_____|_____|_____|_____|_____|_____|

Epping, Melbourne, Victoria, AUSTRALIA.
----- Original Message -----
From: "William Knop" <w_knop@hotmail.com>
To: <linux-kernel@vger.kernel.org>
Sent: Wednesday, December 26, 2001 1:55 PM
Subject: LKML signal to noise ratio-- improvement


| 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/