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-le...@coreboot.org Best regards, Angel _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
