# 2024-06-12 - coreboot Leadership Meeting
## Attendees Werner Zeh, Matt DeVillier, David Hendricks, Mina Asante, Jonathan Hall, Martin Roth, Felix Singer, Felix Held, Nico Huber, Jay Talbott, Rhys Perry, Karthik Ramasubramanian, Shelley Chen, Nicholas Chin, Ron Minnich, Mike Banon, Julius Werner, Marshall Dawson.
## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy
* COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing
* OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io
* OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit
## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 2024-01-10 * Nico: [https://review.coreboot.org/q/topic:enforce_region_api] * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [Felix S/Martin] We’ve got a OSFF booth accepted for [FOSSY conference](https://sfconservancy.org/fossy) * 1st - 4th August * Looking for volunteers to help with the booth. * Please reach out to FelixS or Martin if you’re interested. We might be able to help out some with travel or hotel costs.
### [Martin] Infrastructure * We need additional people to help with coreboot infra. * Using NixOS for the base OS * Docker images for gerrit, jenkins, other services. * Reach out to coreboot leadership if interested. * Felix will be the infra lead, but if we can’t find people in the community, we may need to hire someone (some company) to help with this. * Obviously this will cost the project cash * [MattD] We need a backstop, even if we have volunteers, so hiring a company would probably be good anyway. * If any or our contract companies have recommendations, please suggest good companies.
### [Elyes] Add lint rule to avoid duplicated includes. * I’ve added some lint rules to warn when a header is duplicated through another header which is supposed to provide it. (see [https://review.coreboot.org/c/coreboot/+/81907]) The rules I’ve used are those in: ``Documentation/contributing/coding_style.md`` As per Nico’s comments, we need some rules (if this is something we want to do.) * Headers can still be included in other header files. * [Martin]: This is (or should be) just enforcing what’s already documented in the coding style document. If this is a bad idea, let’s remove it from the coding style and not have a conflict between what we’re willing to enforce and the coding style guide. * [Nico]: This could make updating headers more difficult. * [Ron]: This seems like a slippery slope - do we want to alphabetize the header list? Christmas tree header list. * Those aren’t how we do things here. No required alphabetization or other styles for headers. * [David]: IWYU may make things fragile. Good in theory, if it's easy and reliable to use/enforce then we should do it. * [Julius]: The coding style wastes reviewers time. Do we really need to worry about this? * [Martin]: This patch would fix that. * [Nico]: Do we want to just prohibit bulk cleanups? * [Martin]: Does that mean we should get rid of the coding style? If we’re not going to enforce it, why have it? * [Nico]: it’s good for new users. * [FelixS]: could IWYU be used instead of self-written scripts to supply suggestions? * [David]: Maybe we should roll this out slowly before enforcing it. Hopefully this won’t introduce a bunch of Diffs. * The work is already done, so let’s prevent new style violations from going in. * [Martin]: Can we agree that we can submit this and if it causes issues we can roll it back? * [David]: We shouldn’t block it unless we can articulate exactly why it’s a problem. Let’s think about it for a week and if there aren’t any explicit issues, then let’s merge it.
### [Yidi Lin] [Do we consider GPIO ball names definitions in <soc/gpio.h> as part of <gpio.h>](https://review.coreboot.org/c/coreboot/+/82813/1/src/mainboard/google/kukui/...) ? * This is related to the above header issue. * Listed in the style guide as an example * [Nico]: These two gpio headers aren’t really the same thing. One is hardware, the other is the general function headers. * [Matt]: Does the main GPIO.h automatically include soc/gpio.h? * Felix: Yes, and includes the IWYU annotation that it should be supplied. * [Matt]: As long as we’re being consistent across the codebase, it should be fine. It looks like we’re normally including soc/gpio.h in mainboards. There are currently 364 instances of that - so let’s not change it to comply with the style guide. Let’s update the style guide and update the patch. * [Julius]: Let’s just leave things as they are and not do bulk updates. * [Jonathan]: This seems like a misinterpretation of the style guide - it’s saying that you don’t need to include both. It doesn’t seem to say that you should use gpio.h instead. Let’s edit the style guide to clarify this.
* **Decision**: Let’s just edit the style guide for clarity and not force inclusion. That means that we’d drop these patches (unless the board owner prefers it.)
### [Felix H] Usage of LLM outputs making the commit messages bad * I’ve seen commit messages (patchset 2 of 82871, 82872) that look very much like output from some LLM that say little in much text and I’d very much prefer that we keep commit messages concise, so I’d like to discuss if we want to allow usage of LLM output and if so how we should make sure to mainly get possible advantages of that but keep the disadvantages to a minimum * [Martin] Yes, I think we want to allow the output from LLMs in patch descriptions, in fact I was just talking about creating some automation to generate a description of the patch that could be (optionally) used to update the commit message. People who are less fluent in English could really benefit from this. * [Martin]: Let’s just say that commit messages should be concise and related to the patch.
### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tUN5bLR2ci...) Look at the document for reasoning. Please review it and make comments. * [Martin]: I kind of hate the idea of loading firmware from the drive for stages before the payload - this feels like a slippery slope and that next we’re going to need network drivers in coreboot to support loading the firmware over the network. Payload can do what it wants. * [David]: This sort of thing is pretty normal in the non-x86 world. * [Werner]: The mass storage device is really owned by the OS. If the firmware is on the drive, we could break the boot when the drive is formatted or replaced. * [Karthik]: only boot critical components would be moved to the disk. * [Martin/Felix]: This seems like a large security hole - your system can be owned from the boot firmware instead of just the OS. * [Julius]: This is just extending cbfs to the disk and not a part of an OS file system. This is mainly intended for CSME update. This would be only Ramstage or later and would be optional. * [Werner]: Requires adding mass storage devices. Allows coreboot to read the entire disk. How does that affect security? * [David]: Let’s assume that Google didn't screw up their implementation, and focus on how this would fit into upstream or if it should be blocked. It seems like it could be an advantage for cost savings (as Julius points out) by making it so laptop vendors don't need a huge flash chip for things like CSME binaries. * [Martin]: This needs further discussion, so please review the document and make comments there. In general I feel like if something is needed by some coreboot users, we should try to be accepting of their needs (assuming that it’s not adding additional binary blobs.
# Next Leadership Meeting * June 26,2024. * [coreboot Calendar](https://coreboot.org/calendar.html).
# Notice * Decisions shown here are not necessarily final, and are based on the current information available. If there are questions or comments about decisions made, or additional information to present, please put it on the leadership meeting agenda and show up if possible to discuss it. Of course items may also be discussed on the mailing list, but as it's difficult to interpret tone over email, controversial topics frequently do not have good progress in those discussions. For particularly difficult issues, it may be best to try to schedule another meeting.
# coreboot leadership meeting minutes *[2024-06-12](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...).