- Check the mailing list on Narchive or Hyperkitty
- REMIND FOLKS ON IRC JUST BEFORE THE MEETING STARTS
- Conference call uses Google Meet (doesn’t need a Google account)
2 June 2021
Attendees:
Agenda:
- Open Source Firmware Foundation - Participation [9e]
- Make romstage and/or postcar optional [Arthur]
- Linking romstage in the bootblock makes it smaller + similar to u-boot SPL
- Doing CAR teardown in ramstage reduces need for a full extra stage to just run ~100LOC
- Some potential issues with CAR teardown in ramstage:
- LZMA decompression on uncacheable memory (can be cached but more tricky) is slow
- LZMA decompression requires more stack (postcar was uncompressed)
- Add stuff here, and please tell us who you are, so we can hand off the mic to you during the meeting
19 May 2021
Attendees: Arthur Heymans, Christian Walter, David Hendricks, Eric Peers, Felix Held, Felix Singer, Jason Glenesk, Marshall Dawson, Martin Roth, Matt DeVillier, Patrick Georgi, Philipp Deppenwiese, Piotr Król, Ron Minnich, Tim Crawford, Werner Zeh
Agenda:
- Freenode (our IRC network) is doing weird things right now. Shall we move? Where? [Patrick]
- Some useful links which might help understanding what’s going on:
- https://kline.sh
- https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409#ok-so-whats-going-on
- [FS] TLDR: In 2019, Freenode Ltd. has been sold to Andrew Lee as part of a sponsorship deal. Part of that deal was that A. Lee would neither obtain nor exercise operational control over the network, and that it would continue to be run independently by the volunteer staff. Since the beginning of 2021, A. Lee made decisions without discussing these with the staff. Christel, the former owner of the freenode.net domain, sold the domain to Freenode Ltd and now A. Lee is trying to take over the control over freenode. According to the former freenode staff, he has malicious intentions.
- Most of the former freenode staff is building up libera.chat now
- Alternative IRC / chat networks:
- hackint.org, an IRC network which is maintained and run by many volunteers of the CCC community. Also, known projects like freifunk.net, gluon or archiveteam.org live there. Servers are located in Germany and Netherlands, while services (e.g. ChanServ) are hosted in Germany.
- 3mdeb uses self-hosted Mattermost, but also has some good experience with Matrix
- Purism uses Matrix, Android client is fairly good
- AI Patrick: Put up on the mailing list to see if there are any hard objections to dropping IRC in favor of Matrix or Mattermost hosted on coreboot.org.
- Expectations on “core developers” on Gerrit who have submission rights (see last meeting). Open proposals (with draft text): [Patrick]
- Add expectation to go through submittable patches regularly
- Add the possibility of losing the role after a sufficiently long time of non-use (should we specify anything?)
- David and Werner found it reasonable (as long as dropping rights only happens after “years”, plural). Submitted.
- 8 people with submit rights haven’t merged anything in >2 years.
- How to spend our donation money? (see last meeting) [David]
- Should we define strategic project goals and collect earmarked donations for them?
- How to define them?
- How to hand them to vendors fairly?
- Goal: How do we prove to donors that their money will make a positive impact on the project?
- Should we run something like Summer of Code for coreboot?
- How can we finally pay for work that nobody wants to do in their spare time and that isn’t done by vendors and large corporate members due to time constraints? 3 attempts fell through…
- David: Should we spend on IBVs instead of maintenance contracts since all individual developers seem to be poached by coreboot using vendors ~immediately?
- Could deal with vendors under NDA, e.g. to help with launch-day availability of chipsets.
- Can we even do that and remain non-profit? It would skew the market if one vendor has to pay for their upstreaming & maintenance while another doesn’t.
- Apu2 was merged without major problems
- Apu1 we face pushback related to state of vendor code
- This is related to long thread about stable releases, QA etc.
- We have a policy in coreboot that touching code doesn’t require you to clean it up. In case of AGESA, clean-up would be highly appreciated, but we deviated from entry quality criteria back then (on promises made by AMD, then broken) and sadly that’s on us. Lesson learnt: don’t let quality slip on entry “because it’s maintained” (although we have different situations and challenges now, with pre-release code landing where the hardware underneath is still changing)
- Should we have a marketplace/kickstarter/bounty platform to connect vendors and users/customers? [Patrick]
- Would vendors appreciate having something like that? If so, what exactly?
- We’d have to see if users/customers accept any such platform
- What terms? (we should avoid providing opportunities to low-ball corporate projects through that, or vendors naturally won’t be interested)
- NDA reference spotted by undisclosed AMD employee claiming that it is not the wisest thing refer to, bottom of following page [Piotr]
- https://doc.coreboot.org/soc/amd/psp_integration.html
- This documentation was pushed by Marshall Dawson, an AMD employee.
- We do link Intel NDA Documents referenced by number all the time in commits.
- [marshall] This was crafted by PSP+coreboot devs to be pushed to open source.
- 3mdeb preparing to start sending patches for POWER9 [Piotr]
- coreboot has huge advantage over hostboot in terms of boot time
- ~13k SLOC (bootblock+romstage)
- Patrick: stuff should continue to build and there should be a mainboard that exercises the new code
- Arthur: reproducible builds if possible
- Felix: separate out changes to architecture/chipset independent code so it can be reviewed separately
5 May 2021
Attendees: Christian Walter, David Hendricks, Felix Held, Felix Singer, Jay Talbott, Martin Roth, Patrick Georgi, Piotr Król, Werner Zeh, Stefan Reinauer, Matt Devillier, Marshall Dawson, Rocky Phagura, Eric Peers, Ron Minnich
Agenda:
- Directed donations for coreboot - Should we define causes that people can donate to in order to direct work? For example a KGPE-D16 fund, Thinkpad fund, RISC-V fund, NPI fund, UEFI interoperability, testing fund, etc? [brought up by David Hendricks]
- Causes must be written up such that it's clear how they improve the project and are aligned with the goals of the SFC. Ideas for this will likely need SFC review to ensure tax law compliance.
- This will help enable the organization to contract work for projects that will substantially improve coreboot for the benefit of the community using tax-deductible donations.
- Example: Re-upstreaming and maintainership of the KGPE-D16 - Cost: 30 000E and counting (https://github.com/osresearch/heads/issues/719)
- (Earmarking money means it’s hard to move it to other purposes)
- Excess funds go to general fund
- Donations default to the general fund
- When creating such projects, we’d have to create some open tender process so projects (== project’s money) are allocated fairly
- How would be define and select projects: Do developers propose things they would work on (+ a price tag, or a fixed rate?) and then the project (who exactly?) decides on which to take on?
- With a set list of projects, should we have a process where candidates can send offers privately and leadership decides which to use? The dynamics between our various contractors and coreboot service providers could go sour if things are too visible but also if they’re too opaque.
- coreboot.org won’t be able to pay Google, Facebook, etc rates so how can we avoid that this is just price dumping? (“Hey $provider, how about you do this thing for coreboot.org that would be nice for $corp to see done, but at half the price?”)
- Christian: bidding platform is problematic from the POV of a vendor because the risk is down-bidding and can also mess up the community dynamics.
- Losing bids -> less interest in reviewing code for free that is contributed by the winner (even though other bidders on a task are probably best suited to review that particular work)
- Werner: paying for work might be best for stuff that nobody wants to do at companies for time reason (e.g. vendors) or for free because it’s not interesting (community)
- Martin: Should we talk with the SFC? They might know about other projects’ experience.
- Should we add an expectation for “core developers” to go through mergeable changes on gerrit regularly?
- If half of all core devs (currently ~30 total) take on 2 “ready” changes every 2 days, that’s 15 CLs a day that somebody takes care of that otherwise would linger around.
- Should people lose the core dev role if they review too little commits by others?
- Don’t come with the ban hammer just because people are busy
- Could just nudge people who weren’t around, they might not even be aware that they’re still on the list. Or it brings them back.
- Martin will email people who haven't submitted much in the past year.
- [epeers] Can we automate this? Send out a note for folks that are not reviewing, also send out opportunities every 2 weeks for folks “falling behind” to get the nudge.
- Badges and bragging rights for doing valuable community work?
- Gerrit roles again: Paul Menzel proposed that any core dev can appoint another developer as core dev, without going through the leadership meeting. Yay? Nay? [brought up by Patrick Georgi]
- Requirement of leadership discussion protects core devs from outside pressure to add folks
- Doesn’t need a huge “vote” or anything, in the past we had a few folks brought up in the meeting and it was a short discussion, followed by “yes” by leadership. Patrick expects the impact to be mostly that leadership gets a rarely exercised opportunity to veto
- Martin thinks that if we go there, core devs shouldn’t be allowed to add folks, restricting that action to Gerrit admins instead, to avoid mistakes and confusion.
- Nobody in the meeting thinks that having a quick vote in the meeting is a problem, so Patrick will keep that part in the proposed documentation update and will defend it vigorously.
- When would be a good time to update our GCC version? GCC 8.3 is a couple of years old, and doesn’t have optimizations for many of the newest processors. As GCC 11.1 was just released, maybe it’s time to look at updating?
- Right after coreboot 4.14 release, planned for May 10
- Should we have entry criteria for updating the toolchain? Let’s collect them in a doc going forward so we know what to look for in future updates
- Martin offers to set up a build job on qa.coreboot.org that builds on the latest GCC weekly, and we could even test it on 9esec’s test lab (Christian agreed) so see that it still boots.
21 April 2021
Attendees: David Hendricks, Felix Held, Felix Singer, Jason Glenesk, Jay Talbott, Marshall Dawson, Martin Roth, Matt DeVillier, Patrick Georgi, Piotr Król, Tim Crawford
Agenda:
- Directed donations for coreboot
- Gerrit roles
- Should we have a gerrit role with submit permission only for the parts of the tree they’re listed for in MAINTAINERS? (Gerrit should be powerful enough for that, but it’s a non-trivial investment to hook it all up) [brought up by Patrick Georgi]
- Is there any problem that this is addressing?
- Not urgent, but seems like a good idea?
- Might be easier to be a maintainer for a specific thing rather than a core developer for everything
- Martin: People should be trusted to push everywhere if they can push anywhere
- Incentive for people to register themselves and maintain the MAINTAINERS file
- There are a significant number of changes that only modify mainboard code, for example update a device tree
- For somebody developing a mainboard, they might need to touch files in mainboard, arch, soc, vendorcode, util, 3rdparty, etc…
- Decision: no need to implement that right now. We can revisit that decision at any time.
- coreboot should better support work outside the tree, for both mainboards and SOCs. Currently the only viable way to work outside the tree is from a static pull, such as a release, otherwise your code is almost certain to not work after a few months. Since we require stringent rules about working within the tree because once it's in, it must be maintained by the community, it should be easier to work outside the tree. We should have more stable interfaces. [brought up by Martin Roth]
- Intention is to make it easier to upstream support for new hardware which was likely developed on an internal fork.
- Maintaining ports is difficult upstream due to things like variable name changes.
- Options?
- Formalize APIs?
- Document sweeping changes to the tree, ideally with automated steps that can be reproduced on outside trees. We had something like that in the past: Flag Days
- Make API changes during windows, for example every release
- After next release: AI Martin or Patrick: set up a weekly builder that tries last-release’s mainboards against current ToT rest-of-tree (ie. checkout, git checkout $last_release src/mainboard, build)
- Propose change to gerrit guidelines that sweeping changes should be documented by the author in release notes, ideally with instructions on how to reproduce them.
7 April 2021
Attendees: Angel Pons, Arthur Heymans, Christian Walter, David Hendricks, Felix Held, Jay Talbott, Marshall Dawson, Matt DeVillier, Michał Żygowski, Patrick Georgi, PaulePanter, Ron Minnich, Stefan Reinauer, Tim Crawford, Werner Zeh
Agenda:
- We should document the expectations we have of “Reviewers” (CR+2) and “Core Developers” (Submit, CR-2) on gerrit, and the process to get into one of these groups. What are they, exactly?
- Currently: Reviewers: People who can +2 / -1 changes. Contributors with more activity than a one-off commit.
- “Talk to a Core Developer”
- Number of commits, quality of activity, time frame of activity matters
- Currently: Core Developers: Experienced coreboot developers. Gives -2 and submit rights. Reserved for core developers.
- Bring up proposals at the Leadership meeting (item on the agenda suffices), will be discussed and voted there
- We can decide on code checking more granularly than just vendorcode or not
- Patrick thinks it’s also a matter of recognition: vendorcode is “to the side” while code written by coreboot developers for coreboot
- Other stuff in coreboot comes from outside (lzma, x86emu), should this be vendorcode?
- util/ predates src/vendorcode, probably a few more things could be considered for relocation if we're going to draw a line
- Not having braces around single statement if blocks? Ron’s friend doing security was speechless for 10 seconds
- The main saving grace for avoiding those braces is compatibility with Linux coding style, but we already deviate from that (plus: should we follow GNU style because GRUB2 devs also overlap with coreboot?)
- checkpatch is a pretty stupid tool
- Community TPM (Technical Program Manager):
- David making slow progress, needs to chat with Mike Banon
- If doing this with Mike Banon, he’d prefer doing this through 3mdeb because they have a process in place already
- Possible tasks (as discussed earlier):
- Single Sign-On between gerrit / jenkins / redmine
- Integration between gerrit and issue tracker
- Help with releases (or at least release notes & announcement)
- Help keep patches on gerrit moving forward (e.g. ping the right people, not patch up other people’s patches)
- Late April-late May timeframe
- Anybody interested in being a release maintainer?
- Will be done by Patrick or Angel if nobody else steps up
24 March 2021
Attendees: Arthur Heymans, Christian Walter, David Hendricks, Eric Peers, Felix Held, Jay Talbott, Jonathan Zhang, Lynxis, Matt DeVillier, Michał Żygowski, Patrick Georgi, Patrick Rudolph, PaulePanter, Stefan Reinauer, Tim Crawford
Agenda:
- Community TPM - Somebody to work a few hours a week to update bug tracker, etc. (things we discussed at the previous meeting)
- We have a community TPM: Mike Banon, works for 3mdeb as their community manager. Might be interested in contributing/sponsoring. Could hire him for a few days a week. Help ping bugs, close stale ones. Could help determine priorities / help newcomers / improve documentation.
- What does the work for 3mdeb entail?
- Mike is the community manager. Promoting various events on social media. Publishing achievements. Writes blog posts from time to time.
- Are you fully utilizing his time? He’s pretty busy, working part time, ~10h per week. Should we be mindful of taking his time?
- What does TPM mean in this context?
- Tracking items on issuetracker and pinging people.
- Release notes for new versions of coreboot
- Complement the previous idea, rather than monitoring gerritt and reviewing patches, this is more proactive to get people working on patches/issues.
- Previous bug tracker convo
- Would it help if a new issue is created to CC it to the mailing list?
- Patrick to take a look.
- StefanR - I never get email from the tracker. This would be super useful.
- Michał - could this be too noisy?
- Handful of emails - keep it on one list. If we need to we can fork it out.
- Jenkins got stuck running coverity. Builds again, but fails to upload to Coverity Scan.
- Paule: Can we say strong thank you to Angel Pons?
- Strong contrib to irc, reviews, gerrit.
- Google has a gift card for outstanding open src development (internal link: go/opensourcepeerbonus). Patrick to check if we’ve maxed out the money for that program.
- This is per recipient. But rules change all the time.
- When giving a (monetary) thank you that others might not receive, may result in degradation of community
- Christian: We are supporting his work now. Mostly working on Coreboot. But a thank you from the community would be well received.
- Open compute summit/tech week coming up?
- In Sep/Oct.
- By end of march 21, we will have ocp/osf checklist enforced. If you don’t pass, then vendor submitted won’t get accepted status. There hasn’t been any fw available for those servers. Bar to adopt is quite high. Have both fw and hw submitted together helps. Intel announced they will be making binaries for cooperlake public with redistribution license -- this in a few weeks. We will see end2end server product with coreboot - from coreboot master branch.
10 March 2021
Attendees: David Hendricks, Felix Held, Jay Talbott, Martin Roth, Matt DeVillier, Michał Żygowski, Ron Minnich, Stefan Reinauer, Tim Crawford, Werner Zeh
Agenda:
- GSoC - Coreboot not accepted this year.
- Documentation
- Who is looking using it?
- Is there a Gerrit plugin to integrate the bug tracker with code review?
- And hopefully reduce redundant account management
- Any good ideas on how to manage this?
- People often have to deal with multiple bug trackers (e.g. from their employer) and manually maintained lists
- Can we manage it similarly as with Coverity?
- Would this be a good use of coreboot.org funds - having a "community manager" that can follow-up on these things? If so, who?
- Does somebody want to volunteer to refactor it with better automation?
- Periodic e-mails to mailing list
- Gerrit integration?
24 February 2021
Attendees: Angel Pons, Arthur Heymans, Christian Walter, Daniel Maslowski, Eric Peers, Felix Singer, Felix Held, Jay Talbott, Martin Roth, Matt DeVillier, Michał Żygowski, Nico, Patrick Georgi, Rizwan Qureshi, Ron Minnich, Stefan Reinauer, Tim Crawford, Werner Zeh
Agenda:
- Where’s the line between blobs that are put in 3rdparty/blobs and blobs that are put in mainboard/soc directories?
- Should redistributable binaries that contain configuration data for a core that runs on a separate non-x86 core in the system before coreboot runs be put in the blobs repository or in the mainboard folder of the main coreboot repository like it is done for the vbt on some intel platforms?
- Vbt’s are purely data and documented.
- current case: the apcb files that contain information on for example how the ram is connected to the memory controller
- Apcb are mainboard specific. They currently live in blobs directory, they are redistributable. They are 8-12KB.
- Without documentation on what’s in the apcb, keep it in the blob directory?
- These are generated. Can we rebuild a tool that generates them?
- Would not be trivial to do this.
- Do we have a proper blob directory structure for mainboard dependent blobs?
- Goes in mainboard/vendor/board_name - mirrors the mainboard tree.
- Can we get a version number + documentation on sourcing for any of these blobs?
- Also needs a license.
- Some were simply extracted. May not be easy to get changelog.
- Desire to get rid of this repo long term because it has become a dumping ground. Get to a more specific repo structure.
- Conclusion: keep them in the blobs directory
- Size is small enough for mainboard
- No format specification implies blob though.
- Get license and versioning (changelog) for APCB’s. AI: Felix Held.
- Since it’s pure description (ie. just one way to put it), there may not be copyright for it. Instead of a license, a statement to that effect would suffice as well.
- Mainboard documentation is sparse. It does not include how-to-build. Setting this up so that it is all in one location would make it easier for an end user.
- Linking to main build steps would be reasonable.
- Duplicating instructions is painful - causes doc explosion and maintenance problems.
- Can we include one file inside another? (structured text). See sphinx suggestion by Patrick below.
- Favorite boards are also missing documentation altogether.
- Having a template would help
- Google could potentially help with documentation - either with tech writers or with engineering grass roots.
- What about writing documentation?
- If we do the technical legwork to bring in templates, who will use it?
- Is the hurdle to contribute documentation too high, e.g. the git/gerrit workflow?
- We did that for good reasons, as the wiki was a trash fire and always out of date
- Martin or Eric to contact technical writers
- Martin will look at adding a lint tool to restrict file sizes and dimensions. Restrict to PNG, JPG & WEBP?
- Patrick to look into templating to get a common structure for board docs
- Patrick to write documentation on how to crunch images suitable for our site
- Location: Austin (TX), Santa Rosa (CA), or Santa Clara (CA)
- Location: Seattle (WA) or Cupertino (CA)
- Location: Europe / Remote - or Germany, Bochum
10 February 2021
Attendees: Angel Pons, Arthur Heymans, Christian Walter, David Hendricks, Eric Peers, Felix Held, Felix Singer, Jay Talbott, Marshall Dawson, Matt DeVillier, Michał Żygowski, Nico, Patrick Georgi, Tim Crawford
Agenda:
- Style guidelines: Felix commented, "I'd like to have the "Do not unnecessarily use braces where a single statement will do." from the coding style guide removed; saw a patch that removed those and I don't consider that a very good idea, since that sort of things has caused or at least masked bugs[a]. I don't think that we should mandate curly braces there, but I don't think the coding style guide should discourage people from doing things that possibly avoid trouble"
- It aligns our code with Linux, so we can copy stuff more easily
- Arguments against this policy:
- It’s dangerous when statements are added into missing braces (that is, outside the statement)
- Do we need to document deviations from Linux style? Do we even follow Linux style anymore?
- Clang-format all the things!! (AI: Patrick)[b][c]
- And flashrom too? (AI for somebody else)
- Use braces everywhere then, consistently
- Replace CONFIG(CHROMEOS) with more fine-grained guards
- Presence of ChromeOS GNVS might be better if named VBOOT_GNVS
- With MAC stored in RO_VPD, is CHROMEOS the proper guard there either?
- There are cases where booting non-ChromeOS OSes on Chromebooks need to disable certain features, for example "CSE lite" firmware (?)
- Let’s make feature flags more fine grained when they’re more generally useful!
- Bring such issues with Google folks active on that chipset or Patrick Georgi
- Make non-chromeos abuild builds fail if configurations carry CONFIG_CHROMEOS to ensure we test both configurations (and enforce that boards can be built without CrOS support). Done: https://review.coreboot.org/c/coreboot/+/50494
- [prev] APAC friendly time meeting for coreboot - AI David Hendricks.[d]
- TBA due to Chinese/Lunar New Year
- [prev] GSoC 2021? Org application deadline is 19 Feb
- Previous projects have been too broad in scope. Led to failures.
- Eric Peers (will also raise in his weekly staff meetings)
- Marshall Dawson
- 9elements ( one student - somehow )
27 January 2021
Attendees: Christian Walter, David Hendricks, Eric Peers, Felix Held, Marshall Dawson, Igor Bagnucki, Werner Zeh, Tim Crawford, Patrick Georgi, Jay Talbott, Selma Bensaid, Stefan Reinauer, Stef van OS, Rocky Phagura, Ron Minnich
Agenda:
- Missing SPDX license identifier. How to proceed with CB:47967?
- Patrick will look into finding the right SPDX identifier
- amd/cezanne and timing of PCIe training
- Kick off PCEe training in romstage since it is managed by the SMU. This will help reduce boot time.
- Any showstoppers?
- Is there precedent? Yes - in displays as an example. Things that take 10's or 100's of milliseconds to initialize/train (e.g. due to necessary delay periods) can be started early on and revisited in ramstage
- Is this link training? Yes. Isn’t link training performed by the agents on their own? Enabling the root port is probably the issue and what takes so much time. Might even be able to do it earlier. Should be ok though to enable earlier.
- Marshall will put together a proposal and send to the Mailing list.
- Follow-up on Jan. 13 item - move meeting minutes to cryptpad?
- Patrick sent an e-mail to the list
- Feedback received:
- Need better compatibility with textmode browser
- Put stuff in git repo? The main issue is that we want one source, don't want people trying to add stuff for upcoming meetings to git repo.
- 3mdeb virtual happy hour: Feb. 18, 4pm UTC+1
- Open compute will try an APAC friendly meeting on Wednesday evenings (US time)
- Some of the same people attend, so we should avoid meeting conflict if possible
- Summer of code applications start in 2 days.
- David offers to co-admin but not alone
- Martin might be interested to help. David and Martin will sync offline.
13 January 2021
Attendees: Angel Pons, Christian Walter, David Hendricks, Eric Peers, Felix Held, Felix Singer, Jay Talbott, Jonathan Zhang, Marshall Dawson, Matt DeVillier, Michał Żygowski, Patrick Georgi, Rocky Phagura, Ron Minnich, Sharma Sharma, Stefan Reinauer, Tim Crawford, Werner Zeh
Agenda:
- Archive 2020 leadership meeting notes (similar to what we did for 2019)
- Should we move the minutes to cryptpad.fr as an alternative to Google Docs?
- Need time to evaluate
- It’s open source
- Do we need to run/admin our own instance?
- Spam mitigation? People don't need accounts to edit content. How do we prevent trolls/spammers from abusing it?
- Backups?
- Maybe about other alternatives, like putting the notes in a git repo?
- Is this all worthwhile to satisfy a small handful of people? Odds are that they'd find faults with any number of things (Google being involved in Docs, Microsoft being involved in Github, etc)
- What's next? They might still be dissatisfied with the videoconferencing system. A couple people had problems with Jitsi because it's inefficiency (doesn't scale well)
- Solution in search of a problem? Let’s bring it to the mailing list (so we don’t self-select for people using Google services), but opponents to the Google services will have to make a good argument for an alternative and drive it. (Patrick sent the email 3 hours after the meeting.)
- Should we do coreboot meetings in an APAC-friendly timeslot? If so, should it be one meeting that tries to work across US/EMEA/APAC time zones, or split them into US/EMEA (the current times lot), US/APAC, and EMEA/APAC?
- There are Asian coreboot users but they have little chance to participate here
- Again: mailing list? People who would be interested in APAC-friendly times won’t be in our meeting. AI David to send an email to gauge interest[e]
- Kyösti and Martin had 6 months of timeout on Gerrit. Should we reconsider?
- It's been quite some time and things have cooled off. Let's "bury the hatchet." Welcome back!
- Developer permissions on Gerrit have been reinstated, Stefan sent a “welcome back, now behave” email 2 hours after the meeting.
- Summer of Code 2021 is opening for org applications Jan 29. Do we want to apply? Who manages it?
- Patrick doesn’t have the capacity to drive it this year
- Werner and Patrick already had students asking
- Application is in > 2 weeks, so there’s another leadership meeting. People can consider and we can discuss next time
- David would consider co-admin, but can’t do the main job. If you’re interested, reach out to him
- Firmware Testing in coreboot - Update
- There’s Lava and Contest, 9e wants to merge their reports that go into Gerrit (and possibly board-status?)
- 9elements has their QA system working with OCP Delta Lake and Tioga Pass
- FOSDEM next month: talk about OS firmware testing, maybe some discussion on how to attach their own test system? (btw: FOSDEM is virtual, so Belgium being far away is not an excuse this year :-) )
- Q: is there a way to lease a device in the test system for testing? With a QA system we already have all the moving parts (e.g. recovery from a bad flash). A: not now
- Update lynxis sub-contract
- Didn’t work out, Lynxis found better opportunities, so had to drop out
- Looking for somebody who could take over the maintenance contract, again.
- SFC, David and Stefan prepared all the paperwork so it should be much faster now.
- OCP OSF submission of Quanta/Wiwynn Yosemite V3 server system
- Submission in progress with OCP, which will include:
- coreboot tip, Intel ignition FW (for ME) and FSP
- Delta Lake uses Intel Cooper Lake SP CPUs (Similar to Ice Lake SP)
Notes from 2020
Notes from 2019
[a]I know this is a few weeks old already and I wasn't in this meeting, but I just wanted to point out that the SUSPECT_CODE_INDENT checkpatch test can catch this kind of bug already. So I don't think it should really be a concern for coreboot development today (nor a justification to clang-format everything).
If you want to have style discussions I suggest moving them to the mailing list or Gerrit so the whole community can participate.
[b](AI: Patrick) @patrick@georgi.software
_Patrick Georgi zugewiesen_
[c]FYI:
In https://review.coreboot.org/c/flashrom/+/42556 I highlight some of the issues I found with clang-format on the flashrom codebase.
This file in particular shows the issue with structs that have one member per line for readability: https://review.coreboot.org/c/flashrom/+/38673/5/ich_descriptors.c#227
Those sorts of things might not be a deal-breaker, and as you pointed out there are special comments that can be used to enable/disable clang-format for certain corner cases.
[d][prev] APAC friendly time meeting for coreboot - AI David Hendricks. @david.hendricks@gmail.com
_David Hendricks zugewiesen_
[e]AI David to send an email to gauge interest @david.hendricks@gmail.com
_David Hendricks zugewiesen_