# 19th May 2022, 6:00 - 7:00 am UTC+0
Attendees: Anastasia, Nico, Edward, Martin, Felix, Thomas
## Decisions Summary
* We are targeting v1.3 release between 1st August and 15th December. Until 1st August, we will fix as many bugs from the list as possible and then we will review the status. [https://ticket.coreboot.org/issues/353%5D(https://ticket.coreboot.org/issues...) . * We will be discussing bugs for release more often in the meeting, to keep things moving. * Split programmer lifecycle tests into separate files per programmer.
## Agenda
* [Martinr] When is the next flashrom release? It's been 2 years since the last release (v1.2). * [dhendrix] Should we start doing (semi-)automatic releases on a schedule, with point fixes to address specific problems that come up? We've tried the "wait until everything is perfect'' approach and it's resulted in years-long release cycles and countless forks. Now that we have unit tests we should be confident in doing more frequent releases. * [quasisec]: I would be in favor of a semi-auto release schedule +1. * [Nico] Currently we are rather exercising “wait until everything is broken”. When we set the bar higher in the past, releases were no issue. I think we should return to that. * [Edward] Using a bug tracker allows us to have release-blocker bugs and to know who is responsible for what to help clear up communication lines. * [Martin] Maybe create a release branch to fix any bugs without adding any more features that would introduce new bugs? * [aklm] At the meeting 2022-04-21 community decided that I am a release manager. I will do a release, but I very much appreciate any help and advice from people who have experience. I have never done any release before. I created a list of issues under parent task here [https://ticket.coreboot.org/issues/353%5D(https://ticket.coreboot.org/issues...) some of them already assigned. * [aklm] Hopefully this year * [aklm] We’ve created a list of bugs that should be fixed before release. * After the tests are run. * Testing needs to be done for meson changes, and then another time before the release. * Once release branch is created, it needs to be tested * Martin: if we get qemu images I can add them to jenkins * Edward : intermediate step is one non-linux build bot * Breaking lifecycle tests into separate files : really nice to have * [martin]: Can we set a specific date for a release? That gives us something to aim for. If we need to postpone it, we can. * December? Too far away? * August 1? Is it too aggressive? * Nico: set up for jenkins builders should not affect the release * Thomas: not sure if we finish meson support. We can just document the meson builds for this release - it doesn’t have to be complete. * Edward: how about we have a release window between 1 Aug and 15 Dec * Nico: we can fix all bugs, or disable the code * Martin: We can work until 1 Aug and see how much is fixed. * [Martinr] Who is responsible for flashrom binaries? There don't seem to be links to binaries in [https://www.flashrom.org/Downloads%5D(https://www.flashrom.org/Downloads) and I'm willing to bet that most of those maintainers aren't doing it any more. * [dhendrix] Upstream flashrom has only ever published sources (except for certain Windows binaries?). Package maintainers for various distros have been responsible for binary releases. * The reason I was asking was that the download page is very confusing and seems to be very out-of-date.
[https://www.flashrom.org/Downloads%5D(https://www.flashrom.org/Downloads)
* Windows binaries are the only ones the users are asking for * Thomas: I can build binaries for meson build testing. * Felix: What about doing a static linux build? * Nico: Let’s postpone that until someone asks for it. * Nico: It could be useful to post a daily build off of master. * Martin: We could do a nightly build with jenkins? * Thomas: static libraries are libusb, libpci , libftdi , libjaylink. * TODO: add a bug for updating the Downloads page. * For linux systems use packaged binary, if you need latest, build off master * List of versions in each distro: [https://repology.org/badge/vertical-allrepos/flashrom.svg%5D(https://repolog...) * [Martinr] What do we need to do for flashrom cross-platform build testing? * [Nico] We have a set of Docker containers prepared (util/manibuilder/). FelixS is looking into buildbot integration. If coreboot makes the switch eventually, it shouldn’t be an issue. * These are somewhat out of date. * Thomas has a number of qemu images as well. * TODO: file a bug to update containers * Martin or Nico will take care of updating these. * [Martinr] What's the current state of flashrom testing? * Is it mostly manual at this point? * Unit tests are running on every push, but these are just covering a very little bit. supplement documentation for what was intended for the patch. * Google is testing after downstreaming the code. Also get tested in the commit queue. AVL test of customer roms. * Martin: would this generate a bug upstream flashrom, or only within google? * The plan is to push all of these up to the flashrom bug tracker. * What tests are done for release? * We need to document this. * In the past, there has been testing on hardware, generate a release candidate and ask the community to test. * How do we test the different internal flashers? Just the community - there’s not much change in these programmers. * Martin: email alias flashrom-vvv to send logs ? something like coreboot board status. People can send email “I have tested in, here is an output” * RC branch, when you run it, please email the results * Edward: Do we want an owners file in the tree? “Here are drivers that are officially supported” * Felix: I have some ideas for a QA lab, like 9elements Lava QA but for flashrom. So we could test at least some programmers * Can we go through open patches manually? * What’s needed to continue work on meson? * Tests currently depend on libusb. So in the current setup at least one libusb programmer needs to be selected to run tests. However not all tests depend on libusb , only for some programmers. * Lets split lifecycle.c into per-programmer files and then we can run the tests that do not depend on libusb when the library is not present.