On Wed, 2022-04-13 at 01:03 +0000, Peter Stuge wrote:
Martin Roth via coreboot wrote:
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.
I disagree, since a new name doesn't affect the points I make.
Trying to reframe even risks detracting from the actual argument. It has a taste of whataboutism.
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...
Thanks for the link. A quote: "Framing is the art of communicating such that one’s language activates particular unspoken ideas and associations."
That could certainly help in political contexts where it may be undesirable to communicate matter of fact, to not reveal true intentions.
But I don't think that's something to strive for in open source projects, where my goal is transparency and determinism.
Every time coreboot says that some platform is being "deprecated", it starts an argument.
That's not because of the wording, but because of the foreseeable consequences of the action known as "deprecate" or "move to branch".
I'd really like to avoid that argument.
Let's see what we can achieve.
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?
Code not in master eventually requires duplicated engineering to reuse desirable bug fixes in master.
That's a degradation, since duplicating effort is less efficient.
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.
That's an interesting argument. Whether it holds true depends on the particular changes. I understand now that both you and Michael are very test-focused, which explains why you feel that untested code is per definition second class. I view that differently.
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.
IBVs have tried that model, it eventually results in one branch per board, essentially a completely silo:ed situation, with reuse across branches approaching zero over time.
Do we agree that such a situation is undesirable in coreboot and really any open source project?
IBVs also try to keep everything that "might be needed in the future" and most of that code is just broken. Also see Intel reference code etc. It's a mess af.
In companies that generate revenue each time the same change is implemented in another branch the silo model is profitable, but we don't have that driver in coreboot - here I view it as wasteful duplication of already-scarce labour at best and malicious at worst.
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.
I completely disagree with this paragraph.
Branches are second class because as they diverge over time (which is their purpose) reusability approaches zero, value for consumers follows that directly and so does the likelihood of future investment into the branch.
Deprecation of the code in the branch becomes a self-fulfilling prophecy.
Because this is very predictable there's pushback each time something is being proposed for deprecation AKA move to another branch.
Every time it reduces the value of engineering that has gone into coreboot in the past.
I think everyone understands that there's a tradeoff where such reduction in value can be offset by a significant increase in value which can't happen until the code is moved.
I ask that such increase in value must be demonstrated before code can be moved off master.
If there's no clear benefit then I disagree with moving something off master, especially based merely on a lack of test datapoints or because current project contributors can no longer buy the hardware.
Taking action because there *isn't* any data seems the very opposite of a scientific approach - not something I think we want to do, right?
And this is the difference between science and development...
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.
To me, that's a fallacy and a trap.
With git, a "stable environment" can be created at any time and point. Anyone can create a branch as they require, when they want.
But once code is moved off master reuse of changes on master will eventually become impossible and there's no good path to recover from that situation, so it should be important to avoid such dead ends for any code we want to stay usable - IMO all code.
(Again: If there are actual source code issues with platforms then that weighs a lot heavier for me than mere lack of testing.)
How would you "reuse [] changes on master" on a platform, where these changes can't be tested? o.O
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.
Ah! I want as much code as possible to be usable as far into the future as possible. Being used today or yesteryear doesn't matter to me, guarding discoverability and the opportunity to use it later while benefiting from work done for completely different targets matters much more to me.
This my philosophy is clearly different from that of someone focused strictly on the next product coming to market, for them the only thing that will matter is right now.
But I don't invest effort into open source merely for right now, I think that's a waste of time since product lifecycles are so short.
I can understand that someone focused on right now is keen to "declutter" and move anything that doesn't seem immediately relevant.
That's fine in a private repository for a private project, but I have a fundamentally different mindset within open source.
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.
It can, but without evidence that's just as hypothetical as the code continuing to work fine. Mere absence of data isn't a reason to make any change.
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?
Ah! No not run time issues, but source code issues causing problems with other code in the tree. These are, as I wrote, trivial to manufacture if desired, but maybe that's a fair threshold.
No, it is both about runtime issues and code issues like "can't merge a change that affects multiple platforms because one platform can't be tested". You won't get in an untested change.
Kind regards
//Peter _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Michael