Thank you for the explanations! Really helpful.

I am trying to understand the mechanics.

“This is also why I suggested that we can drop suspicious
code from a release branch (i.e. we could branch 1.3.x now
and then delete code on that branch without affecting master).
Then the freeze might be over really quickly.”

This option would mean all the items from the first list are reverted in v1.3?
And then they, hopefully, all get fixed to the time of v1.4?
(correct me if I am wrong)

Then that means on the other end there is an ideal scenario where all the items from the first list are fixed (on master) and then v1.3 happens?

And also a scenario in between when some of the items are fixed, but not all of them?

Which of these scenarios has minimum time to freeze master, and which one takes second place? I am asking because I fully agree with you, it seems just as you said “a very desperate measure”... so I am worried this may create a drama :\

We have already created 5 bugs as “flashrom release blockers” in our internal bug tracker (the only reason they are created in internal one is because flashrom bug tracker is not ready yet). There is no secret info there at all. That’s for all the items that are missing documentation.
It is not a hasty activity, we want to help! Release is important.
And especially the items which say “missing documentation”, it’s a no-brainer, needs to be fixed.

“My latest idea about this is that we could add an option (e.g.
`inofficial`) and a whitelist of known working platforms. Such that
one would have to literally state they want an inofficial binary to
build on a platform with unknown status.”

Looks fine, let’s keep it unofficial (if it really is). Let’s just not delete it :)

“I can work on that unless someone else wants the task.”

Thanks Martin! There is a patch currently for man page: https://review.coreboot.org/c/flashrom/+/62768
But did you mean more than that?