I have great news: I created items for the release in our bugtracker!

Here is a parent issue “Release v1.3” https://ticket.coreboot.org/issues/353 and it has 23 subtasks. The subtasks are the items from the original starter email. Thank you so much Nico for going through the long history and making the list, that’s a lot of work and time!

The very good thing is that now the big task is trackable, parallelizable and open to anyone who can join the effort.

I looked into commits and gerrit reviews that correspond to those, I tried to get some context. Surely all of the descriptions can be improved, or more info can be added to issues. Especially if you are taking an issue and start working on it.

Also, of course, more tasks can be added, if something is missing. Please set the parent issue #353, category “Release prep” and target release 1.3 if you add a new task.

I assigned the parent issue to myself. Please tell me if anyone has objections. I did it because at the last dev meeting the community decided that I will be “release manager”. It was completely unexpected for me, but it is true to say that I very much want the release to happen.
I really appreciate any help and advice from people!

As a separate note, the question of meson and make has been discussed in this thread. And we now have a One Build System working group with the goal to converge two flashrom build systems into one (meson). Here is the doc with more info. Everyone who is interested in contributing to the effort can join! This effort goes in parallel with release prep.

I haven’t done any releases before, so tell me if I am wrong. But what I am thinking when looking at the list of issues: maybe we can have some time for “just fixing issues on master” and after that do a release branch? Does it make sense?
“Some time” won’t take forever (AU winter maybe?). I have issue #353 assigned to me, so now it has to happen :)

On Thu, Mar 24, 2022 at 2:34 AM Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006@gmx.net> wrote:

Hi Richard,

Am 23.03.22 um 10:20 schrieb Richard Hughes:
> On Tue, 22 Mar 2022 at 12:07, Carl-Daniel Hailfinger
> <c-d.hailfinger.devel.2006@gmx.net> wrote:
>> AFAIR there were three arguments for meson:
>> - Meson build integrates nicely with other packages built by meson
> This means we can build libflashrom as a subproject, which means we
> can build the flashrom plugin even when the distro doesn't ship [a new
> enough] flashrom package:
> https://github.com/fwupd/fwupd/blob/main/subprojects/flashrom.wrap
>
> That's just something you can't do with the Makefile, and removing the
> subproject would force us to remove flashrom support from almost all
> the CI systems we test fwupd with.

It took me some time to understand the text of this last sentence, but
I'm unsure about the implied subtext.
The first paragraph implies that a fwupd build can rebuild flashrom as
well. Interesting. In that case a Meson wrapper for Makefile might
satisfy your requirements in principle, but not in spirit.

For the subtext of the last sentence I'm not sure if the intended
understanding was "use Meson or we'll drop flashrom" or "give us a way
to keep our CI running with flashrom" or something entirely different.
Sorry, English is not my native language. I'm trying understand if this
is a technical (something doesn't work) or social (something is
frustrating) problem or both. Analyzing your statement above with the
linguistic tools of Schulz von Thun and Watzlawick gave me the
impression that I'm missing something here.

>> - Native support for most non-Linux platforms
> I keep hearing this, but haven't got any actual data -- is there any
> reason why the meson build system wouldn't "just work" with
> *BSD/Win32/macOS?

Someone would have to test it and document it. This also includes
crossbuilds for MacOS and DOS on Linux which are both supported with
Makefile.
Documentation for the various Makefile based builds is available at
https://github.com/flashrom/flashrom/blob/master/README . Copy/paste
from a README is something that "just works". This is currently missing
for our Meson build.

>> I think Meson was a good idea, but it failed to get traction beyond "we
>> need it for dynamic libflashrom".
> I don't know how you've managed to get to "failed to get traction"
> given that it's being built with meson in 4 of the biggest projects
> (in terms of distribution, and number of deployed packages) using
> flashrom.

The switch to Meson in Debian has resulted in some regressions which
caused people to join #flashrom IRC. Not all of the regressions were
fixed. Maybe "failed to get traction" was the wrong phrase. "Nobody
bothered to check the Meson build result and compare it to the Makefile
reference" would be a more accurate description.

This caused a mismatch between packagers picking up Meson and developers
(as well as users following the documentation) still using the Makefile.

> This is all so frustrating: This feels like more of an existential
> crisis about what flashrom actually *is* rather than a discussion
> about build systems.

I've seen this in many open source projects: A rewrite of some component
happens, but the rewrite has a different subset (and not a superset) of
features. As long as both the original and the rewritten version are
available, neither side will have any motivation to make their version a
superset of the features of the other side because their own use case
works well. As a result, everyone is frustrated.

My hope with flashrom is that it brings joy or at least works as a good
tool. It is definitely not my intention to frustrate you. I would love
to find a solution that makes everyone happy.

Regards,
Carl-Daniel