2024-03-06 - coreboot Leadership Meeting minutes

# 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).