# 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](jpmur...@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-Jgbc9JtnoQY9shys/edit)
* 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_reg.h)
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.
_______________________________________________
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
