Attention is currently required from: Martin Roth, Piotr Król, Felix Held. Julius Werner has posted comments on this change. ( https://review.coreboot.org/c/coreboot/+/52576 )
Change subject: Documentation: Add suggestion to document flag days ......................................................................
Patch Set 1:
(1 comment)
File Documentation/getting_started/gerrit_guidelines.md:
https://review.coreboot.org/c/coreboot/+/52576/comment/3d56d7bd_7f0ba299 PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
So, I misunderstood that. I agree with selecting stable point and integrating on top of that, but what should happen when you shipped product and once in a while (e.g. 1x/year) you getting request about fixing something?
You should backport the fix, I think. That's what we always do for Chrome OS. Thankfully fixes tend to be rather small and uncomplicated to backport most of the time.
Finally I didn't mentioned that, but coreboot does not build production firmware images, it is more like framework then something building images that can go to market. There is always some customer-specific diff that will not be merged upstream. That diff have to be maintained by someone (e.g. for PC Engines it is now ~4k SLOC), bigger difference more expensive maintanance.
I think this is your real problem tbh, and it's one of your own making. Why isn't your code upstream? Google had a downstream fork of coreboot for years, and we suffered immensely under the constant back and forward porting effort just like you describe here, until we eventually learned our lesson forced everything to be landed upstream first before we would ship it. I don't think that this is any "10k+ employees vs small company" difference, the effort is still the same, and the answer is just that working directly upstream is the only way to prevent all that churn. (Google may have 10k+ employees but they're not all working on coreboot, btw. It's more like 20 or so.)
-
Julius Werner (Code Review)