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:
But did you mean more than that?

On Fri, Mar 18, 2022 at 2:56 AM Nico Huber <> wrote:
On 13.03.22 16:28, Nico Huber wrote:
> On 13.03.22 08:28, Anastasia Klimchuk wrote:
>>> I suggest that we freeze the master branch for everything that is neither
>>> a fix nor on the list (or a similar case that I missed)
>> But how can we freeze master… that would mean no one can do any work? Maybe
>> I am missing something?
> No you didn't miss anything :) it would be a very desperate
> measure. However, I see no other solution to make progress
> again without forking or further stalling a release. And
> after 2 years I think the project has waited long enough.

Sorry folks, I didn't mean to provoke any hasty activity to fix the
listed problems. Rather to push us to talk about what we should fix
before a release and what features we could do without in a release.
If we'd wait for everything to be fixed at snail pace, I fear people
would give up before another release happens (I would). Not to mention
that people will continue to push more controversial patches in the

flashrom mailing list --
To unsubscribe send an email to