Hi Peter,
On 28.11.21 02:44, Peter Stuge wrote:
TL;DR: If someone wants to deprecate older code then *they* have to first balance any compatibility debt introduced by the newer code.
sounds fair. However I have to ask, do you see things are unbalanced? And in what direction?
Taking the allocator case for instance, there is zero compatibility debt introduced by the new code. All the debt is within the code of the deprecated platforms, which is neither compatible to the old nor the new allocator code. It's just buggy. Always has been. Changing core coreboot code just makes this more visible, and to me it seems fairer to deprecate broken code than to pretend that it's working.
Overall, all the cases of dropped platforms that I can recall are of this kind: Somebody pushed their code upstream and then they or somebody relying on the code tried to get their bugs fixed for free by coreboot maintainers. IMHO, this is heavily unbalanced and depre- cation are a means to fix that.
Anything else incentivises a race to the bottom; to move fast and break things. coreboot IMO neither wants nor needs that.
Sounds right. But I guess you assumed things are unbalanced in a different direction than they are :)
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.
No, not unconditionally and definitely not eventually. Their is always hope that somebody tries to fix the platforms that rely on deprecated code.
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.
tl;dr that code works by coincidence is not enough to ask other people to maintain it.
You may not have read the code of the platforms in question. I did and IMHO, if anything is malicious then it's having such broken, impossible to maintain code in our tree. Looking at the code, I have to assume it was added with minimum effort to write sound code and maximum debt. People have worked to fix it and clean it up for years and it's still in a (IMHO) horrible state. Pushing such code into the tree "falls between lazy and malicious". Asking to keep such code without the intention to fix it, too.
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.
What's the public good in this case? Isn't it for the public good when people like Arthur continue to support projects like coreboot? You seem a little too biased towards existing code, but what about new code? Is there no public interest in new code?
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.
Ok, your are free to consider it like this. But I can tell you it's wrong. IIRC, all the deprecation up to now were in favor of code that turned out to work best for all sound coreboot ports. Of course, new code doesn't always work well for ports that only worked by coincidence with the old code, and there's the burden. Who's responsible to fix code that was added in a poor state? The original authors? the people who rely on it? or the people who want to continue the project?
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.
Again, the incompatibility burden is usually not introduced by the new code. What you say seems generally true, but you are blaming / talking to the wrong people. It's not what is going on in this project.
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. :)
I find it completely unacceptable for someone adding broken code to push a workload of fixing onto people who have no relation whatsoever to the platforms in question.
Not sure how you can say such things with a smile.
Please be more mindful than that. I've of course also made mistakes, but I try to always improve.
Well, please try in this instance too. It feels very awkward to write this. It seems you are blaming people for things they didn't do and support people who pack all the work on the former's backs.
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.
Companies? So far it has always been a community effort to deprecate and companies objected. Not always, but often, code is maintained in our tree in the interest of companies. And such deprecation is our only means to keep breathing under the burden.
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.
What are you talking about? It seems you got everything backwards :(
Nico