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/38883a32_a2a5f6a6 PS1, Line 332: requires a change in all mainboards using it) needs to be documented.
- Sign of life - certain string showing as early as possible on platform boot
Open to discussion but I think this might be reasonable as a Kconfig (depending on how complicated it looks).
- sortbootorder as payload - would payload supporting only one vendor will be merged to coreboot?
- Custom SeaBIOS features which SeaBIOS upstream won't accept - this is general pattern related to other payloads (memtest, ipxe), including customization and configuration of those payloads
Payload stuff I'd consider separate -- I think for payloads we already have an existing assumption that payloads don't need to be in-tree and that the payload interface is somewhat stable (of course, sometimes changes are unavoidable, but we could discuss more rules about how those should be communicated). So I think it should be okay if you uprev coreboot but keep your payload code untouched and expect them to continue working together most of the time.
- Experimental uCode inclusion
Is this more than just setting the microcode file Kconfig to some file you maintain out-of-tree? (I think that's considered supported.)
- ACPI difference, mentioned in email thread, required for OS compatibility
I haven't fully understood that problem, but generally, I think OS compatibility stuff is something that can be included upstream (depends on whether we're talking about a publicly available OS or something custom used only by your customer, maybe). Again, I think coreboot itself gets developed as a sort of monolithic blob with no stable boundaries on its inside, but the boundary between coreboot and the payload or the OS is different and we spend more effort trying to keep that as stable and widely compatible as possible.
Maybe we should be clear about saying that coreboot is too expensive for small OEM/ODM, they should go to IBVs.
I don't think anyone is trying to build any intentional barriers here to keep someone out. We're all interested in making all the things that people want to do with coreboot as cheap and easy as possible. I just don't think there are any easy answers to your problems here. "Everyone stop making big API changes" isn't something we can do, then we can't really develop big new features at all anymore. Then the project would basically become irrelevant and die out. "Spend a ton of extra effort on every global change you make" also becomes prohibitive and will effectively cause the same problems as forbidding big changes completely. I think we can discuss smaller effort process changes (e.g. writing spatches where it makes sense), but it needs to balance out the effort saved on one side and the extra effort caused on the other.
-
Julius Werner (Code Review)