linux-kernel - Re: [PATCH v6 1/6] fbdev/matrox: Remove trailing whitespaces

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] [day] [month] [year] [list]

Message-ID: <7c2a6687-9c4e-efed-5e25-774b582e9a27@linux-m68k.org>
Date:   Fri, 12 May 2023 20:04:48 +1000 (AEST)
From:   Finn Thain <fthain@...ux-m68k.org>
To:     Thomas Zimmermann <tzimmermann@...e.de>
cc:     Helge Deller <deller@....de>, Sui Jingfeng <15330273260@....cn>,
        geert@...ux-m68k.org, javierm@...hat.com, daniel@...ll.ch,
        vgupta@...nel.org, chenhuacai@...nel.org, kernel@...0n.name,
        davem@...emloft.net, arnd@...db.de, sam@...nborg.org,
        linux-fbdev@...r.kernel.org, dri-devel@...ts.freedesktop.org,
        linux-arch@...r.kernel.org, linux-snps-arc@...ts.infradead.org,
        linux-kernel@...r.kernel.org, linux-ia64@...r.kernel.org,
        loongarch@...ts.linux.dev, linux-m68k@...ts.linux-m68k.org,
        sparclinux@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
        linux-parisc@...r.kernel.org
Subject: Re: [PATCH v6 1/6] fbdev/matrox: Remove trailing whitespaces

On Thu, 11 May 2023, Thomas Zimmermann wrote:

> But I'd really like to see most of these drivers being moved into 
> staging and deleted soon afterwards. Users will complain about those 
> drivers that are really still required. Those might be worth to spend 
> effort on.
> 

That strategy is not going to find out what functionality is required. 
Instead it will find out which beneficiaries are capable of overcoming all 
of the hurdles to reverting deletion:

 - Find out how to report a regression correctly.
 - Gather all the necessary information.
 - Obtain buy-in from a sympathetic developer.
 - Build a patched kernel, test it and provide the results. (And possibly 
   repeat the same until neglected code becomes accepted.)
 - Wait for the relevant distro to release the relevant kernel update. 

Developers tend to overlook the burden of process because it's ostensibly 
done to raise code quality. But it seems to me that affected users are 
more likely to seek a workaround than undertake the process.

So deletion doesn't discover end-user requirements. What it does is 
advertise a vacancy for an unpaid adoptive maintainer, somehow presumed to 
be found amongst a very well remunerated and very small pool of talent.

The way I look at it, the maintainence of old code is the price of a 
so-called "right to repair". But there ain't no free lunch and if we want 
that right we should seek ways to reduce that price. For example, by 
making a larger talent pool more effective, by re-using more code and by 
improving the tooling and automation.

The code I'd delete first wouldn't be a small amount of old code in need 
of sponsorship. Or even the most buggy code. The first to go would be that 
code which will never find an actual end user because some portion of the 
code required to actually use certain platforms was never mainlined by the 
vendor -- and never will be without some push-back.