Apr 12, 2022, 12:14 by f...@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-elephant/
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
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
