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