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.
