On 4/21/21 8:33 PM, Patrick Georgi via coreboot wrote:
Hi everybody,
Hi,
In our leadership meeting[1] we discussed how we should deal with tree-wide changes (ranging from "new file header" to "some API is gone now"). The concern was that right now, anything can change at any time, making local development harder.
I already added some comment on gerrit: https://review.coreboot.org/c/coreboot/+/52576/comment/4033eba1_56d6eab5/
There have been a few ideas but nothing definite yet:
One idea was to declare some interfaces (e.g. those used by src/mainboards/**), with varying stability horizons (e.g. "only change right after a release"), or backward compatibility guarantees (although the details still seemed hazy on how that could work in practice.)
Initial point was related to long term development on fork, but based on changes proposed by Patrick I wanted to rise other concerns.
Any guarantees should have some anchor e.g. in release version. At this point we all agree that release points of coreboot are chosen arbitrarily and provide no quality or API compatibility guarantees. Despite it is clearly stated in documentation out of community not many people know that.
From embedded systems consulting perspective, and we faced applications of coreboot in e.g. trains or medical robots, long term support and some API compatibility is needed. Cost of massive rebase of patches from some old, or sometimes not so old, version may be not feasible - that's how some customers may get back to IBVs.
What worries me is that dislike of backward compatibility and easiness of throwing away "redundant" baggage of code that blocks tree-wide changes makes coreboot harder to maintain for long run in some applications.
This is one part of the problem, other is specifications compatibility where ACPI is one that breaks things often. coreboot moves with ACPI compiler faster then most of BSD systems, what lead to problems with BSD-based firewalls.
Another idea brought up was to require that such changes come with documentation and, ideally, migration support in the form of scripts and the like. We had something like this in the past[2] and I created a proposal[3] to establish it as a rule and build a culture around documenting sweeping changes.
Flag Days looks like good idea it essentially can work as guide where to look for problems, if firmware do not behave the same after set of tree-wide changes or if we have to rebase old fork.
Right now committer of tree-wide change applies proposed modification to whole code. This is done without any hardware test as well do not require all maintainers to confirm the change. I'm not sure if any of those changes required code development from maintainers. It seem that community agree to that approach or treat that as necessity. Maybe those de facto standards should be also written down?
One doesn't exclude the other, and there may be other approaches on how to make development easier without calcifying our codebase. Or maybe people don't see a problem that needs fixing?
What about announcing this changes before release and while those kind of changes are released giving option to still use older code base by config option (this may be classified as calcifying)?
If config option is to extreme then maybe one release notice period, like with platform drop, of switching API would be good enough?
In any case, I wanted to bring it up in a larger forum to make sure that we find rough consensus across the community before a decision is made on how to proceed here.
Best Regards,