linux-kernel - Re: Slow DOWN, please!!!

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:	Thu, 1 May 2008 02:42:35 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Linus Torvalds <torvalds@...ux-foundation.org>
Cc:	Willy Tarreau <w@....eu>, David Miller <davem@...emloft.net>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jiri Slaby <jirislaby@...il.com>
Subject: Re: Slow DOWN, please!!!

On Thursday, 1 of May 2008, Linus Torvalds wrote:
> 
> On Thu, 1 May 2008, Willy Tarreau wrote:
[--snip--]

> I do _not_ want to slow down development by setting some kind of "quality 
> bar" - but I do believe that we should keep our quality high, not because 
> of any hoops we need to jump through, but because we take pride in the 
> thing we do.

Well, we certainly should, but do we always remeber about it?  Honest, guv?

> [ An example of this: I don't believe code review tends to much help in 
>   itself, but I *do* believe that the process of doing code review makes 
>   people more aware of the fact that others are looking at the code they 
>   produce, and that in turn makes the code often better to start with.

It may help directly, for example when people realize that they work on
conflicting or just related changes.

>   And I think publicly announced git trees and -mm and linux-next are 
>   great partly because they end up doing that same thing. I heartily 
>   encourage submaintainers to always Cc: linux-kernel when they send me a 
>   "please pull" request - I don't know if anybody else ever really pulls 
>   that tree, but I do think that it's very healthy to write that message 
>   and think of it as a publication event. ]

I totally agree with that.

Still, the issue at hand is that
(1) The code merged during a merge window is somewhat opaque from the tester's
     point of view and if a regression is found, the only practical means to
    figure out what caused it is to carry out a bisection (which generally is
    unpleasant, to put it lightly).
(2) Many regressions are introduced during merge windows (relative to the
    total amount of code merged they are a few, but the raw numbers are
    significant) and because of (1) the process of removing them is generally
    painful for the affected people.
(3) The suspicion is that the number of regressions introduced during merge
    windows has something to do with the quality of code being below
    expectations, that in turn may be related to the fact that it's being
    developed very rapidly.

My opinion is that we need to solve this issue sooner rather than later and so
the question is how we are going to approach that.

Thanks,
Rafael
--
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/