# 2024-03-06 - coreboot Leadership Meeting minutes
## Announcement:
OSFF ByteTalks - [https://osfw.foundation/events/bytetalks-vol.-1/]. OSFC will be in Bochum Germany - September 3-5 - [https://www.osfc.io/].
## Attendees:
Martin Roth, Mina Asante, Julius Werner, Daniel Maslowski, Jonathan Hall, Matt Devillier, Nicholas Chin, Nico Huber, Jay Talbott, Felix Singer, Werner Zeh, Marshall Dawson, Felix Held, David Hendricks, Jules Irenge, Max Brune.
## Open Action Items
* 2024-03-06 * [Open] Martin: To update documentation on gerrit contributing guidelines. * https://doc.coreboot.org/contributing/index.html * 2024-01-10 * [Open] Werner: Push patch based on https://ticket.coreboot.org/issues/522 * Nico: https://review.coreboot.org/q/topic:enforce_region_api * Open Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [Martin] -1 should be a privilege for coreboot reviewers along with +2 rights. * Since 2016, all registered users have had -1 rights. Back then, we didn’t block on unresolved comments, so giving a -1 was the only good way to get attention for an issue. This is no longer the case, and I feel that we should go back to having -1 rights be one of the privileges given to contributors. * There’s no incident - We just don’t need to give -1 to every registered user anymore. This has been superseded by making people address all open patches. * Current status: * Registered users: -1 to +1 * Developers: -1 to +2 * Core developers: -2 to +2 * Proposed: * Registered users: 0 to +1 * Developers: -1 to +2 * Core developers: -2 to +2 * FelixS: If people can give +1, they should be allowed to give -1. * Martin: So should we give -2 privileges to everyone with +2 privileges as well? * FelixS: The -1 allows me to see attitudes about things without needing to read come * Martin: I feel like the -1 rights should go to people who have actually submitted patches - it’s not hard. * Max, David, Daniel: Agreed * FelixS: Disagree * Documentation needs to be updated. * We can change it back if there are issues.
### [Martin] Implementing fuzzing testing at coreboot. * First test at [https://review.coreboot.org/plugins/gitiles/coreboot/+/refs/heads/main/util/...] * Any APIs & anything loaded out of SPI should be fuzzed when possible. * Add to ongoing projects.
### [Martin] Gtiles is currently down * FelixS added some firewallish rules to the web server to block some bots. Still not very efficient - each Bot needs to be blocked individually. * We don’t get IP addresses of requests. * Daniel: Search engines also index GitHub on which we have mirrored out repos, so when it’s about code visibility/discoverability, we can block crawlers completely to lower the impact on our own infra. People can use the GitHub viewer and Gitiles alike, giving just a different view on the same data.
### [FelixS] Revisit register naming for I2c device registers: * See (https://review.coreboot.org/c/coreboot/+/77098) - This only changes the *coreboot* structures, not device #defines and device specific structures. * After discussion about this patch, there’s more support for keeping internal naming consistent, even if it doesn’t match the names from the specs. * Werner: Keep the names consistent with the datasheets even if they don’t match the coreboot structures. Max: Agreed * Martin & FelixS would prefer to change.
### [Martin] Renaming SPI master/slave * There’s no specific SPI spec, but there are a number of major companies who have changed the names in their specifications. Most notably, Intel has changed the names in the eSPI specification to controller/target. \ Unfortunately, there’s no real agreement on what to change the names to: \ [https://en.wikipedia.org/wiki/Serial_Peripheral_Interface#Alternative_termin...] * Martin’s proposal would be to go with the eSPI names of controller/target as eSPI. \ * Matt and Werner agree. * Julius points out "main" and "sub" preserves MISO/MOSI and is currently used on Wikipedia. * Max likes this. David +1 * Nico: This seems a bit forced * SPI: main/sub and eSPI: controller/target (Devices use whatever their datasheet says) * FelixS: Let’s look at what the linux kernel does.
### [Martin] Designing a coreboot Poster & Brochure for conferences * We’d like to design a poster & brochure to have at conferences and other places where coreboot information is desired. * [https://docs.google.com/document/d/1l-dSWram1vpq6-fYYqecYmOXCpj_7YXSnBx-kaKf...] * Please comment or contribute * Marvin has a flyer * Add a payload section - Most used payloads - add logos * Adding a bunch of qr codes pointing to the website for the vendors & consultants * Shortened links as well or instead * Make part of the domain instead - gsoc.coreboot.org instead of https://doc.coreboot.org/contributing/gsoc.html
### [Martin] Info only: The 24.02 release is complete and announced. * Next release will be Mid-May.
### [FelixS] Not applying to GSOC this year - deadline is passed. * Not many people interested in mentoring - This is a big time investment.
# Next meeting * March 20, 2024. * [Meeting link](https://bbb.sfconservancy.org/b/mar-sfn-e22-axi). * [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-03-06](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj... 1).