# 2023-06-28 - coreboot Leadership
Attendees: DavidH, Jpmurphy, Coolstar, MattD, FelixS, WernerZ, JonathanH, StefanR, MartinR, JuliusW, RonM, KarthikR, DanielM
## Minutes:
* [KyöstiM] Make build statistics downloadable from qa.coreboot.org Work to create such tar-file with timestamps and ccache stats started here: [https://review.coreboot.org/c/coreboot/+/75803%5D(https://review.coreboot.or...) * Martin will look at making the stats downloadable
* [KyöstiM] Is ccache for clang intentionally disabled for coreboot-gerrit queue? I think it would be possible to configure ccache for separate gcc and clang backing storages. * Ccache was causing the build to take longer, so was disabled. Martin did look at separating the two ccache locations, but the GCC ccache is stored in ram, and there isn't typically enough memory to save both. * Look at separating GCC and clang builds into two separate builds. * Look at coverity builds - should probably only build GCC.
* [coolstar] Pixel 2013 (Link) I2C bus ACPI (Windows vs Linux) * Attaches to IGD device because the i2c touchpad/touch screen are on it * Brand new drivers that are about to be submitted to MS to get signed – hardware pre-dates I2CSerialBus (which normally would be in HSW+), but new drivers on Windows use it. * It sounds like the best plan is to just push the patches and see if there are any other suggestions.
* [Mailing list] Variants * There was a request on the mailing list to look at making a company’s board a variant of the CRB. We should give recommendations in the documentation about when variants should be used. * [Martin] vendors shouldn’t be under other vendors. CRBs shouldn’t be used as baseboards for other boards. * [Werner] Agree with Martin that variants should be used for whitelabel devices, but not for CRBs. * [Ron] Things are the way they are because early in the coreboot project, the other method of having vendors under CRBs was tried. The current method gives free reign to vendors to change whatever they want.Vendors like to tweak their own boards and do not like having other vendors introduce conflicting changes. * What about duplicated code and having to refactor functions out? * Ron - Sure, things can be refactored out, but deduping the code can be very tricky - it leads to a lot of #ifdefs and gets very messy. Mucking about in mainboard code may look good from an abstract firmware engineering standpoint, but leads to issues. * Daniel: Using CRBs for baseboards could work as a tree with another level, but agrees with Ron that having separate boards probably makes more sense. * Who should handle any refactoring? * Martin thinks that pushing refactoring to new coreboot engineers is going to make people want to not contribute to coreboot. * David - Definitely - can’t ask new people to rewrite as a vendor without giving any direction as to why or how, or point at a concrete example. * Ron - Agrees with David - pushing people too hard encourages forks. * Werner - could be a path to more contribution - submit initial patch, then look at rewriting. * David - teaching good code quality and coreboot standards is one thing, but pushing them without direction just leads to frustration from the new person. * Daniel - Experience shows that refactoring without understanding leads to poor refactors. We could use some documentation. Any comments could be written as documentation to help people. * David: “There are plenty of variants in the tree - look at them for examples.” is not helpful - people would have no idea which variant to look at. Especially when one doesn't exist. * Ron - stakes are much higher in firmware. It's easy to mess up and brick a bunch of systems. * Martin & David: Refactoring by beginners causes those beginners to rewrite the code in the CRB, which will lead to issues, especially if they can’t test it. * Stefan - Making code look nice is problematic and can break things. * David will write up some documentation on what was discussed here about when to use variants. Daniel & Werner can help.
* Would it be interesting to have “shepherds” to help newcomers to the community? * FelixS: I’m doing this for the releases. * How time consuming is this? * The process is started 6 weeks before the release. It really varies, but typically a few hours a week. * Would people be interested in signing up to shepherd newcomers? * Matt, stefan, martin - sure * Martin will create a signup sheet * Ron, Jonathan, and Jpmurphy would be interested in shadowing until they feel confident. * Martin to send email to the mailing list with a request for additional shepherds. * Make script to help direct attention to patches (status:open and +1'd or +2'd, maybe other criteria) to help get them merged - send to mailing list periodically (weekly digest?).
* [DanielM] relaying from Slack * Warner Losh: So I’m trying to understand something about a code change request I got for FreeBSD. A long time ago (2015), we committed: [https://cgit.freebsd.org/src/commit/?id=6c176113bbdd5%5D(https://cgit.freebs...) to implement quirks for what’s not about 10-year-old chromebooks, but specified just the Acer Peppy. Later (2016), I expanded this to all coreboot instances since at the time I only knew that they were in chromebooks. Lately, we’re getting a lot of requests to add exception to the rules that are there. Starting in 2020, we started getting these. I’m wondering if there’s a better way and if people here even know what the issue is/was. DFBSD seems to have deleted all their code for this. [https://github.com/DragonFlyBSD/DragonFlyBSD/commit/ad8b9749306613f2978808b4...) and [https://github.com/DragonFlyBSD/DragonFlyBSD/commit/7f3d8d5546c701eceefe4437...) were the original dfbsd commits describing the problem with the emulated i8042. * Could someone reach out to Warner on slack? * Matt and coolstar fixed this in the EC codebase in Matt’s repo.
# 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 https://docs.google.com/document/d/1NRXqXcLBp5pFkHiJbrLdv3Spqh1Hu086HYkKrgKj...
-
coreboot org