[prev in list] [next in list] [prev in thread] [next in thread] 

List:       flashrom
Subject:    [flashrom] flashrom dev meeting notes 19.05.22
From:       Felix Singer <felixsinger () posteo ! net>
Date:       2022-05-19 10:04:59
Message-ID: ea181a73b715060702246d79f0a3a1a70e15f319.camel () posteo ! net
[Download RAW message or body]

# 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](https://ticket.coreboot.org/issues/353)
.
* 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](https://ticket.coreboot.org/issues/353)
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](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](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](https://repology.org/badge/vertical-allrepos/flashrom.svg)
                
* [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.
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-leave@flashrom.org


[prev in list] [next in list] [prev in thread] [next in thread]