2024-10-16 - coreboot Leadership Meeting Minutes
mina--- via coreboot <[email protected]>
| Newsgroups | gmane.linux.bios |
|---|---|
| Message-ID | <[email protected]> |
# 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](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
### [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-update/)
* 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.
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]