# 14th July 2022, 6:00 - 7:00 UTC+0
Attendees: Felix, Thomas, Edward, Anastasia
## Decisions Summary
* aklm will be creating unit tests from selfchecks. Selfchecks will stay for now, because they are covering all platforms and unit tests do not [yet]. In the long-term, we want unit tests working on all platforms and then we can remove the selfchecks * We had impromptu in-depth discussions about the future of core elements of flashrom, e.g. board-enable infrastructure or how flash chips are organized, and this may turn into future projects.
## Agenda
* Maintainers file; * Thomas agrees we should try the mechanism but suggests it may be overkill for the project. * Thomas suggests that every flashrom developer is responsible for the whole tree. * Quasisec - Maintainers file does not preclude flashrom developers or block them from one another, simply to; * Allow new developers know who could be a good reviewer, * Critical developers are aware of patches to drivers that impact them (e.g., secunet knows a ichspi patch is up for review). * Quasisec - Not unlike the Linux kernel there are both subtree maintainers and every individual developer is responsible for entire tree changes when an internal API changes. * Global state; * Quasisec - One of the first projects for aklm was to remove static globals per driver. * Quasisec - Sent patches to help move the pacc global state inwards. * Quasisec - libflashrom has something aspirational but was probably merged prematurely that would allow for a state machine with a scope that is longer than the per-driver life-time of `flashctx`. * This per-flashrom instance context needs to be worked out by taking global statics out of flashrom.c into a struct to form the basis of this state machine. * Also, super i/o artifacts scattered everywhere should be consolidated into a flashrom super i/o support library. * Pacc global state needs to be polished off and folded into the per-flashrom instance context as well. * Quasisec - Finally cli_classic can likely be hoisted upon libflashrom completely. * Quasisec - It would be nice to move in a general direction of less OOP huge singleton contexts. * Self-check vs unit-tests; * [aklm] How about turning flashrom.c#selfcheck() into unit test(s) ? I can look into that. For example, testing the order of erase functions would be great to do when a patch is pushed to gerrit. * Unit tests are helpful for developers, * Runtime sanity self-testing is perhaps too late. * Blocker - unit tests only work on Linux at the moment. * Thomas agrees it's better for them to be in the unit-test. * Good starting point is to convert sanity checks to unit tests and later we can switch. * As a first step we can have unit tests AND selfcheck, because unit tests run for Linux only, other systems rely on selfcheck(). TODO aklm * Re-write as proper unit tests, small and granular. * There is also selfcheck_board_enables in board_enable! * Quasisec - Speculative here but can a first step be to factor out all self-checks into selfcheck.c and _maybe then_ next step is to not compile on Linux as it has unit-tests ? * Quasisec / Thomas; * Long term projection into the future of what flashrom could look like. * Less OOP * Have flashrom core the ability to query programmer capabilities and query flashchip capabilities. If the user requests an operation X then flashrom core can do the NxM and determine what to do rather than hard coded bespoke decisions.