# Decisions on 23th March 2022:
* Meeting times from not until November will alternate between two different times (to be voted upon) so that no one group will be excluded from every meeting. Time1 is EU+AU, Time2 is EU+US. * In the short term, any money collected for the Flashrom project, will be given to the coreboot project. coreboot will maintain a ledger for flashrom money. * We want a single build system (either Make or Meson). Anastasia will set up a separate meeting to discuss the “Makefile vs Meson” topic. * Next meeting will be in 2 weeks since there's still so much on the agenda.
# 23th March 2022, 21:00-22:00 UTC+0
**Attendees: **Thomas, Michal, Felix, Anastasia, David, Nico, Patrick, Edward, Martin, Carl-Daniel
**Agenda:**
* [FelixS] Before we start discussing new topics, anything we need to discuss from the last meeting? * Leadership question is relevant to the item below, about fiscal sponsorship * [aklm] Reminder: daylight saving time is approaching. Next time we will use this time (21.00-22.00 UTC+0) in November. * For the next occurrence of dev meeting, Felix will send a poll to vote on days/times for the interval Apr-Sept. * In October we can have a vacation from each other (because there is a month diff when DST happens in different locations). * Martin: Can we have a schedule where the bad time rotates? So one out of every 3 times is poor for 1 group, but better for the other two. * Will do alternating times until november. Alternating between EU+AU and EU+US. * [Martinr] Should flashrom look for a fiscal sponsor so that it can accept donations? * [aklm] (possibly related) As an organization we can get some money per successful gsoc project (around 500 USD IIRC). Where do we put it? A bank account? * That's exactly the issue. In the past, before coreboot joined the SFC, the coreboot project had no way to accept donations, so the money was just donated directly to the SFC. By joining a fiscal sponsor, that allows money to be donated to the flashrom project to be used for purchasing test equipment, boards, servers, or whatever is needed. * [https://opensource.com/article/19/1/fiscal-sponsors-open-source%5D(https://o...) * [aklm] I just (10/03) got this comms from gsoc orgs: “For orgs who need to change their financial details for GSoC 2022, the deadline to have all of your Payoneer account information completed is July 15, 2022 as described in the Program Rules. We will not pay out stipends to any orgs who miss this hard deadline. We'll send more details about receiving stipends etc. in May so you'll have 2 months to get everything in order.” * It takes a long time to join a fiscal sponsor, so if flashrom is going to join a group, we're probably looking at 2023. * [FelixS] Since there is no legal entity around flashrom, we would have to create one first or a private person needs to take the money for now. In any case, this brings a lot of complicated implications and work (e.g. taxes). Can we just transfer the money to coreboot? * Since flashrom currently shares the coreboot infrastructure, in the short term, combining the financial interests makes sense. In the long term, we might want to look at having the projects be more separate, and getting a fiscal sponsorship for flashrom itself. * aklm will ask gsoc organizers on a mailing list, to get official reply whether 2 orgs can have the same account. * [Patrick] SFC needs some point of contact that can make decisions (e.g. about spending project money), so that's where the "leadership" thing came from in coreboot. They also strongly suggest to have at least 3 people and to avoid having outsized impact of any particular company contributing which informed how we defined our leadership group make up. * [aklm] Meson and Makefile. For upstream, Makefile is officially supported and used by developers, Meson is only used for unit tests. For chromium, Meson is officially supported and used for everything, including tests. Logically, these two should be in sync, since they are building the same code. Each side is interested in one build system (the one they are using). Can we join forces and keep two build systems in sync? * [FelixS] Thomas is about cleaning up both build systems and bringing them closer. * [Thomas] I’m working on getting the Makefile in a readable and usable state. A lot of configuration was / is done by C preprocessor macros. I’m trying to get rid of those. Since the meson.build is mostly a copy of the Makefile I want to update it when the Makefile is in a good shape. Currently the meson.build lags support for non Linux systems. I personally would prefer meson as a single build system, but we are not at this point yet. * [Edward and Martin] we need to test builds in both build systems until a single build system is selected. * [David] Are there any fundamental differences between the two build systems that cannot be resolved? We need to do gap analysis * [FelixS] I think Thomas mentioned a few things that can’t be done with Meson, or which are harder to do, but AFAIK he is working on it adding this functionality to upstream Meson. * [aklm] Do we all agree that we ideally have one build system? * YES! * Why did googlers decide to use meson? * [Edward] we want to use libflashrom instead of subprocessing, and that was supported well by meson. Also I have experience with both, and IMO meson is easier to maintain. Makefile is more ugly to do configurations for boards. * [Nico] secunet uses it in combination with FILO for firmware updates * [Thomas] I did lots of readability improvements and rework, but would like to switch to meson completely. It would be good to work with google to implement meson as the primary (and eventually only) build system. * Aklm to set up meeting (in 2 weeks from now) about meson and Makefile work, google will happily join this effort. Aklm is a google point of contact for the effort. * [Nico] Is meson capable of doing everything that Makefile is doing? Is ninja available on all platforms? * [CDH] if everything works for meson, I have no preference. But if not everything is working, then everyone will be unhappy. * [David] if we can cross-compile to DOS with meson, that would be a POC * [aklm] we do cross-compile with meson, just not for DOS * [Edward] How do we make it easy for new contributors to get involved in the project and grow the community to have more resources? * Improvements to community guidelines, * Improvements to developer documentation and expectations, * Convey appreciation to contributors and make them feel like no contribution is too small, * [aklm] Good news: this is exactly what we are doing right now! Literally, all of that starting from “How do we make it easy ….” to “.... no contribution is too small”. Importantly, these are not just words, but _lots of tasks to be done._ Since we got accepted to gsoc, already 6 people contacted us, they want to contribute. I really encourage everyone who can, to talk, respond to people, answer their questions, review their patches. I can quote myself from a previous meeting: “If you want to help and don’t know what to do, contact Anastasia or Felix.” * [dhendrix] Better automation. Git precommit hooks for style checks, etc. so that we don't waste review time telling newcomers where to put their braces, how to write a commit message, etc. * [FelixS] In my opinion, the website needs to be reworked. From my view, it’s not really inviting or motivating to read it. Also, many texts are outdated. * [David] What do we do about the GitHub mirror? Many issues and pull requests there, people are waiting for responses. * Edward suggests using [PRBot](https://github.com/ajdlinux/PRBot) * Martin: Do we want to add checks similar to coreboot's linters to the jenkins build? * Edward: Clang-format would be good. * [dhendrix]: revisit [https://review.coreboot.org/c/flashrom/+/44095%5D(https://review.coreboot.or...) ? * CDH: An automated message is much better than nothing. We need some sort of onboarding, and onboarding is always hard. * [aklm] Easy projects page, we need more easy projects for new people, please add if you have ideas. * [Nico] we have checkpatch set up for coreboot, I think this is a good thing, * [Martin] I think I can set this up. * [Martin] I can set up scan-build too * [Edward] we can display coverage in gerrit, contributors will see the progress for the changes in their patch? * [Thomas] note: tests are only for meson * [Martinr] The tests need to generate an output file, and a gerrit plugin needs to be added. coreboot currently has the files output, but the plugin isn't integrated yet. * [Felix] upstream pull requests as easy projects? * [Nico] These are not very easy projects, but there are unmerged patches on [patchwork](https://patchwork.coreboot.org/project/flashrom/list). We can see if there is some useful stuff there.