linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Willy Tarreau <w@1wt.eu>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: LKML <linux-kernel@vger.kernel.org>
Subject: Re: Taking a break - time to look back
Date: Thu, 20 Dec 2018 06:26:35 +0100	[thread overview]
Message-ID: <20181220052635.GB18931@1wt.eu> (raw)
In-Reply-To: <alpine.DEB.2.21.1812200022580.1651@nanos.tec.linutronix.de>

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

  reply	other threads:[~2018-12-20  5:26 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-20  0:46 Taking a break - time to look back Thomas Gleixner
2018-12-20  5:26 ` Willy Tarreau [this message]
2019-01-02 23:51 ` [patch] Fix up l1ft documentation was " Pavel Machek
2019-03-11 10:21   ` Pavel Machek
2019-03-11 13:05     ` Thomas Gleixner
2019-03-11 13:13       ` Pavel Machek
2019-03-11 22:31         ` Thomas Gleixner
2019-03-12 11:57           ` Pavel Machek
2019-03-24 20:41             ` Thomas Gleixner
2019-08-28 22:18               ` Pavel Machek
2019-03-11 14:38     ` Jonathan Corbet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20181220052635.GB18931@1wt.eu \
    --to=w@1wt.eu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).