linux-kernel - Re: Taking a break

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, 20 Dec 2018 06:26:35 +0100
From:   Willy Tarreau <w@....eu>
To:     Thomas Gleixner <tglx@...utronix.de>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: Re: Taking a break - time to look back

Hi Thomas,

[trimmed cc list]

On Thu, Dec 20, 2018 at 01:46:24AM +0100, Thomas Gleixner wrote:
>  1) Lack of code quality
> 
>     This is a problem which I observe increasing over many years.
> 
>     The feature driven duct tape engineering mode is progressing
>     massively. Proper root cause analysis has become the exception not the
>     rule.
> 
>     In our normal kernel development it's just annoying and eats up review
>     capacity unnecessarily, but in the face of a timeline or real bugs it's
>     worse. Aside of wasting time for review rounds, at some point other
>     people have to just drop everything else and get it fixed.
> 
>     Even if some people don't want to admit it, the increasing complexity
>     of the hardware technology and as a consequence the increasing
>     complexity of the kernel code base makes it mandatory to put
>     correctness and maintainability first and not to fall for the
>     featuritis and performance chants which are driving this
>     industry. We've learned painfully what that causes in the last year.

I totally agree on this point by having been hit by the same problem on
another project (haproxy). It turns out that everyone are interested in
features, reliability and performance. But these ones cannot come without
maintainability, and in practice only these 3 former ones can improve over
time. Maintainability only gets worse and is never ever addressed "later"
by incremental code updates. Now I tend to be a bastard on this point and
to demand properly documented patches, properly named functions/variables
and everything that helps other people quickly figure why the code works
or doesn't work, knowing that performance/features/reliability area easily
addressed afterwards by many other contributors when the code is maintainable.

> That said, I'm going to vanish into vacation until Jan. 7th and I'm not
> going to read any (LKML) mails until then. As I predict from experience
> that my (filtered) inbox will be a untameable beast by then, don't expect
> me to actually go through it mail by mail. If your mail will unfortunately
> end up in the 'lkml/done' folder without being read, I'm sure you'll notice
> and find a way to resend it.

Take your well deserved vacation with your family, ignore e-mails and don't
read the news, it will only make you relax better, and you'll come back
fully recharged.

Willy