lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 11 Nov 2006 23:03:17 +1100
From:	Neil Brown <neilb@...e.de>
To:	Willy Tarreau <w@....eu>
Cc:	Randy Dunlap <rdunlap@...otime.net>,
	Stephen Hemminger <shemminger@...l.org>,
	Jesper Juhl <jesper.juhl@...il.com>,
	Al Boldi <a1426z@...ab.com>, linux-kernel@...r.kernel.org
Subject: Re: A proposal; making 2.6.20 a bugfix only version.

On Saturday November 11, w@....eu wrote:
> On Fri, Nov 10, 2006 at 08:53:11AM -0800, Randy Dunlap wrote:
> > Either that or lkml is/remains for bug reporting and we move development
> > somewhere else.  Or my [repeated] preference:
> > 
> > do development on specific mailing lists (although there would
> > likely need to be a fallback list when it's not clear which mailing
> > list should be used)
> 
> I've been thinking about this too for a while now. There is something
> like half of the email volume which are (semi-)automated emails
> containing patches moving from a GIT tree to another. I think that
> moving this to some linux-dev or something like this would :
> 
>   1) reduce the noise on LKML so that problem reports are better caught
>   2) reduce the global email volume because instead of sending all these
>      emails to 10-20000 persons(?), only maybe a thousand will be subscribed.
>   3) reduce even more the latency between post and publication due to 2.
> 
> I don't know if others would be interested, in which case it would be wise
> to poll on the subject and include Matti and Davem to the discussion.

I personally don't think the volume on lkml is a particular problem.
I have filters which pick out the items that might be of particular
interest to me (matching on words like 'nfs' 'raid' 'md' in my case)
and the rest goes in to a bucket that I glance at occasionally.  When
I do, I scan the subject lines and read the things that seem
interesting at the time, and delete the rest unread.

I prefer this to splitting lkml into multiple lists because it makes
it much easier for me to change my areas of interest from time to
time.  I don't have to go and subscribe to different lists, I just use a
different pattern for matching (either in my brain or in my filter).

I suspect the main reason that I miss problem reports that are
relevant to me is that people choose poor Subject: lines.
e.g. when I scan the subjects of a thread I might see multiple threads
all with 
           Subject: Re: 2.6.18-rc5-mm2
and I'll have no idea what they are really about, and I don't have
time to read them all.   If reporters simple put
                                   (nfs problem)
at the end of the subject (or whatever is appropriate) then it would
be a LOT easier to avoid missing things (some people do do this.  I
see their bug reports promptly when relevant).
Fortunately akpm is very good at reading all of these and forwarding
things as appropriate (thanks Andrew) but that shouldn't really be
necessary.  And that situation won't be improved by reducing traffic
on any list or splitting up the list (there are already plenty of
other lists around).  It really requires people who submit bug reports
to think about what they are doing, and make it easy for people to
find their bug report.

I guess bugzilla encourages people to think about their bug report and
tag it accordingly.  In that sense bugzilla is good.  I just hate
using it - I have to use a web browser, and it feels like a closed,
private discussion, which really isn't appropriate.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ