TL;DR: If someone wants to deprecate older code then *they* have to first balance any compatibility debt introduced by the newer code.
Anything else incentivises a race to the bottom; to move fast and break things. coreboot IMO neither wants nor needs that.
Patrick Georgi via coreboot wrote:
With all due respect, dropping support for the majority of AMD boards
Dropping support for hardware has never been the primary purpose of deprecation plans,
I think the difference is unimportantly subtle; deprecation is formal intent to (eventually) drop.
Deprecating code that not only provably works on hardware but is in fact *our only* code that currently works on the hardware IMO falls between lazy and malicious, in any case far from good practice when considering the future.
Our classic tension between private interests and the public good will not diminish over time unless everyone invests towards that goal. The Linux kernel is a perfect example of what happens otherwise, it's certainly nothing to strive for.
I consider Arthur's argument about maintenance burden to be based on the false premise that newer code is per se more valuable than older code.
If only considering hardware running the newer code with tunnel vision I do understand such an attitude, but to me a hard requirement for such a premise is that the newer code is a drop-in replacement - only then is it prudent to speak of deprecating the older code. If it's not compatible then the new code obviously solves a different problem.
It's of course too late to enforce drop-in compatibility once new code has been accepted into the tree, but the desire for deprecation such as this is a good opportunity to pay back what I consider compatibility debt in the new code.
Accepting an incompatible new implementation fails to create the incentives required for medium to long-term codebase stability. It would be wise to start repairing that culture deficit right now.
I find it completely unacceptable for someone working on something new to push a workload of forward-porting onto people who have no relation whatsoever to that new effort, but I'm sure it's a fun power trip. :) Please be more mindful than that. I've of course also made mistakes, but I try to always improve.
If companies are unable to invest in creating open source firmware for the public good then please think about whether you really want to be known for introducing compatibility debt.
If companies are able but merely unwilling then please be honest about that and do not bother others with your code, you should maintain it locally then.
No progress can be infinitely better than "wrong" progress, and therein lies the challenge for private interests in projects for the public good. A strange game!
Kind regards
//Peter