# 1 December 2021 - coreboot Leadership Meeting Minutes
## Attendees Felix Singer, Martin Roth, Werner Zeh, Patrick Georgi, Julius Werner, Eric Peers, Tim Wawrzynczak, Matt DeVillier, Felix Held, Stefan Reinauer, Jason Glenesk
## Key Decisions * coreboot is interested in doing GSOC 2022, but needs to find a primary admin. * Fundraising for coreboot projects is allowed, but will not be sponsored by the coreboot project. * Deprecation of AGESA ports depends only upon not fixing the features being depredated, and will not be done if the chips/boards are updated. * Discussion about deprecation requests and port requirements needs more discussion.
## Agenda / Minutes * [David] This meeting overlaps with the Open Source Firmware Conference, so expect a light turnout: [https://talks.osfc.io/osfc2021/schedule/#2021-12-01%5D(https://talks.osfc.io...) * May need to postpone or continue discussions on Dec. 15.
* [Patrick] GSoC 2022? * They allow “short” (175h) and “long” (350h) projects now, so the reason why we skipped applying in 2021 (only short projects) is gone. * Open to everybody 18 years or older who didn’t already participate in GSoC twice. * Participants may not work with projects where they made non-trivial contributions already. * Flashrom wants to participate apparently. Maybe as a separate project, if that doesn’t work but coreboot makes it, we could take them under our umbrella again like we did in the past. * Who’s willing to admin? * [Martin] I’m willing to help, but I don’t want to be the primary admin. * [epeers] Can help too but not as primary. * Martin to ask on mailing list
* [Piotr] AGESA-based ports * It looks like a decision was already made, so I just want to tell my point of view. * [Martin] I don’t think that it’s decided yet, especially if there are reasons not to make that decision, so yes, let’s discuss it. I do think that there has been a decision that there will be deprecations at some point again, but not necessarily this code yet. * [Felix] Do we just need the patches that are already in gerrit to keep the platforms alive? * [Piotr] Maybe, we don't really know what the criteria are. * The Proposed changes build bad marketing and may affect contribution level: * Why OEM should sponsor maintenance when total cost of ownership is unknown and subject to spikes? * Why should IBV/IFV/OSFV contribute code to upstream, if the cost of keeping it there can be infinitely increased by design decision out their control? * [Patrick] Why should the community accept contributions if their side of the deal is supposed to mean "maintain it forever, for free"? It's rather simple to dead-lock this debate. * [David] I can't speak for all cases, but AFAIK these maintenance agreements usually come with a timeline. * [Piotr] 10 years for embedded and Intel coming with 15years supported platforms * [David] 15 years ago coreboot was LinuxBIOSv2. What you're suggesting here is unreasonable. Things change in master. Don't base your support contracts/obligations on master. * [Martin] What are the possible alternatives? * Any code put into coreboot is going to need to be maintained by someone, that will need to be either the original contributors, or by people trying to add new features. * Branching model looks like UEFI closed source development model, which proven to be wrong many times (lack of bug fixing across branches, lack of backporting) * This was already said by me couple times - “Disagree and commit” * It will lead to problems mentioned [in this presentation](https://talks.osfc.io/osfc2021/talk/D9X39Z/) and [Alex tweet about UsbRt](https://twitter.com/matrosov/status/1465863974310744064) * [David] Is bitrotting code any better if it's in master than in a branch? * How does an individual or company know that a board will work? Do they checkout master and potentially bisect thousands of changes until they find the last working commit? * [Piotr] This applies also to master branch, there are no guarantees on branches as well as on master. So no one ever can be sure if platform works, however we define works, since coreboot does not provide such guarantees. * How do well-meaning community members refactor code without ability to test on real hardware? * [Piotr] There are Linux kernel parts that nobody can confirm works eg. at some point I tried Marvell Armada 8k crypto engines, but I'm not aware of any activity of hardware support removal because of that. * We need to do a better job of advertising when a board was last known to work. board_status was supposed to help with this, but has its own problems and is not used very often. * 100% agree and 3mdeb will support that effort if agreement about direction would clearly stated - we had that discussion many times at OSFC'20 as well as on vPub. * [David] OTOH, having a variety of SoCs, mainboards, and architectures in the master branch is a huge advantage coreboot has in this space. None in the x86 world come close to the universal extensible firmware _implementation_ which is coreboot ;-) Let's not take that for granted. * Leaving boards on branches means they can die just because of lack of toolchain for building - I’m not sure how likely it is, but we can check how far in the past we can go and still build a toolchain that gives working coreboot.rom. * [David] coreboot builds its toolchain specifically to avoid problems with toolchains. Bitrotten code compiled with a new toolchain may encounter difficult-to-debug issues. This is actually a case where leaving old targets on branches may help, since the code and toolchain will be known to work together. * [Martin] There are builders set up with the older toolchains. Toolchains back to at least 4.10 can be built on current debian/ubuntu systems with the command: CC=gcc-8 CXX=g++-8 make crossgcc CPUS=$(nproc) Note that(4.10 does fail when building make, but current systems use a version of make that works. And yes, I tested this yesterday after seeing this comment. :) Older toolchains can also always be built using the OS versions that existed at the time the system was released. If we need VMs of these older releases, we should make them and post them for download. Right now, compiling still gives some errors even with the correct toolchain due to errors compiling the tools with the new host compiler, but we could either fix those errors in the branch or work out how to configure HOSTCC to get everything compiled with gcc-8. * [David] How to balance maintenance with community resources? * Even if time weren't a factor, lack of testing ability and access to documentation make it difficult to guarantee that code clean-ups don't break things. * coreboot is a hardware-oriented project and that means dealing with hardware scarcity, NDA'd docs from vendors, etc. * Some hardware is simply obsolete. Even with the best of intentions, the amount of work needed to maintain certain targets can never pay off since the hardware is unobtainable (old vendor reference boards, for example). * [Piotr] My points are not about old hardware that nobody has and want support.
* [Felix S.] Tree-wide change [CB:39331](https://review.coreboot.org/c/coreboot/+/39331) * Makes PCI ID defines a little bit shorter without losing information * Any objections on this? * This looks good. The commit message tells how to reproduce the patch instead of cherry-picking it.
* [Felix] Let's set up meeting for this time next week to discuss the jenkins builder replacement.
# 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.