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]

Message-ID: <20080501005727.GO29330@cs181133002.pp.htv.fi>
Date:	Thu, 1 May 2008 03:57:27 +0300
From:	Adrian Bunk <bunk@...nel.org>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>, rjw@...k.pl,
	davem@...emloft.net, linux-kernel@...r.kernel.org,
	jirislaby@...il.com
Subject: Re: Slow DOWN, please!!!

On Wed, Apr 30, 2008 at 03:41:24PM -0700, Andrew Morton wrote:
> On Wed, 30 Apr 2008 15:31:22 -0700 (PDT)
> Linus Torvalds <torvalds@...ux-foundation.org> wrote:
> 
> > Any suggestions on how to convince people that their code is not worth 
> > merging?
> 
> Raise the quality.  Then the volume will automatically decrease.

100% ACK to "Raise the quality" (no matter whether it influences the volume).

> Which leads us to...  the volume isn't a problem per-se.  The problem is
> quality.  It's the fact that they vary inversely which makes us say "slow
> down".
> 
> So David's Subject: should have been "Do Better, please".  Slowing down is
> just a side-effect.  And, we expect, a tool.
> 
> 
> We should be discussing how to raise the quality of our work.

One big problem I see is Linus wanting to merge all drivers regardless 
of the quality.

Linus said in [1]:
"I'd really rather have the driver merged, and then *other* people can 
 send patches!"

The problem is that such "other people" do not exist (except perhaps Al) 
for non-trivial stuff.

My favorite gem from this driver we merged in 2.6.25 is:
  grep -C4 volatile drivers/infiniband/hw/nes/nes_nic.c

Fixing such stuff aren't "janitorial kind of things", and people are 
actually more motivated to fix their code for getting it into the kernel 
than to fix their code after it went into the kernel.

I am not saying we shouldn't merge such a driver at all or set 
unrealistic high quality goals - I'm for merging all code of good 
quality that provides functionality not yet into the kernel.

But we need some minimum quality level.

cu
Adrian

[1] http://lkml.org/lkml/2008/2/21/334

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

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