Attention is currently required from: Martin Roth, Julius Werner, Felix Held. Patrick Georgi 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/fda4055f_e116a27f PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
I understand what this proposal is trying to get at, but as written this is completely impractical. […]
Would "the code has shipped on a product" be a good break-off point? At that point the quick iterations should be mostly over, and if there are multiple teams working on the same pre-production SoC[1] they better collaborate, for which upstream is a great place - any team trying to opt out of that should bear the costs themselves instead of expecting others to accommodate them.
However, once stuff is shipping and development for that platform has slowed down, any kind of rework of the code should be documented so that upstream changes can be brought into local stabilization branches (e.g. ChromeOS' firmware branches!) more easily, and local development branches have an easier time when it comes to upstreaming.
In Felix' patchset level comment I proposed "two different vendors" but that's actually not a good benchmark because even if a chipset is exclusively used by one vendor (e.g. Google) at the time, once it's settled down, I think we should document changes sufficiently so that external development can be brought in with relative ease. 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".
[1] or whatever component they share