2025-02-05 - coreboot Leadership Meeting Minutes

# 2025-02-05 - coreboot Leadership Meeting

## Attendees

Felix Held, Jay Talbott, Julius Werner, Andy Ebrahiem, Martin Roth, Maximilian Brune, Matt
DeVillier, Christian Walter, Andre, Mina Asante, David Hendricks, Alicja Michalska, Jon Murphy,
Jeremy Compostella, Elyes.

## Open Action Items

* 2024-11-27
    * Send out poll with regards to  LLM usage (requested by SFC)
  * 2024-10-30
    * Add clarification to docs, “do not use gerrit change-id or CB: format in reference to already-merged patches.”
  * 2024-10-16
    * Matt: Set up a meeting to discuss board status alternatives and send out invites. 
      * Decouple data collection with uploading
      * Require gerrit credentials or other auth to push
      * Json format?
      * https://github.com/chrultrabook/linux-tools/blob/main/debugging.sh
  * 2024-09-18
    * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan.
      * Werner: Send out an invite for the meeting. 
        Sent out a poll to find a time slot: https://rallly.co/invite/1c8J3azXAcje
  * 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

### [Elyes] coreboot toolchain and/or Jenkins malfunction
  * There is something wrong with the coreboot toolchain and/or Jenkins. Here,
(https://review.coreboot.org/c/coreboot/+/86100), I'm expecting the build to fail, at least getting
this error: "error: initializer-string for array of 'char' is too long"! 
And here, (https://review.coreboot.org/c/coreboot/+/86012), it looks like Jenkins is mixing GCC
versions! So, what is the plan?
    *  I can understand adding support for a library that can be used by coreboot, as seen
here(https://review.coreboot.org/c/coreboot/+/80737), but I'm having trouble understanding the
purpose of adding LIBSTDCXX. Unless I'm mistaken, this library is not used in coreboot.
What is the strategy of coreboot after this add and that of 'go' here (https://review.coreboot.org/c/coreboot/+/63639)?
    * To give some more background:
      * During the creation of the patch there was talk about the US government making SBOMs mandatory at
some point (not sure what the current status is).
      * The go dependency was already there although to be fair it was only present in tooling
(intel-sec-tools) as far as I know. We had multiple long talks (also in the leadership meeting)
about adding go as a dependency into the coreboot build system. As far as I know we agreed on
letting it into the coreboot build system because it was an optional dependency.
      * We worked with [https://fwupd.org/%5D(https://fwupd.org/) together to facilitate SBOM as part of
Firmware updates. More specifically you can see SBOM information on their web interface when you
look at the Firmware updates. I haven’t looked at it for a while now, so I am not sure about the
current status.
      * Isn’t that only an ABI for aarch64? According to the content of the patch it is removing the
riscv abi (although the title mentions aarch64).
      * Rv32 is used by one of our emulation targets (src/mainboard/emulation/qemu-riscv)

### [Martin] Someone mentioned that GitHub isn't being synced anymore.
  * Felix S. already handled this? Need to double-check.

### [Alicja] Release notes status?

### [Martin] Adding IT support (reducing the "bus" factor)
  * Need someone knowledgeable in NixOS and our infra (Jenkins, Gerrit, Docker, etc)
    * Max has a potential candidate who can help.
    * We're happy to use some coreboot funds to do admin duties and document everything.
  * [Max] Toolchain is a significant maintenance burden. There are other projects out there, maybe we
can utilize another project's toolchain (or merge?) so we don't shoulder the entire burden.
    * [Martin] For now the plan is to just split it into a separate module. We only update the
toolchain 4x per year, and probably don't need to do it that often.
      * Splitting would allow us to test it separately from coreboot. We do toolchain builds but don't
stress test the toolchain itself beyond "does it build?"
      * Splitting would make it easier to update - if people want more frequent updates, then that would be fine.
        * [Jon] This is also what ChromeOS does, for the above reasons.
  * [Max] Do we want all of our payloads to compile using coreboot's toolchain?
    * [Martin] We can try this out to see what's needed to support different payloads.
    * [David] It's nice, but not required. When we started LinuxBoot, we were using the coreboot
toolchain since ARM64 was one of the early targets and doing the usual cross-toolchain setup was a
pain outside of coreboot.
    * [Martin] Will look at adding build tests in Jenkins; can't promise to fix anything.
      * Having the latest working toolchain version is valuable info, even if the more recent toolchains fail.

# Next Leadership Meeting
  * February 19, 2025.
  * [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
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...