On Tue, 2022-04-12 at 23:22 +0200, Martin Roth via coreboot wrote: > > > > 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.
Agreed. > > > > > > 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. Exactly that is the point. Without any testing the platform *cannot* be maintained (as in "make sure it is still usable"). It's like wanting to keep your pet "alive" by stuffing it. Erm. Sorry for this unlovely example... I just feel it fits very well... > > > > > > 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 Michael _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
