# 2022-04-20 - coreboot Leadership Next meeting: 2022-05-04
## Attendees: Jay, Martin, Felix, Christian, Piotr, Tim, Ron, Arthur, Julius, Felix Held, David, Stefan, Paul, Patrick
## Decisions * Martin will write up a document about when platforms would be moved to a branch: Basically only when it hinders progress, not because it's untested. * Martin will do an example of Kconfig where the platforms have been removed keep the mainboard names in the tree. When selected, it will show the branch where the platform is maintained. We can also include the last known good commit for current mainboards. * Patrick will look at adding the security mailing list to the page at [http://mail.coreboot.org%5D(http://mail.coreboot.org) * Felix Singer will investigate adding better user authentication to our redmine server.
## Minutes
### [Felix S] The German government wants to fund open source projects. More information will follow next year 2022. [1] * I did some research and asked around, since I didn’t hear anything. The German government agreed on this funding last year, but their presented household finance plan (~22th March) doesn’t contain anything for open source. The final finance plan will likely be decided this summer. Until then it’s possible to change that. * Official statement from OKFN (only german) [2] * Alternative funding projects are the [Prototype Fund](https://prototypefund.de/en/) and the [Hardware Prototype Fund](https://hardware.prototypefund.de/en/), but they are expecting you to invent something new and all participants of a group should have their residents in Germany. Prototype fund is going until 2024. 5 or 6 projects are accepted every 6 months, and a project can get up to 50,000 euros. * Something “new” would have to be added to coreboot. * Hardware prototype fund is similar, but more specific to hardware. * [Piotr] [Technology Common Trust Open Firmware Fund](https://technologycommons.org/OFF/) in cryptocurrency. 50k Euros. Mostly for EU citizens, but have funded north american projects in the past as well. * What do we want to do with these funds? * Do the people working on the project get the funds? * Do we just put these up on the website as a way to help get coreboot projects funded if someone wants to do something?
### [Martin] Moving platforms to a stable branch. * What are the requirements? * I think (roughly) everyone agrees that platforms can be moved to a release branch if they’re blocking forward progress. * Is this the ONLY reason things should be removed? * Felix H, Paul: yes * Martin will write up something about this and push it to documentation to review. * David: We discussed before that platforms would be removed if it hasn’t been tested. * Give a release cycle or two to have it tested and remove it if it doesn’t get tested in that 6 months. * Boards that are moving to a stable/release branch are announced in the release notes prior to being moved, so there is time to update/test a target if a developer wishes to keep it in main. * Put the last known working version in the Kconfig. * Paul: Need to avoid having too many branches. ChromeOS, for example, has hundreds of branches that are difficult to understand. Security patches would need to be ported to many branches. * Ron: Everyone acts like leaving an unused target in the tree has no cost, and that’s not true. * There are other costs than just the jenkins builds. * FelixS many of us use freetime to do the maintenance, and this could be better used. * Can we make a requirement going forward that all mainboards must have maintainers and can we require that the mainboards be tested by the maintainer? Does this place too much of a burden on people contributing mainboards? * Julius: This may be a bit extreme. If we remove things that haven’t been tested in the last 6 monts this will remove most of the tree. * Martin: Can chromeos test all of their boards. * Answer: Not really. * Julius, David: There is an advantage to maintaining old mainboards that keep us away from focusing on specific architectures. * Also, people interested in porting coreboot to a board will look for examples. This could be some random embedded single board computer, or an experimental work done for a new architecture (POWER9 work based on POWER8 work?). * Ron: Keep old code in the tree, but stop building it. Then it can be used as a reference.
### [dhendrix] Make GCC the official compiler of coreboot? [3] * This is basically simply continuing what we're doing now, but making it formal instead of an unwritten rule. * Julius: Just because some extensions are allowed (like dollar signs in names), we don’t need to allow them. * [Martin]Should coreboot follow the linux kernel’s lead and look to switch to -std=gcc11 [4]? * The makefile is already specifying gcc11, so no change is needed here. We should document it somewhere though.
### [Martin] Proposal for handling platforms moved to a stable branch to make them easier to use: * Add all those mainboards back into the Kconfig in ToT, just with the branch name that they’re being maintained in and which host compiler is needed. * Offer to check out that branch if desired. * Branches are already being built by jenkins, so patches can be pushed directly to the 4.11, 12, 14, 15, and 4.16 branches. * Update buildgcc on those branches to pull the tools from the coreboot download site instead of the original sites. * Martin will implement and post for review.
### [Martin (Arthur)] SMM security fixes [5] * Backport to 4.14, 15, & 4.16 branches. * Martin will do releases of the branches after the fixes are in. * Should this have gone to the security mailing list instead of the general mailing list? * Probably. Arthur looked for the security mailing list, but didn't find it. * Add to the mailman interface page? Is this possible? * Patrick will look at this.
### [Martin(Arthur)] Deprecate lb_serial uart_pci_addr field [6] * How does this help us? * It removes ugly code. * We’d still want to keep the field in the structure so that a payload that uses it doesn’t misinterpret the field. * Make this field reserved.
### [Jay]: Martin, any sign of the ITRenew server? * No, still no signs of it. :-(
### [Martin] New page at coreboot website: Help the coreboot project. * Add small projects * Add requests for testing. * Make it easier to test things. * FelixH: Build an image, post coreboot output & dmesg output and have this parsed and added to the test list. * Replacement for board status. * Don’t need to check out the 2GB git repo. * Paul will take a look at how to download less. * Script doesn’t always work. * Felix s: Add a control server that allows distributed testing of mainboards for people. * Need to be some sort of authentication mechanism for pushing - git serves this purpose. * David: Make a branch that can be checked out. * Martin has a script that will remove old versions.
### [FelixH] Can we add oauth authorization to redmine? * FelixS: There’s a plugin, but it’s not officially supported. * FelixH: is there a bugtracker that better integrates with gerrit? * FelixS: we can look, but redmine has the best interface in my opinion, and it is very customizable. * FelixH: Not suggesting switching, but it's a hassle to use separate credentials.
[1]: https://sovereigntechfund.de/en [2]: https://okfn.de/blog/2022/03/stf-offener-brief/ [3]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/message/3C2Q... [4]: https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.18-C11-Plan [5]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/PAT6C... [6]: https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/RYKUJ...
# 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.
Dear coreboot folks,
Am 20.04.22 um 22:49 schrieb coreboot org:
# 2022-04-20 - coreboot Leadership
[…]
- Patrick will look at adding the security mailing list to the page at [http://mail.coreboot.org%5D(http://mail.coreboot.org)
Patrick already did that during the meeting [1].
Security security@coreboot.org first point of contact for security issues
Kind regards,
Paul
PS: Martin thank you for leading the meeting (and writing(?) and sending out the minutes).
Apr 20, 2022, 14:49 by coreboot.org@gmail.com:
# 2022-04-20 - coreboot Leadership
## Decisions
- Martin will do an example of Kconfig where the platforms have been removed
keep the mainboard names in the tree. When selected, it will show the branch where the platform is maintained. We can also include the last known good commit for current mainboards.
Please take a look at the proof of concept patch I've posted at coreboot.org and let me know what you think. The code's not much to look at - it's better to actually test it.
https://review.coreboot.org/c/coreboot/+/63754
This is supposed to address the issue that after a board has been moved to a branch, it's basically dead. By keeping the boards in the master branch's Kconfig and showing the user what to check out, hopefully this should simplify that issue. It's not a complete solution, but hopefully it's seen as a step in the right direction.
Take care,Martin
Hi Martin,
Martin Roth via coreboot wrote:
..
It's not a complete solution, but hopefully it's seen as a step in the right direction.
Thanks a lot for this.
I think that this really helps with visibility while guiding people at the same time. Great idea!
I have some comments: (apologies for not using gerrit)
* Managing expectations
"Run the command 'git checkout $(CONFIG_MAINBOARD_BRANCH)' to build this board."
The git command doesn't build anything, so maybe ".. to switch branch." or ".. first and then re-run Kconfig to set up your board." or somesuch?
* Most of src/Kconfig now seems excluded for branch boards, maybe:
if MAINBOARD_SUPPORTED_ON_BRANCH source "src/mainboard/Kconfig" source "site-local/Kconfig" else # everything endif
rather than multiple if-endif statements is less confusing? (Yes, the duplicated source lines aren't great, but maybe okay for two lines?)
* Branch names
Newer git branch names look like "4.11_branch" so src/Kconfig and Kconfig.branch saying "(supported on 4.11 branch)" could really trap people, especially with "4.11" being a valid git tag.
But including the branch name also in the bool description is already redundant and could conflict with select _ON_BRANCH_*.
I really like the comment idea in src/Kconfig to connect _ON_BRANCH_* configs with the branch name only in a single place!
Do you see any way to avoid all the "(supported on * branch)" instances, while still making the information available in the vendor menu? Hmm.
* Having both Kconfig.name + Kconfig.branch
The idea is for SHOW_BRANCH_SUPPORTED_PLATFORMS to gate board visibility in Kconfig for "forward-movers", right? (Maybe name it _SUPPORTED_BOARDS btw.?)
IIUC the "if SHOW_BRANCH_SUPPORTED_PLATFORMS" logic would need to sometimes go into Kconfig.name (all boards on branches) and other times into Kconfig.branch (only some boards on branches), that seems a bit fiddly.
Might it be better to only use Kconfig.name and not introduce a new Kconfig.branch?
And maybe it would even be better to introduce this SHOW_BRANCH_SUPPORTED_PLATFORMS in a commit of its own?
Thanks again and kind regards
//Peter