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?
On Fri, Mar 18, 2022 at 2:56 AM Nico Huber nico.h@gmx.de 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 meantime.
Nico _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org