Hi flashrom folks,
I've been thinking more and more about returning to a stable flashrom branch lately; starting over from v1.2 seems reasonable. The question is, how to proceed on such a branch?
There are, of course, many cherries on the current master branch. But in what order should they be picked? And should they be picked first? What about even older patches? There are still many patches on patch- work [1] and also on Gerrit. Some of them probably also cherries.
When I was still more of an official maintainer for flashrom, I tried to keep track of these things. And lately, a look at the wiki history told me that maintainers before me cared too [2]. But I guess nothing happened in that direction in the past 3 years.
Depending on the progress with the 1.3 release, I'd suggest to either try to merge things in historical order, or start with the easy cher- ries on the current master branch (new chips and programmers that are ready; for a small release and then focus on a short release cycle).
WDYT?
Cheers, Nico
[1] https://patchwork.coreboot.org/project/flashrom/list/ [2] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=22...
On Sat, 19 Nov 2022 at 17:17, Nico Huber nico.h@gmx.de wrote:
I've been thinking more and more about returning to a stable flashrom branch lately
I'm missing the "why".
Richard.
On Sat, Nov 19, 2022, 09:17 Nico Huber nico.h@gmx.de wrote:
Hi flashrom folks,
I've been thinking more and more about returning to a stable flashrom branch lately; starting over from v1.2 seems reasonable. The question is, how to proceed on such a branch?
Would you mind elaborating on why going back to 1.2 seems reasonable? That's not obvious, at least to me.
There are, of course, many cherries on the current master branch. But in what order should they be picked? And should they be picked first?
They have already been picked. So by the nature of reality the answer here seems to be yes.
What about even older patches? There are still many patches on patch-
work [1] and also on Gerrit. Some of them probably also cherries.
I would assume stuff on patchwork has by now been bitrotting for a few years and should not be committed without being forward ported, tested and uploaded to Gerrit.
When I was still more of an official maintainer for flashrom, I tried to keep track of these things. And lately, a look at the wiki history told me that maintainers before me cared too [2]. But I guess nothing happened in that direction in the past 3 years.
Are you suggesting that you didn't keep track in the past three years? What sort of track keeping are you referring to here?
Depending on the progress with the 1.3 release, I'd suggest to either try to merge things in historical order, or start with the easy cher- ries on the current master branch (new chips and programmers that are ready; for a small release and then focus on a short release cycle).
What do you mean by "depending on the progress"? What are your key indicators of progress here that would influence one or the other direction? It seems to me that a realistic path forward is to have a combination of the two.
WDYT?
Cheers, Nico
[1] https://patchwork.coreboot.org/project/flashrom/list/ [2]
https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=22... _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.orgfffcc
Hi Stefan,
On 20.11.22 00:12, Stefan Reinauer wrote:
On Sat, Nov 19, 2022, 09:17 Nico Huber nico.h@gmx.de wrote:
I've been thinking more and more about returning to a stable flashrom branch lately; starting over from v1.2 seems reasonable. The question is, how to proceed on such a branch?
Would you mind elaborating on why going back to 1.2 seems reasonable? That's not obvious, at least to me.
1.2 is still our latest release. The code has been tested for almost three years now. We have gathered fixes that came up in that time on the 1.2.x branch recently. I think it should be easy to trust it.
This is a little vague: it seems to me that the 1.2 release was also roughly the time when people started to care less to keep the master branch in a releasable state.
There are, of course, many cherries on the current master branch. But in what order should they be picked? And should they be picked first?
They have already been picked. So by the nature of reality the answer here seems to be yes.
I don't understand this "nature of reality". Do you mean that all the cherries on the master branch have to be picked before any other deve- lopment can happen? or even that they should stay in their original order? I think that would only lead to bikeshedding what the cherries are.
What about even older patches? There are still many patches on patch- work [1] and also on Gerrit. Some of them probably also cherries.
I would assume stuff on patchwork has by now been bitrotting for a few years and should not be committed without being forward ported, tested and uploaded to Gerrit.
I'm not sure about re-testing. If something still applies and there is no doubt that the original test results still hold, I guess I would also accept that. Otherwise, yes.
When I was still more of an official maintainer for flashrom, I tried to keep track of these things. And lately, a look at the wiki history told me that maintainers before me cared too [2]. But I guess nothing happened in that direction in the past 3 years.
Are you suggesting that you didn't keep track in the past three years? What sort of track keeping are you referring to here?
I meant to say I didn't keep track if anything happened to older patches. If somebody pushed any of the patches from patchwork to Gerrit, for instance, I didn't notice.
Depending on the progress with the 1.3 release, I'd suggest to either try to merge things in historical order, or start with the easy cher- ries on the current master branch (new chips and programmers that are ready; for a small release and then focus on a short release cycle).
What do you mean by "depending on the progress"? What are your key indicators of progress here that would influence one or the other direction?
I have no indicators yet. If I would start a new branch in the future, I would have a look then how things progressed for 1.3. Ideally it would be released already.
Nico
[1] https://patchwork.coreboot.org/project/flashrom/list/ [2] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=22...
On Sun, 20 Nov 2022 at 11:04, Nico Huber nico.h@gmx.de wrote:
Are you suggesting that you didn't keep track in the past three years? What sort of track keeping are you referring to here?
I meant to say I didn't keep track if anything happened to older patches.
I'm a bit confused; I didn't think you were a maintainer anymore? Surely the maintainer team are the ones who decide what the release from which branch? It seems a bit rich to just walk back in as a contributor and want to undo the last three years of changes...
Richard
Hey Richard,
On 21.11.22 11:02, Richard Hughes wrote:
On Sun, 20 Nov 2022 at 11:04, Nico Huber nico.h@gmx.de wrote:
Are you suggesting that you didn't keep track in the past three years? What sort of track keeping are you referring to here?
I meant to say I didn't keep track if anything happened to older patches.
I'm a bit confused; I didn't think you were a maintainer anymore?
yes, that's right. It wasn't exactly a formal position but I said I wouldn't do it anymore end of January 2020.
Surely the maintainer team are the ones who decide what the release from which branch?
I don't know an official maintainer team. We tried kind of some grassroots democracy this year. But that didn't work too well, can't even agree on a communication channel.
It seems a bit rich to just walk back in as a contributor and want to undo the last three years of changes...
When I walked back (a little more than a year after I left, IIRC) I simply tried to pick up what nobody else did (releases and such). Didn't work out well because I have no intention to force anybody into anything. I merely try to discuss things on this mailing list. This thread could provide some ideas how to move on or not. If I'd decide to do anything what is discussed here, that doesn't have to mean any- thing for the current master branch. That's not up to me to decide. People can decide to go on there, that's up to them.
Rewinding on another branch doesn't mean anything gets undone. Some- times going a step back can make it easier to eventually move forward. A second branch could also be part of an official solution (e.g. the compromise in [1] or something else), it could eventually pull all the patches from the current master branch once they are ready for a release. There are many ways.
So, Richard, do you want to tell us how you would do it?
Nico
[1] https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/3K2ZE...
On Mon, 21 Nov 2022 at 18:34, Nico Huber nico.h@gmx.de wrote:
So, Richard, do you want to tell us how you would do it?
As I've stated before, a release every month. Any regressions quickly get fixed upstream and cherry picked into the current release by distros. Release early, release often.
Richard
I don’t understand why this topic is on the mailing list. No one is planning to return back in time to 3 years ago and “restart over”. There's only one person that I know (Nico) who can’t stop thinking about returning back in time. And there are… 3 threads already on the same topic?? I can imagine how confusing this is to the readers of the mailing list :\
No, *we are not returning back in time*. It is November 2022 at the time of writing, and time goes forward. Time always goes forward.
Indeed, Nico is not a maintainer anymore. So despite a lot of talking, lying and trolling, he cannot block anything.
I am not sure how many more threads on the same topic OP plans to produce. But I want to mention, there are some useful things that would be great if Nico could do instead, for example:
#1 Replying to the question in the comment here https://ticket.coreboot.org/issues/359#change-1258 #2 Replying to the thread on the mailing list about documenting flashrom https://mail.coreboot.org/hyperkitty/list/flashrom@flashrom.org/thread/KM3ZT... #3 Writing a new unit test! That would be a good long-term investment.
-
Anastasia Klimchuk -
Nico Huber -
Richard Hughes -
Stefan Reinauer