Attention is currently required from: Martin Roth, Piotr Król, 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:
(2 comments)
Patchset:
PS1:
i like the idea to document what interfaces and coreboot- or soc-level functions/functionality were […]
Hey, these are good points. Marking unresolved till we find a conclusion.
There are different lines we could draw: One that should be less difficult to define is generic (not SoC specific) code changes, e.g. changes in style expectations, changes in the resource allocator, ... As soon as a change affects two code for different SoC vendors, it _must_ be documented that way.
A similar approach could be used for SoCs level code: As soon as SoC level interface changes affect two mainboard vendors (e.g. Google and Purism), they _must_ be documented that way - at that point it's probably not at an internal development stage anymore (and even if they are, there's enough coordination overhead between all the parties that documentation is not a bad idea ;-) )
File Documentation/getting_started/gerrit_guidelines.md:
https://review.coreboot.org/c/coreboot/+/52576/comment/70e5bb79_640617b3 PS1, Line 327: keeping years of baggage around
From 3mdeb perspective I'm little bit worried how dramatically things change sometimes. […]
I think we can discuss any approach of "let's mark certain things stable and only modify them on some cadence and with heads-up notes", but the issue I see, and where we didn't get very far in yesterday's meeting, is how to identify things to keep stable.
That said, I think this is orthogonal to the "let's document what changed so people can follow up" approach listed here and can be done in addition to that. Maybe you could bring it up in the mailing list thread I started which has a wider scope?