# 2026-04-01 - coreboot Leadership Meeting
## Open Action Items
* 2024-11-27
* [Open] Send out poll with regards to LLM usage (requested by SFC)
* 2024-10-30
* [Open] Add clarification to docs: “Do not use gerrit change-id or CB:
format in reference to already-merged patches.”
* 2024-10-16
* [Open] 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
* [Open] 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
* [Open] 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)
* [Open] Daniel: Look at how we want to localize (non-console) strings
for coreboot. Long-term project.
## Announcements & Events
* Next Open System Firmware - OCP Project Meeting
* Date: [March 26, 2026](https://coreboot.org/calendar.html)
* OSFC 2026
* Date: 15 - 17 September
## Attendees
Angel Pons, Mina Asante, Jay Talbott, David Hendricks, Julius Werner, Werner
Zeh, Matt DeVillier.
## Minutes
### [Nicholas Chin] Unexpected Patch signed-off-by change
* (I can’t attend, adding it here in case anyone forgets. Angel, Alicja,
Matt, and David should be aware of this incident).
Last week, there were a few patches that had their sign off unexpectedly
changed by a new user, including one which was sitting in the submittable
state, [CB:91785](https://review.coreboot.org/91785) (full list corresponds to
these builds: [https://qa.coreboot.org/user/gwowvwubkwwruabq-blip/builds]).
This did not seem to be a simple mistake from a beginner nor an attempt to take
over old patches that haven’t been touched by the original author. Currently,
Gerrit is set up to preserve votes if only the commit message is changed, which
could lead to a commit getting submitted with an incorrect sign off. Even if
the code was changed, resetting the vote, this would still lead to a lot of
cleanup work if done en masse.
Do we want to do anything to prevent this behavior from bad actors/bots/etc
and if so, how should it be implemented? Editing patches you do not own can be
disabled, though there are legitimate use cases for being able to do this. One
idea was to restrict this ability for new accounts.
* Do we create a new group that we regularly add new established users to?
I suppose such a group wouldn’t get +2 rights, otherwise it doesn’t seem
meaningfully different from the reviewers group. The reviewers group would be a
superset of this.
* Reuse the reviewers group? The description says “Contributors with more
activity than a one-off commit” which to me seems not that far off from the
criteria of a new group of not-new users.
* [Angel Pons]: Current problem: Any new Gerrit-user can just edit other
peoples patches without limitation. Messing around with patches is too easy
right now. A new group of people (manually added to this new group) could get
the rights to edit other people’s patches and all new users will be prohibited
to edit other people’s patches on Gerrit.
* [David Hendricks]: Adding new lists isn’t always easy to maintain as it
comes with a burden.
* [Angel Pons]: We do have a group for corporate users, we could use
this one plus the reviewers group (Gerrit groups can include other groups).
This should cover most use cases.
* [Werner Zeh]: We should think of making our Gerrit instance more robust
against ‘attacks’ like the one. Having the AI power in mind coming into our
lives, attacks like these one can have a much bigger impact.
* [Werner Zeh] Do we have a regular backup of the Gerrit database?
* [David Hendricks]: Felix Singer knows best but I guess we have a backup
in place. Maybe we can implement a server-side hook to avoid that a
signed-off-line can be deleted from a patch.
* Plan: Restrict the rights to modify existing patches for new users. Users
of the corporate and reviewers group will still be able to modify existing
patches. We will apply the permissions to the groups which will automatically
enable the users and on the other hand disable all other users from changing
existing patches.
* [Matt]: Sounds good to me for now. Let’s see how it will work.
* [Julius]: Sounds good to me.
* [David Hendricks]: Let’s bring the implementation of the plan to the
coreboot admins group, someone from this group will take care.
### [Werner] This e-mail reached us:
* My name is Rik Viergever, I work with E Foundation and Murena, who
collaborate on /e/OS, an Android-based mobile operating system, fully open
source (https://murena.com/smartphones/). We are working on a funding
application currently with a number of Linux distros and I'm wondering if it
could be worthwhile to explore for coreboot to join us. It is Horizon funding
by the European Commission, they are looking to fund European organizations
and/or individuals to work on open-source OS and firmware projects.
* I'm emailing to ask if this would be of interest to you + if you would have
a European entity from which this work could be conducted.
* The amount it would concern would depend on the work you would propose, but
could be up to 250k.
best regards,
Rik
* Is the coreboot project qualified? Do we have a European entity?
* [Werner]: Ask Martin Roth for more details for the ‘European entity’ part.
# Next Leadership Meeting Date
* April 15, 2026.
* [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 Notes
https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKjeDQ.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
