# 2023-11-01 - coreboot Leadership Meeting Minutes
## Attendees Julius Werner, Jonathan Hall, Tim Crawford, Jay Talbott, Matt DeVillier, Jeremy Compostella, Wilhelmina Asante, Martin Roth, Simon Glass, David Hendricks, Christian (not 9e), Jon Murphy, Werner Zeh
## Open Action Items * [Open] Martin: Shallow submodules - document & test, then update submodules if testing goes well. Additionally look at whether the .branch option helps. * [Open] Martin: Note the slowdown of syncing the master branch to the 4.22 release notes - Updates are now weekly & branch will be removed at 4.23 release. * [Open] Martin: Send out an email to the mailing list about running devicetree.cb files through the C preprocessor to get feedback. * [Open] Arthur: Ask Philip about how to use company logos. *[Open] Martin: Write a document about vendorcode submodules. * [Prototyped] Martin: Create coreboot governance page * Please review and give comments. * [Started] MattD and WernerZ :Work on compiling a list of website requirements from the mailing list. * No feedback yet-MattD: To continue compiling feedback list of website requirements. * [Started] Martin: Write a tutorial for gerrit - Feel free to help. * [Started] Martin: Work on clang-format. * We can use the clang format version from the coreboot toolchain! * Some issues with clang format - martin will present. * See CB:78832 for what the current format’s changes will look like. * Martin to add bitfield example to 78832 * [Done] PatrickG: Slow down the updates of the master branch.
## Minutes:
### [Martin] Thoughts on enabling shallow clones of submodules by default? * [https://git-scm.com/docs/gitmodules/2.28.0] .shallow When set to true, a clone of this submodule will be performed as a shallow clone (with a history depth of 1) unless the user explicitly asks for a non-shallow clone.
* [TimC] Shallow clones means no git history. Would be good for CI and people who don’t need it. Related: Does/Can gerrit support partial clones? Treeless clones (--filter=tree:0) would be nice to have. They’re like shallow clones, but still have the git history. * [Martin] You’re spot on about not having git history in the submodules - by default. I believe you could still download the full repo manually if desired (I’ll test before implementing if the decision is to go forward with it.) I don’t see why gerrit would have a problem with it, but git submodules don’t support treeless clones, just shallow.
* [MattD] Are we already using a single branch? _AI: Martin to check._ This seems like a reasonable default - need to document how to change this. * What difficulties are there with this? Will we have issues updating during a build? * Will people need to update manually if going back to an earlier commit? _AI: Martin to write docs & test_
### [Martin] Slow down syncing of coreboot’s master branch to Daily? Weekly? * We want not using the main branch to start being a little painful, without completely breaking things yet. We’ll want to discontinue updates to master and delete it in a month or two. * [TimC] Handle it like boards/features are deprecated and do it at a release? e.g., no updates after 4.22 and removed after 4.23.
* [MattD] Slow the updates down to weekly, put it in release notes that the branch will be dropped at 4.23.
* [JonM] Remove documentation from the master branch and point to the main branch. * [Martin] Because of the way the branches are being synced, we can’t have any differences between the master and main branches.
** Decision: Slow down to weekly updates.** _AI: Martin: Add change from master branch to main branch to the release notes_ _AI: PGeorgi: slow down the updates to master._
### [MattD] Requirements for new website * Everything must be owned and run by coreboot - not an outside developer. * Everything must be contained in a git repo (outside of downloadable files like releases). * As much as possible should be generated statically. * Use a site-wide top bar for navigation? * Should look like a “professional” website. _AI: MattD: Mailing list & solicit feedback from other forums. (Just continuing from previous AI)_
### [Martin] Should we have a separate meeting to discuss coreboot RFC patches? * [https://review.coreboot.org/q/status:open+repo:coreboot+message:rfc] * [Matt] A separate meeting seems reasonable. Would we get more people if we had another meeting, or fewer?
* [David] Let’s try to do it in this meeting and go over one RFC each time. If we can’t get caught up, we can have additional meetings.
** Decision: Just try to do it in the leadership meetings.**
### [Martin] Clang-format update - show the pros & cons. * [clang-format: Update configuration for version 16+] https://review.coreboot.org/c/coreboot/+/78832
* Please take a look. Pain points: - Consecutive macros: Registers with bit definitions below them typically have bits indented to group things together. clang-format currently does not recognize this and will remove indenting of macros. - Bitfield handling: Martin says recent clang-format works much better - Martin: add example to CB:78832 - Structs where each member is on its own line (for example, a struct with UART baud rates) was a problem in earlier versions as well since clang-format would aggressively join lines. Maybe this is fixed.
### [Martin] 4.22 release scheduled for 2023_11_17 * 4.22 release checklist & meeting minutes (https://docs.google.com/document/d/1jElapZVmef2H6Gxs9QzdsHiiim-OpCHP6RjsGcLj...) * Release meetings run for 4 weeks starting this friday. See the coreboot calendar for details(https://coreboot.org/calendar.html). * Discussions happen on IRC in #coreboot_releases. * MattD will try to test platforms he supports before the 4.22 release.
### [Martin] RFC: util/sconfig: Add 'enable_option' keyword * This will allow a Kconfig option to be used to enable/disable a device * Do we also want a “disable_option” keyword that enables the device if it’s not set? * Should we just make a 2nd Kconfig option that’s set when the first isn’t? * [https://review.coreboot.org/c/coreboot/+/78604] * Jonathan: supports the idea.
* Julius: Let’s just run it through a preprocessor and make rules about what is and isn’t allowed. This is more consistent with how we handle other files.
** Decision: Look at using the C preprocessor instead.** * Simple #defines and #if type statements - no complex macros allowed. * Look back at the discussion from last year when we had the opposite decision. _AI: Martin: Send out a separate email to the mailing list for comments from all._
### [PatrickR] RFC on coreboot forms representation * [https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PX6WD... G5S/] * [https://review.coreboot.org/c/coreboot/+/77882/] * [https://review.coreboot.org/c/coreboot/+/74121/] * [https://review.coreboot.org/c/coreboot/+/78506/] * [https://review.coreboot.org/c/coreboot/+/78296/] * [https://github.com/9elements/edk2/commit/f34f17996444ef811cc0223b4f875c45daa...]
* Simon: In the spirit of cross-project collaboration, would it be worth looking at how U-Boot does this? It has a schema which can be loaded at runtime, rather than needing data in the C code (https://u-boot.readthedocs.io/en/latest/develop/expo.html#expo-format-exampl...) * Goal is to be able to have a setup engine. * Runtime or payload. * Would we need to implement chain loading of payloads?
* Martin: 3 main objections * Change the name - Forms Representation is awful. Config Options Data, Option Data structures, Menu Option Data, anything. “Forms Representation” is totally a UEFI phrase. * Make this at build time and not runtime. * Make it easier to populate the menus from each different level - Arch, SoC, Vendor, Mainboard
* Werner: Agree it doesn’t need to be run-time. * Matt: Any runtime can just update the fields in cbmem. coreboot would need to understand the data structures.
* Martin: Should we set up a meeting to discuss this with 9E and interested parties in the community?
# Next meeting * November 15, 2023 * [Meeting link] https://meet.google.com/pyt-newq-rbb
* [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...