Apr 12, 2022, 12:14 by foss@mniewoehner.de:
On Mon, 2022-04-11 at 22:23 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
1) Please don't use the term deprecate - use "moved to a branch"
I don't think the wording matters, my points are discoverability and drive-by maintainance.
Yes, wording matters. Opinions are changed in politics by just reframing the argument all the time. If you really don't think that wording matters check out this article, and the book that it's about: https://commonslibrary.org/frame-the-debate-insights-from-dont-think-of-an-e...
Every time coreboot says that some platform is being "deprecated", it starts an argument. I'd really like to avoid that argument.
If a platform is perfect and doesn't need to be updated, it doesn't need to be on the master branch, right?
I think wrong, because being on master is the only chance to receive tree-wide changes, e.g. through coccinelle spatches or sed:its.
Missing those rots the code quicker so yes, something getting moved to a non-master branch is de-facto deprecation by degradation to second class.
How can it degrade if it's not being changed? Older platforms that aren't being tested regularly stop working *because* they're in the main branch, receiving lots of code changes without being tested. By moving them to a branch, they're less likely to get additional breaking fixes. So allowing them to be maintained on a branch is much better for stability.
It's absolutely not second class either. If people understand that the older platforms are maintained on these version branches, they can be worked on there without having all of the changes on newer platforms to deal with. It's a matter of getting people used to working on those older branches.
Maintaining without ability to test will make it degrade, too.
Exactly. By moving it to a branch, if someone wants to work on a platform, they can do it in a more stable environment.
I absolutely agree that if something isn't being used, it doesn't need to be maintained on the master branch.
I disagree.
Ok. Any reason why? I don't understand why would we want to maintain something that nobody uses on the master branch. If it's not being used, it can just as easily not be used on a release branch as the master branch, and then we don't have to continue to try to maintain it as the rest of coreboot moves forward.
I just want to make sure that things actually aren't being used before moving them to a branch.
I think "no usage" alone should be a very weak motivator to move something from master, just like "no availability".
(Many SOCs are currently unavailable and will remain so for some time!)
Why It's not unavailable for *some time* but forever, bc it's not being produced anymore.
If code is perfect or nearly perfect then why move it?
Even if the code was "perfect" when it was written, it doesn't exist in a vacuum. As the rest of the coreboot platform changes around it, the perfect code can stop working.
If there are *concrete* issues with code then I think it would be reasonable for *that* to count much more than "no/unknown usage", but the current proposal did not reference any such issues, Paul's ask didn't yield any and neither did mine.
Not used => not tested.
And how do we know whether or not there are concrete issues with it if it's not being tested? Thanks for the discussion. Martin