# 8th Sep 2022, 6:00 - 7:00 UTC+0
Attendees: Thomas, Felix, Edward, Anastasia
## Decisions Summary
* Felix gets submit rights * We need to document code review & merge rules (after the release)
## Agenda
* [Felix / Anastasia] Giving Felix submit rights * I am already a submitter for the coreboot project since over a year * I commented and reviewed over [200 flashrom patches](https://review.coreboot.org/q/project:flashrom+commentby:felixsinger%2540pos... ) since autumn 2021 * Admin and Mentor for gsoc * YES, all approved! * [Felix]: What are the rules for submitting patches? 3 days? What else? * 3 days, but also * Needs +2 * Are there any other ongoing work that maybe should be merged first? * Are all comments resolved? * If there are several ongoing streams, which one is easier to rebase, easier to test? * Look for other people’s patches who don’t have submit rights, because they cannot do themselves. They might sit and wait, and will need to rebase many times. * All the rules need to be documented. * Maybe a small update on wiki to begin with * And after the release , do the proper documentation * [Felix] Urgent: We have to unbreak our tests in CI * I think updating the Docker containers will be done later (in ~2 weeks). coreboot release got rescheduled. * We should submit [this patch](https://review.coreboot.org/c/flashrom/+/67345) (and the follow- up) now to make unit tests with Jenkins working again. I don’t think we should wait any longer. * DONE! * [quasisec]: Can we get over the hump of reviewing the remaining [https://review.coreboot.org/c/flashrom/+/66720/%5D(https://review.coreboot.o...) flashrom.c/print.c cleanups
And now most critically getting the bulk of the programmer init param plumbing patches reviewed and merged in the [https://review.coreboot.org/q/topic:programmer_init_param_globals%5D(https:/...) topic. Keeping in review for a long time causes rebases that effectively nullify the work but the bulk of the patches are just boring plumbing that are nop.
* Bringing the tree into consistent state: * Names for init functions * Start addr+offset VS start region + end region * chipoff_t and chipsize_t defined in flash.h * Layout regions * force_boardmismatch -> maybe it can be removed from flashctx and turned into a programmer param? * Checks for internal can be moved into internal maybe? * Internal is the most dangerous, and needs lots of checks * Cli * Needs to call libflashrom programmer init instead of programmer_init * Probe flash , the same * [Felix] Customized Buildbot commands using Gerrit comments * I am thinking about some use cases for user Buildbot commands, which are triggerable from Gerrit. Basically a Buildbot command is just a Gerrit comment, but Buildbot interprets it and can do something. * For example for build-testing if the binary is reproducible it could look like “@buildbot build reproducible”, which builds a binary before and after the specific patch and compares them. * I would like to know which ideas other people have or what their use cases would be. * Can we use flashrom_tester on buildbot? * Can we use EM100? * Can we have a command to retry build again?