# 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%2540posteo.net+-author:felixsinger%2540posteo.net
) 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/](https://review.coreboot.org/c/flashrom/+/66720/)
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](https://review.coreboot.org/q/topic:programmer_init_param_globals)
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?
_______________________________________________
flashrom mailing list -- [email protected]
To unsubscribe send an email to [email protected]
