Attention is currently required from: Martin Roth, Julius Werner, Felix Held. Piotr Król 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/8ef235f6_8a663929 PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
Well, for Chrome OS firmware branches specifically, the kind of broad API changes we're talking about here usually *shouldn't* be backported. That's kinda what I was trying to say in my email as well, if you're trying to stabilize for a product you shouldn't *want* to keep pulling in every new hot-off-the-presses development from master. You should sit back and only take bug fixes relevant to your platform.
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?
Of course there should be budget to maintain code up to that point, or pay enough for significant backport. Right now we evaluate effort, if we backport or somehow hack similar fix on branch. Sometimes it happen that customer decide to stay with old code, it maybe doesn't matter much for 10k+ employees corporation, but for 3mdeb it is smaller market. It is also bad marketing for coreboot since OEMs spread the word about costs of coreboot maintenance and choose alternatives.
There is also other perspective, where customer may want some release since end users push them for that. So customer didn't paid for maintenance for some time and we have to deal with massive rebase. At one point rebase will cost N, on other 2x N - in that way it is harder to provider stable maintainership services and convince customers to keep upstreaming their code and provide newer version of firmware.
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 believe in Linux situation is way different because in additional to huge players there is whole spectrum o medium and small one. In coreboot we have huge players, small players and community.
Consider: Even if a vendor doesn't intend to upstream, they still have to provide their sources to their customers (thanks to the GPL). Helping those customers upstream such custom development can go a long way to help bring separate lines of development back "home".
That sounds like an incredibly unlikely scenario to justify extra churn, though. After all, all this is trying to do is trying to safe the integrator of those extra out-of-tree patches some effort. It only makes sense when the net effort saved will consistently be higher than the net effort spent. I really doubt "on the off chance that someone finds some third-party non-upstreamed tarball release somewhere that they then want to upstream" happens often enough to make it worth doing this for every SoC.
It is not so unlikely it is about convincing customer that keeping up with upstream is cheaper, then figuring out after some years they have way outdated firmware for their successful project and cost of rebase is way bigger then regular updates.
P.S. 10k+ employees corp vs small entity IMO largely define point of view and it would be great if whole discussion would go to some consensus making coreboot place for everyone not only for biggest or those who got contract with the biggest.
-
Piotr Król (Code Review)