# 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 -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org

Reply via email to