LKML signal to noise ratio-- improvement

LKML signal to noise ratio-- improvement

[William Knop]

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

RE: LKML signal to noise ratio-- improvement

[M. Edward Borasky]

I rather like the way the R project does it. They have three lists: one for
developers, one for "announcements" and one for help. The announcements list
is probably irrelevant; the announcements show up on the other two lists. Of
course, if you ask a question on the help list you will be told to RTFM if
necessary. Still, the biggest improvement I'd like to see on LKML is a
usable search engine / archive.

--
Take Your Trading to the Next Level!
M. Edward Borasky, Meta-Trading Coach

mailto:znmeb@borasky-research.net
http://www.borasky-research.net

RE: LKML signal to noise ratio-- improvement

[Georg Nikodym]

On Tue, 2001-12-25 at 22:13, M. Edward Borasky wrote:

> necessary. Still, the biggest improvement I'd like to see on LKML is a
> usable search engine / archive.

Uh... groups.google.com fills this need quite nicely.

Specifically, try: http://groups.google.com/groups?group=linux.kernel

Re: LKML signal to noise ratio-- improvement

[Georgi Chorbadzhiyski]

Georg Nikodym wrote:

> On Tue, 2001-12-25 at 22:13, M. Edward Borasky wrote:
> 
> 
>>necessary. Still, the biggest improvement I'd like to see on LKML is a
>>usable search engine / archive.
>>
> 
> Uh... groups.google.com fills this need quite nicely.
> 
> Specifically, try: http://groups.google.com/groups?group=linux.kernel

Umm that would be: http://groups.google.com/groups?group=fa.linux.kernel
:)

Re: LKML signal to noise ratio-- improvement

[Chris Friesen]

Georgi Chorbadzhiyski wrote:
> 
> Georg Nikodym wrote:
> 
> > On Tue, 2001-12-25 at 22:13, M. Edward Borasky wrote:
> >
> >
> >>necessary. Still, the biggest improvement I'd like to see on LKML is a
> >>usable search engine / archive.
> >>
> >
> > Uh... groups.google.com fills this need quite nicely.
> >
> > Specifically, try: http://groups.google.com/groups?group=linux.kernel
> 
> Umm that would be: http://groups.google.com/groups?group=fa.linux.kernel
> :)

Did you try the link?  It works.  There are multiple newsgroups on the list, 
you can also use:

http://groups.google.com/groups?group=mlist.linux.kernel


-- 
Chris Friesen                    | MailStop: 043/33/F10  
Nortel Networks                  | work: (613) 765-0557
3500 Carling Avenue              | fax:  (613) 765-2986
Nepean, ON K2H 8E9 Canada        | email: cfriesen@nortelnetworks.com

Re: LKML signal to noise ratio-- improvement

[Mark Harrop]

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/

RE: LKML signal to noise ratio-- improvement

[William Knop]

M. Edward Borasky wrote:
>I rather like the way the R project does it. They have three lists:
>one for developers, one for "announcements" and one for help. The
>announcements list is probably irrelevant; the announcements show up
>on the other two lists.

Ah yes, I meant to include -announcements too, but I forgot by the time I 
got down to the named parts. Perhaps a -proposals would be good too, so 
something like -misc posts would truly not fit into a preconcieved catagory. 
If people still announce to the other lists, they can be scolded.

Although, it seems that with so many lists it gets too complex and parts of 
the system might be ignored; perhaps you are right, that three lists would 
suffice. But either way, one list with 7000+ messages a month is, as many 
have admitted, not optimal for developers and maintainers.

Thanks,
Will

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.