# 2024-09-18 - coreboot Leadership Meeting
## Attendees
Ron Minnich, Felix Singer, Julius Werner, Felix Held, Matt DeVillier, Nico
Huber,Jon Murphy, Werner Zeh, David Hendricks, Mina Asante.
## Announcements & Events
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
## Open Action Items
* 2024-09-18
* Jon: Schedule a dedicated meeting to discuss the Coverity defects and
action plan.
* Werner: Send out invitations for this meeting.
* 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)
* Daniel: Look at how we want to localize (non console) strings for
coreboot. Long term project.
## Minutes
### [Martin] How do we want to handle code written with copilot or other AI
tools.
* We don’t currently have a policy, and it seems like we should.
* [Matt] Code generated by AI is not copyrightable. Submitters should stay
responsible for their
code, regardless how it was created.
* [David] Would be polite if the author mentions in the commit message that
AI was used to create (parts) of the code.
Still DCO should cover the legal parts of this discussion. Therefore, we do not
need a dedicated policy for that.
* [David] We should try to leverage AI possibilities in our project. As
Bryan @ Oxide observed,
open source code are by nature documented better than proprietary firmware (as
far as LLM training goes)
and this can be an advantage of coreboot.
* [Nico] Can this make it easier to violate the DCO using AI? Should we try
to improve the awareness in the community?
* [Matt] The AI can spit out license-incompatible code and this way could
make it into coreboot’s code base.
* [Matt] Update the DCO to include that the comitter has to ensure that the
added code from AI is compliant to our license.
* [David] Are there filters available at the AI side to ensure output is
license compatible?
* [Julius] We could ask the SFC for help from the legal standpoint
→[David](mailto:david.hendri...@gmail.com) will ask
### [jpmurphy] What are the coreboot projects goals?
* Individuals and companies have their own goals. Do we have wider goals from
the project’s point of view?
* [David] This is a huge topic. Should we start a doc and just collect
things there?
* [Ron] Initial goals of linuxbios were: maintainability, security
reliability
* Goal was to have computers shipped with coreboot, not to retrofit
machines like buying a Wintel
PC and installing Linux on it.
* [Werner] Get adoption by big vendors earlier, the rest will fall into it.
* [Nico] For an early vendor adoption, we need to be able to boot into
Windows as a first class citizen
* [FelixH] UEFI way of booting an OS is de facto standard in the client
space. We could counter
this with EDK 2 but somebody should take the time to work on this.
* [David] There are a number of different solutions to boot Windows
(Universal Payload, EDK 2,
Yabits and Rust Hypervisor (Akira's projects)), has somebody had a closer look?
If the goal is to
boot into EDK2, why bother with coreboot at all?
* [David] Multiple architectures and boards in a single codebase -
LinuxBIOS started with PPC,
Alpha, and x86. Support for ARM helped get Intel to support coreboot. EDK2 is a
fork-per-product sort of deal.
* [Werner] We should continue the task of re-building coreboot’s webpage.
Gather all the
requirements and reach out to some company that can do the work based on our
requirements. Preserve
a section in this webpage where real uses-cases can be added to to make
coreboot’s use cases popular.
* [FelixH] Simplified architecture, not bloated like EDK2 with its
dispatcher, dynamic module loading, etc.
### [jpmurphy] How do we want to manage a roadmap?
* Can we start a draft of a roadmap to at least start gathering a list of
features/tech debt and their priorities?
* [FelixH] Writing up a roadmap does not mean the features will be
implemented. Who will make sure
that we stick to the planned roadmap?
* [Jon] We should have at least a list gathered so that we can plan
* [FelixS] We have too many communication channels, keeping track can be
quite challenging.
* [Werner] Use a kanban board to publish and track progress of features?
* Better look/feel than tickets.
* [Werner] The coreboot project has a few different communication
channels around (mailing list,
Slack, Matrix, IRC, Google docs, Discord) All our discussions happen spreaded
among those and there
is no central place (accepted by all community members) where decisions are
written down.
* Mailing list seems suitable as it has an archive but some people opted
out due to heated
discussions and other issue we had in the past.
* Google docs could be one place but unfortunately not every community
member likes them. In
addition, despite the meeting minutes, there is no “official” document where
centric decisions are
written down, one has to search in the archive to find things.
* Slack/Matrix are not used by everyone.
* IRC is not suitable for such things as well.
* Would a kanban-style board be something we like to have a look into for
such things? I know,
ranting about too many communication channels and then adding another one isn’t
the best move. But
still, let us at least discuss.
* Possible open source boards we can have a look at:
(https://kanboard.org/) and
(https://wekan.github.io/).
It might be easier to maintain a feature roadmap this way, IMHO. And we can
host it on coreboot.org
to have full control over it.
* [FelixS] I suggest using [forgejo for kanban
boards](https://forgejo.org/docs/latest/user/project/) instead,
since I’ve suggested it as an issue tracker before and it got positive
feedback. Both, issues and kanban, are very well integrated.
So we reduce the number of services.
### [jpmurphy] We get coverity results for free from synopsis. At the time of
writing, there are
705 outstanding defects. Do we have a plan for burning these down?
* (https://scan.coverity.com/projects/coreboot)?
* Can we set a bar to burn these down by a certain date, and then moving
forward we require that
the defect count is 0 prior to releases?
* [FelixH] Can we export the coverity results and show them in a
coreboot-driven dashboard so that
everybody can have access?
* [Jon] Set up a dedicated meeting to discuss this?
* [Werner] I can send out an invite to discuss this.
### [jpmurphy] I opened a bug within Google to update our best practices on
bugs being used with
coreboot. There are at least two options, asking for feedback/alternatives:
* 1. Use a public component that everyone can see accessible at
<code>(https://issuetracker.google.com/)</code>
* Some bugs will still need to stay private to protect business needs and
may create the need for
secondary bugs. For this reason, some Googlers prefer we not use this approach.
* 2. Instead of using BUG=b: fields within commit messages, googlers could
use a different ID to
make it more clear it’s a Google bug. Felix S had suggested ChromeOS-Bug-Id.
# Next Leadership Meeting
* October 2,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
