# 2024-08-21 - coreboot Leadership Meeting
## Attendees Martin Roth, Maximilian Brune, Werner Zeh, Nico Huber, Felix Held, Jon Murphy, Jonathan Hall, Karthik R, Matt DeVillier, Julius Werner, David Hendricks, Ron Minnich, Felix Singer, Mina Asante.
## Announcements & Events * 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-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
### [Martin] coreboot relies on VBOOT, but the API isn’t stable. Currently we can’t build coreboot without vboot at all. How do we want to handle this? * [Matt] For the majority of chromebooks, vboot is used in downstream builds, so has become a requirement. However one can’t update just the RW portion because the API has changed. You’re basically committing to a single version of coreboot & vboot when you create an RO. * Do we want to fork VBOOT? * This would create a number of issues * We can have multiple versioned VBOOT submodules. * Create a new VBOOT submodule version * Can we create submodules based on the final patch of vboot version * Julius: The real solution is to fix the board. * Can Google help us to specify and stabilize ABI versions? * Julius: coreboot has this own issue itself - When we update the car layout for example * Jon: Just because there are issues in one area doesn’t mean we shouldn’t try to fix it in other areas. We can look at fixing the different areas individually. * Julius: This would halt progress if we can’t change things. * Martin: we’re not saying that we can’t change things, just that we draw a line when we do change things. * Jon: Things should try to be backward compatible. * Julius: This isn’t a vboot problem - it’s a coreboot problem in general. * Jon: This is at least a starting point. * Martin: VBOOT is *AN* issue, let’s take issue one by one. * Julius: There are too many issues, and it may be a waste of time to try. * Jon: Let’s try to draw a line - we won’t fix everything, but let’s try to create mechanisms. We can at least try to separate coreboot & vboot. Let’s write a design doc to deal with this. * Julius: We’re already working to encapsulate vboot. It’s a more realistic goal to try to hold any breaking changes to a certain time. Keeping things stable for a year isn’t realistic. * Werner: Has google run into this? How does google handle it? * Julius: We cut a branch and ship any updates from the branch. * Jon: i’m not suggesting an annual roll. Just giving a year to come up with a plan. The current google method is problematic. This change would help both google and the community. * Martin: We can do quarterly releases of breaking changes like we do with toolchain updates. * David: Can we break the build when there’s a backward-compatible breaking changes? Google can create branches for porting features and test all their products, but upstream cannot. Our goal upstream is to avoid breaking boards in the upstream main branch, so it will help to signal to our builder that something is broken so incompatible boards can be removed. * Martin: It’s more of a boot test than a build test. The new RW wouldn’t be backward compatible with the old RO. * Werner: what breaks? * Matt: Basically the structures are no longer compatible. Changes to the major and minor versions will halt the boot. We want to avoid having downstream dependency break upstream coreboot. * Jon: Software versioning is an industry practice. Why can’t we update vboot for backward compatibility? Disable features that aren’t compatible. * Julius: The CAR stack size for intel was incompatible. To be compatible, you have to add asm and move things by the exact amount. This would be very early. For the AMD board, can we just update a new signed verstage? * Matt: Yes, we just got a new update. There was a 2 year period where things were broken. * Martin: we can add a check in the CI to make sure that an update to the vboot version number breaks the build. This would make sure that people are notified and new signed verstages are published. * Martin: Let’s work towards marking all backwards breaking changes.
### [Martin] We had a meeting with the SFC last week. * We currently have over $70K in the bank and our current expenses are around $20K per year for the server infrastructure. * We should again look at how we want to spend this, and who is going to manage the projects spending the money. SFC will help in this process. We’ve agreed that we (the coreboot project) do _not_ want to pay anyone for writing patches. * Some thoughts we’ve had for our needs in the past: * someone to do documentation * someone to help with reviews * a community manager (Mina is doing parts of this job now, but the job could be expanded significantly.) * Update the website SFC will help with a fund-raiser. * Currently, our main supporter is Google, who has donated $50,000 over the past two years. * [Jon Murphy] Google is willing to contribute more, but requires written justification. I can request $25,000 this year, but need to write a one pager on what it’s used for. Can I get help? Can the community take this action and include me [Jon Murphy](jpmurphy@google.com) * Martin will write something up as to what we want to use this money for. * If we’re actively spending the money, especially on salaries, the money goes fast, so we should look at * What should our priorities be? * MattD: A website is probably the first item. * Werner: This doesn’t need coreboot expertise. * FelixS: Documentation and a website. * Max: For documentation, we’d really need someone who already knows coreboot * Martin: My thought was that we want a tech writer who can learn the coreboot project. * David: Agree with Max - documentation tasks would have to be scoped to be very high-level for this to work. * Matt: We can separate this into 2 parts: the project documentation and the implementation/developer documentation. * Ron: Documentation needs to be structured as something ongoing. It’s typically out of date as soon as it’s written. * Max: Agreed - we have breaking changes and updates. * Martin: Right - we want to have a writer who keeps updating things. * There’s a stringent process on how to hire people. There’s a bidding process and a lot of rules. * David: We may have legal expenses - there’s a company using the coreboot logo without supporting coreboot, and have a generally terrible reputation. Not sure if legal funds come from SFC's 10% or if that would come from our budget.
### [Werner] Intel asks for feedback from the open source community on how open source is received. * They currently have the opinion that open source isn’t worth it and base it on their experience with EDK II. * Werner: We have meeting with intel, where we ask for more open source. Recently we had meetings where there was friction. Intel tried with edk2 and don’t see that it works. Offered to ask the community about why edk2 isn’t a good example. Why did it fail, and how can things be done better? * Ron: Clearly open source works - they’re a big contributor, but you can’t just dump anything out there and expect it to work. Edk2 is viewed as being a dumpster fire. * Werner: This comes from the firmware group * Nico: Continue the comparison with the linux kernel. Edk2 is completely different. It tries to be internal binary compatible. * Werner: it’s not that the code is bad, but the way it’s run * Matt: Trying to upstream into edk2 is very difficult, moreso than linux. Patches stagnate, hard to get code reviews. Dev process is difficult. Sean has had similar issues. * Ron: There is an open source culture and EDK2 hasn’t adopted it. They don’t accept change well. * Max: posted link to blog post. EDK2 is more closely linked to closed source. coreboot is different because it’s based on open source. We don’t upstream to edk2 because it’s too difficult. * [https://blog.aheymans.xyz/post/uefi-coreboot-comparison/] * Werner: is there a community around the EDK2 project * Max: Yes * Werner: Can I set up a doc to further the discussion? [Feedback on EDK 2 as open source project](https://docs.google.com/document/d/1P3GLpCufykSID1MjhSU47wI7nM-Jgbc9JtnoQY9s...) * Feel free to add your thoughts on this into this doc and share it with whomever is interested in being part of this discussion. * Max: May accept github PRs now. * FelixS: Did intel give any reasons why it failed from their perspective? * Werner: not yet. * FelixS: My thinking is that theirs is currently an empty statement to prevent any further discussion. * Ron: Big question is what’s in it for you? They failed at open source, it didn’t fail them. * Werner: I don’t want to pass up an opportunity and get blamed for it.
## INFO
### [Martin] Patches Review Meeting Feedback * The 2nd review meeting was Wednesday, August 15th. There was positive feedback again about the usefulness of the time spent. Reviewed ~15 patches. The feeling is that anything that we can review and get moving is to the project’s benefit.
### [Martin] Looking at uncrustify as an alternative to clang-format. * David: Search gerrit for uncrustify. We tried it on flashrom a while back and had some promising results, but it fell somewhat short. I'll be interested to see how you approach it.
### [Martin] Info:coreboot 24.08 Release * Release tag planned for Thursday. * Please mark anything you want to be merged with the hashtag “coreboot_release_2408”. * Mark anything that should be merged after the release with the hashtag “post_coreboot_release_2408”.
**Completed Action Items**
* [Done] Martin: Work on [clang-format config update](https://review.coreboot.org/c/coreboot/+/7883). * We can use the clang format version from the coreboot toolchain. * Some issues with clang format - martin will present. * See [CB:78833](https://review.coreboot.org/c/coreboot/+/78833) for what the current format’s changes will look like. * [David] #defines for bits in headers lose their indenting. Maybe we should have clang-format ignore headers for now. Smaller issues can be handled on a "use your best “judgement" basis. * [Done] Martin to add [bitfield example](https://review.coreboot.org/c/coreboot/+/78833/4/src/drivers/intel/gma/i915_...) to 78833 * Let’s look at running this just for .c files to start with. * [Done] PatrickG, FelixS, MartinR: Look at improving the responsiveness of gerrit. * This had a number of causes, mostly related to running out of storage, as well as both of the NVMe drives going bad. We’ve reduced the amount of data being saved by jenkins and replaced the NVMe drives
# Next Leadership Meeting * September 4, 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.