Dear coreboot community,
Please be reminded that our leadership meeting is scheduled for Wednesday,
September 18,
2024.[1]
Kindly review the current agenda and share your thoughts or suggest additional
items you
would like to see discussed during the meeting.[2]
Thank you.
## Current Agenda
### [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.
* [jpmurphy] What are the coreboot projects goals?
* [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?
* [jpmurphy] Have we solicited or received feedback on why organizations
choose not to use
coreboot?
* Have we solicited or performed technical analysis of how we compare to
other solutions or what
features may be missing?
* [jpmurphy] How do we utilize the OSFF to obtain NDA’s with SoC vendors and
provide early silicon support?
* [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>
* <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.</code>
* <code>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</code>
* <code>[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?</code>
* <code>(https://scan.coverity.com/projects/coreboot)?</code>
* <code>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?</code>
### [Werner] The coreboot project has a few different communication channels
around (mailing list,
Slack, Matrix, IRC, Google docs) 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
In addition, I agree with jmurphy’s points above, we do not have a plan for a
roadmap.
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.
## Announcements & Events
* OCP Global Summit: San Jose, California on October 15–17, 2024
https://www.opencompute.org/summit/global-summit
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]
