# 2024-10-02 - coreboot Leadership Meeting
## Attendees
Felix Held, Alicja Michalska, David Hendricks, Matt DeVillier, Maximilian
Brune, Werner Zeh, Mina
Asante, Martin Roth, Jonathon Murphy, Felix Singer, Julius Werner, Karthik
Ramasubramanian, Jeremy Compostella.
## Announcements & Events
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
## Open Action Items
* 2024-09-18
* Jon: Schedule a dedicated meeting to discuss the Coverity defects and
action plan.
* Werner: Send out invitations for this 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
### [jpmurphy] Have we solicited or received feedback on why organizations
choose not to use coreboot?
* Have we solicited or performed technical analysis of how we compare to
other solutions or what features may be missing?
* David: Were we supposed to set up a meeting to discuss ideas?
* Intel was pushing slimboot - BSD licensed.
* Do we know how much slimboot is used?
* Werner: 2 years ago it was being used because of the license reason. More
than 90% of
contributions were made by intel employees. The main intel contributor has left
the project. It
doesn’t look like there’s a community there at all. No guarantee that the
project will persist if
intel decides to drop it. Based on the BSD license there’s not much of a chance
that a healthy
community will evolve. With intel’s current financial issues, it’s even less
likely.
* Max: I’m not hearing anything about slimboot anymore.
* Martin: Inertia
* Martin: UEFI is more expected, has larger IBVs.
* The silicon vendors push the IBVs - AMI, Insyde, Phoenix.
* ODMs just go with their relationships with the IBVs.
* Developing on your own is hard
* Complexity/inflexibility of FSP. It's hard to justify coreboot + FSP when
FSP requires its own
set of custom patches and hacks to change its default behavior.
* Alicja: I believe we need something that can configure the platform
options at runtime (writing to CMOS/SMMSTORE) instead of setting options at
build time, many people using Chromebooks with Matt's builds complain about
"lack of features".
* Can anyone look further into this?
### [Werner] Present the workflow for Feature Request and Implementation which
is an outcome of one of the OSFF’s workstreams.
* There are tasks around streamlining feature implementation requests to make
it more plannable for
business use cases. Werner took it as an AI.
Website:
(https://opensourcefirmware.foundation/workstreams/feature-request-flow/)
Specification:
(https://drive.google.com/file/d/1su3s93xNgqy9AixDfHEWGrB_1nxYbQoz/view)
* This process has been reviewed by a number of coreboot and OSFF community
members from a number of companies.
* This would not be required to add a feature, but is intended simply to help
the project and
feature implementers work through the process.
* The point of this is to provide a timeline and a better guarantee that the
feature would be
accepted by the community.
* Felixh: Who is doing the work to implement the feature?
* This is not restricted by the process. Most of the time it would be the
requester.
* Felixh: The “guarantee” of acceptance is very concerning. I’m worried that
companies will demand
that their patches get rubber stamped.
* That’s absolutely not guaranteed by this process. The idea is that a
specification would be
agreed upon, to facilitate the merging of features. The time to reject a
feature is early in this
* Max: Who decides when to transition between phases?
* Werner: It differs between phases. One way is when the community and
requester are in sync. In
the implementation phase if the feature complies with the design document
(this is decided by the implementation team).
There are also suggested timelines.
* Max: There are a number of feature patches where the idea is good, but the
implementation doesn’t fit coreboot well.
How do we avoid merging poor patches?
* Werner: That’s why the community needs to be involved in the
implementation phase. Full features
shouldn’t just be dropped into the tree.
* David: Agreed, even if an implementation isn’t perfect, it may be better
to get it in then fix it
rather than just letting it bitrot.
* FelixH: If things are being done behind closed doors, this process may not
work.
* Martin: Behind closed doors should be a big exception. Let’s see how this
goes.
* Werner: I can look at creating a feature design template from the OSFF. We
can also have a
dashboard of features that are ongoing and what phase they’re in. There are a
lot of things to
improve in the ecosystem.
* Martin: How to give feedback:
* Werner: Send an email or review on the google
[doc](https://docs.google.com/document/d/1zZvnoJwAKX7bm80UxPwnHMfelvoqoYbxR1vAW3xvxuM/edit?usp=sharig).
Feedback is welcome.
### [jpmurphy] I opened a bug within Google to update our best practices on
bugs being used with coreboot.
There are at least two options, asking for feedback/alternatives:
* 1. Use a public component that everyone can see accessible at
<code>(https://issuetracker.google.com/)</code>
* Some bugs will still need to stay private to protect business needs and
may create the need for secondary bugs.
For this reason, some Googlers prefer we not use this approach.
* 2. Instead of using BUG=b: fields within commit messages, googlers could
use a different ID to
make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id.
* Jon: We’re going to try to make the bugs public and update gerrit. Can we
add a rule to link to
the bug?
* Martin will work with the other admins to make this work.
* CrosBug?
* BUG=b:?
* CB-Bug - For coreboot bugs?
* Werner: Please respond to the poll about how to respond to coverity issues.
* (https://rallly.co/invite/1c8J3azXAcje)
### David: We had to take an action with a community member’s behavior. Details
are on the mailing
list. David will respond to various questions on the mailing list.
* If anyone is feeling anxiety about dealing with other people in the
community, *please* reach
out. You can email anyone on the leadership team or the arbitration team. These
issues will be kept confidential.
(https://coreboot.org/leadership.html)
### Granite rapids patches are out! Great job getting these out before the chip
is out.
* FelixH: These are great and very appreciated. It’s obvious that a lot of
work went into trying to improve things.
# Next Leadership Meeting
* October 16, 2024.
* [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 mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
