Attention is currently required from: Martin Roth, 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/d2c8f4a5_0a19ec46 PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
Would "the code has shipped on a product" be a good break-off point?
Yes, for Chrome OS boards, but I'm not sure that's transferable to all coreboot developers. For the Facebook guys with their servers, for example, I don't know what a good cutoff point for them would be. I still think "once multiple independent parties say they are interested in it" for each SoC would be the best way to handle this to avoid a lot of unnecessary bookkeeping. (For a "single party", like Google and an SoC vendor collaborating on a new Chromebook, we usually just keep each other CCed in the actual patches as they go in, which is a much lower-touch way to keep each other in the loop.)
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!)
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.
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.
-
Julius Werner (Code Review)