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
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to