# 2024-10-16 - coreboot Leadership Meeting
## Attendees Werner Zeh, Matt DeVillier, Felix Held, Ron Minnich, Mina Asante, Maximilian Brune, Felix Singer, Alicja Michalska, Jason Glenesk, Marshall Dawson, David Hendricks.
## Open Action Items * 2024-10-16 * Matt: Set up a meeting to discuss board status alternatives and send out invites. * 2024-09-18 * Jon: Schedule a dedicated meeting to discuss the Coverity defects and action plan. * Werner: Send out an invite for the 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%5D(https://review.cor...) * Daniel: Look at how we want to localize (non console) strings for coreboot. Long term project.
## Minutes
### [dhendrix] Should we add something in the code of conduct about autism or other conditions that may warrant limited exceptions? * This is something Angel brought up in the e-mail thread regarding a recent disciplinary action. A reasonable accommodation may be good to carve out. That leaves some open questions, however, like how do we know that somebody is really having this condition (e.g. doctor's note?) and not using it as an excuse? Also, what would such accommodations look like? SFC has offered to get us in touch with their director of DEI who can help craft policy for this sort of thing * [Alicja & others] Not a good idea to ask for documentation of a condition due to privacy, people gaming it, discrimination concerns, etc. * Code of conduct came as part of joining SFC. That was quite some time ago, maybe they have some updated language we can use.
### [Sheng] coreboot documentation automation build has been broken for ages. What has to be done to fix it? * FelixS.: Documentation system was converted a while ago (still Sphinx but uses a different parser now because the former was deprecated), noted too late to apply reverts. Now there seems to be a lot of errors which need fixing. * Matt: Has the conversion tool from markdown to html changed? * FelixS.: No, the parser changed. It runs locally but has issues to run on the server * Matt: Currently our repo is out of sync with the doc page. * FelixS. Needs to fix it on the coreboot server (understand why the docker-image isn’t working in our environment) * Werner: Isn’t there a builder for the documentation repo? * FelixS.: There is a dummy-builder around which does not really do anything. It Was planned to integrate it in the future but never happened. * Matt: Any plans to improve this to enable us to catch issues upfront? * FelixS.: Yes, planned but not yet started.
### [WernerZ] Shall we add a policy which will encourage fixing automated code scanner findings (like coverity or scan-build) even if the findings are not very likely to happen in the real world? * Max: Difficult, changing something just because a test found it might not be the right thing to do. It could be a false-positive. We should not just patch in order to make coverity happy. * Matt: Second Max, currently going through a nightmare at AMD fixing coevrity issues. It often makes code harder to read while does not solve any real problem. * David: Maybe we can constrain where coverity scans in the tree? EDK -code can be a source of coverity-findings because coverity does not understand the code flow properly. * FelixH.: Looked at AMD code in coreboot a few years ago, did not have the impression that many coverity issues are found there (mostly 32 to 64 bit issues) * Matt: Let’s exclude submodules and vendorcode from coverity and see how it flies. * Max: Good idea to limit the tree that is scanned by coverity * David: BTW, we had a GSoC project about coverity a few years ago. Jacob did some good write-ups and found 172 real issues, ignored 91. There may be some ideas for how to filter out false positives: (https://blogs.coreboot.org/blog/2019/08/22/gsoc-coreboot-coverity-final-upda...) * FelixH.: Used his github account to log in into coverity and then was asked by coverity to grant wider github account access rights. Why is that needed? Looks fishy. * What's up with coverity scan e-mails? Need to check with Martin about this…
### [Alicja] Do we have something in place that requires maintainers to build and run testing boards to make sure that the images are still able to boot with TOT? * Max: Hard to get some older boards sometimes, how to enforce a run test? And there is not always a maintainer for every board. * David: We decided a few years ago to drop boards that seem to not be maintained anymore (after >2 releases?) * FelixH. Tried to use board-status and it was a pain. Please do not drop boards on this basis because bringing a dropped board back in is much harder. → Matt and Max do agree here! * Matt: Need a better way to communicate a board's current status. board-status repo is too cumbersome. * Matt: Shall we set up a separate meeting to discuss board-status alternatives? * Alicja: Good idea, let’s do that * Matt will send out an invite.
# Next Leadership Meeting * October 30, 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.