# 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 -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
