# 2024-06-26 - coreboot Leadership Meeting
## Attendees Felix Singer, Felix Held, Werner Zeh, Jonathan Hall, David Hendricks, Jay Talbott, Mina Asante, Martin Roth, Karthik Ramasubramanian, Marshall Dawson, Shelley Chen, Maximilian Brune, Lean Sheng Tan.
## Announcements & Events * FOSSY conference: August 1-4 2024 in Portland, Oregon, USA https://sfconservancy.org/fossy
* COSCUP - Taipei, Taiwan on 2024/08/03 ~ 2024/08/04 https://coscup.org/2024/en/landing
* OSFC will be in Bochum Germany - September 3-5 https://www.osfc.io
* OCP Global Summit: San Jose, California on October 15–17, 2024 https://www.opencompute.org/summit/global-summit
## Open Action Items * 2024-05-01 * Nick Van Der Harst volunteered for Dutch. "gogo gogo" would like to translate to Russian (?) * 2024-03-20 * Martin:To Add a note to the gerrit guidelines to email the leadership for further discussion and guidance when code submissions are not up to standard. * 2024-03-06 * Martin: To update gerrit contributing guidelines documentation. (https://doc.coreboot.org/contributing/index.html) * 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
## Improving coreboot processes
### [Martin] bi-weekly review meetings * In an attempt to get patches merged more quickly, we’re looking at adding a meeting to review patches and try to get blocking issues sorted out. This will start as a bi-weekly meeting of 1 hour and we’ll see where things progress from there. Any preference for Tues/Wed/Thurs? 16:00, 17:00, or 18:00 UTC? (should we define it in UTC or in some other time zone that may switch based on daylight savings?) * 17:00 UTC on Wednesdays opposite the leadership meeting. * David: Start a new google doc to ask for reviews. * Werner: Dedicated email address * Felix: Would it be better to just generate a list? * David: Let’s do both requests and generate a list of patches to review. * Karthik: Should maintainers be involved? * Martin: Absolutely, if they come to the meeting. * David: The idea is to remove bureaucracy * Werner: Who should we invite? * Martin: core devs * Felix: We can change things that don’t work well.
### [Martin] Merge SLOs * Can we define objectives for timeframes to get patches merged to different areas in the codebase? An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform.
* Mainboard: 1 week? * FelixH: So what do we do if we get past this timeframe? Just merging anything because it’s passed the SLO period seems like a bad idea. * David: This is designed to help people who are new to the project. We don’t just want to merge stuff, but for isolated code, maybe we can look the other way at imperfections. * FelixH: Frequently add comments and mark as resolved. * David: SoC code still needs to be held to higher standards. * David: We still expect authors to be responsive to feedback. * FelixH: We still need reasonable patches as well - one logical change per patch. * Martin: Do we want any areas besides Mainboards? What about SIOs? * Werner: Maybe drivers? * Max: Everything other than mainboards can be used by multiple vendors? * Martin: It doesn’t seem unreasonable to try to get things merged in a month. * FelixH: It would be good to have a list of things to look at. * Martin: Send out an email with a list of patches which will be looked at in the next meeting? (Yes) * Add a month SLO for drivers & SIOs initially.
### [Karthik] RFC - Extend Coreboot FileSystem to disk * [Extend CBFS to Storage Media](https://docs.google.com/document/d/1LFXIr38_u2bnXY9G6-uJHYxIAFqwX9tUN5bLR2ci...) * Werner: How do we make sure we don’t address the wrong drive? * Karthik: Define a rule in FMAP to describe the characteristic of the disk. * Werner: Wouldn’t coreboot need to search all of the disks? Finding it would be tricky. * Werner: Don’t like searching multiple partitions. * Martin: So would this just be in libpayload * Karthik: The initial code would be just for libpayload. * Martin: I can’t really think of any uses for this in coreboot other than a splash-screen, so I’d really prefer that it just stayed a part of libpayload. * Karthik: We can keep this just a part of libpayload. If we ever need to change that, we can address that again at that point. A notice will be added. * Werner: Last time I dealt with EMMC, there was a difference in speed - training slowed things down and it needed write support. * Martin: I feel like there’s a big difference between training and any writes needed for that, and actually accessing data on the drive. I’m not opposed to the idea of starting training earlier. * David: Are there any patches? * Karthik: I can upload patches in the next week or so - it’ll be a WIP patch.
### [Martin]: Setting aside the reformatting project with clang-format until it’s more stable and has fewer quirks.
# Next Leadership Meeting * July 10,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 leadership meeting minutes *[2024-06-26](https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...).
Hi list,
On Thu, Jun 27, 2024 at 2:00 PM mina--- via coreboot coreboot@coreboot.org wrote:
# 2024-06-26 - coreboot Leadership Meeting
*snip*
### [Martin] Merge SLOs
- Can we define objectives for timeframes to get patches merged to different areas in the codebase?
An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform.
- Mainboard: 1 week?
- FelixH: So what do we do if we get past this timeframe? Just merging anything because it’s passed
the SLO period seems like a bad idea. * David: This is designed to help people who are new to the project. We don’t just want to merge stuff, but for isolated code, maybe we can look the other way at imperfections. * FelixH: Frequently add comments and mark as resolved. * David: SoC code still needs to be held to higher standards. * David: We still expect authors to be responsive to feedback. * FelixH: We still need reasonable patches as well - one logical change per patch.
- Martin: Do we want any areas besides Mainboards? What about SIOs?
- Werner: Maybe drivers?
- Max: Everything other than mainboards can be used by multiple vendors?
- Martin: It doesn’t seem unreasonable to try to get things merged in a month.
- FelixH: It would be good to have a list of things to look at.
- Martin: Send out an email with a list of patches which will be looked at in the next meeting?
(Yes)
- Add a month SLO for drivers & SIOs initially.
Would it make more sense to aim for timely replies, i.e. avoid patches sitting unreviewed for an indefinite amount of time? IMHO, aiming to submit mainboard ports after 1 week sounds unrealistic: authors won't necessarily be active on Gerrit every day, and some mainboard ports (e.g. laptops) may take more time to review; mainly because EC support, but if possible one could do an initial port and add EC support in a follow-up (and hope said follow-up also gets through).
About helping newcomers, I think what would help the most is to streamline the review process. For example, be less nitpicky about style. I know, I myself am guilty of that. Also, instead of asking everyone to manually change stuff that autoport or intelp2m generated, fix the tool in question. It took me too long to gather the resolve to make https://review.coreboot.org/82401 (good thing it's submitted). Yes, that comment is likely wrong on most of the boards in the tree. And yes, I remember seeing a relatively new mainboard port with an unreasonably low DSDT revision number, with that bloody comment...
In addition, having an up-to-date mainboard porting guide (tutorial, part 4) that helps guide people through the process would be fantastic, as there have been a few times where pointing others to such a guide would've been very useful. Plus, I've seen many people make less-than-ideal decisions in the past, e.g. edit existing boards instead of adding a new one (even if it's a copy of an existing board), "cross-flash" a coreboot build for a different board (oh no, the GPIOs), or using Intel RVPs (Reference and Validation Platforms) as a reference.
Clarification regarding RVPs: the code for newer RVPs is quite convoluted for a beginner because variants, ChromeOS support and EC firmware SKU selection; older RVPs (CML and earlier) are mostly untested and unmaintained these days, so they're not great to use as a reference. Plus, most newcomers are retrofitting coreboot onto commercially available devices: they do not always have access to board documentation (schematics and/or boardviews), which makes configuring things like PCIe clock source/request mapping substantially harder; some boards don't even have a proper console (and having to rely on flashconsole for porting is last-resort misery). Because of this, the porting process differs from that used for the RVPs, where board documentation is available, there's at least one (if not more) UARTs to get coreboot logs out of, and one may even have access to blobs' source code.
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards, Angel
Jun 27, 2024 at 10:14 by th3fanbus@gmail.com:
Hi list,
On Thu, Jun 27, 2024 at 2:00 PM mina--- via coreboot coreboot@coreboot.org wrote:
# 2024-06-26 - coreboot Leadership Meeting
*snip*
### [Martin] Merge SLOs
- Can we define objectives for timeframes to get patches merged to different areas in the codebase?
An individual mainboard that doesn’t affect the rest of the codebase doesn’t need as much scrutiny as core code that affects every platform.
- Mainboard: 1 week?
...
- Add a month SLO for drivers & SIOs initially.
Would it make more sense to aim for timely replies, i.e. avoid patches sitting unreviewed for an indefinite amount of time?
Sure, that'd be amazing. Do you have a proposal about how to make that happen?
The SLOs are to help us see when things are sitting for too long, not to push things in that aren't ready to be merged. Right now we don't really have any sort of method to sort patches and keep things following well.
This is simply an attempt to help with that and identify patches to pick up for review in the bi-weekly meetings that are going to be organized. If it doesn't work, we'll soon discover that.
... About helping newcomers, I think what would help the most is to streamline the review process. For example, be less nitpicky about style.
That's part of what's being proposed, particularly for areas such as mainboards.
...
In addition, having an up-to-date mainboard porting guide (tutorial, part 4) that helps guide people through the process would be fantastic, as there have been a few times where pointing others to such a guide would've been very useful.
Absolutely! Can you help write that? Can we get volunteers?
...
Clarification regarding RVPs: the code for newer RVPs is quite convoluted for a beginner because variants, ChromeOS support and EC firmware SKU selection; older RVPs (CML and earlier) are mostly untested and unmaintained these days, so they're not great to use as a reference.
Again, I agree, I'm just not sure what to do about it. The reference boards are done for the Si vendors' testing, not as reference for coreboot developers.
Any thoughts on how to solve this?
...
Because of this, the porting process differs from that used for the RVPs, where board documentation is available, there's at least one (if not more) UARTs to get coreboot logs out of, and one may even have access to blobs' source code.
Again, I agree. What do we do about this? The boards that are being ported are what they are. Can you (or anyone) help document ways to work around these issues?
If you have any solutions to these problems, or can figure out how to get the things done that need to to be done, I'd love to hear them. I want to avoid burning out the people we have on the project already. Any concrete ideas along with ways to get them done are welcome.
Let's just try to avoid making suggestions that expect someone else to do them. It's easy to say "someone should", but finding that someone is the hard part.
Apologies if my tone is hard. Today's a crap day.Martin
coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
Best regards, Angel _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
-
Angel Pons -
Martin Roth -
mina＠coreboot.org