Hi flashrom fellows,
something that's on the agenda for the next dev meeting (30th June)[1]:
Should we look at forking flashrom between version 2 (Classic, Legacy, or “Stable” flashrom) and version3 of flashrom (Modern, Tested or Contemporary), where new features are added?
I think such a question deserves more attention, hence this email.
My own thoughts about the topic are quite mixed. First of all, it's not the first time the idea to work on two branches comes up. When we switched to Git and Gerrit in 2017, we started with a `stable` and a `staging` branch[2].
There were reservations, of course. Most of all that the `staging` branch could fall out-of-sync quickly, so it would be too hard to port anything from there to `stable`. Maybe such problems could be be avoided by allowing merges from `stable` to `staging`.
Eventually, we had a lot of new patches on the `staging` branch, including many fixups, so the features could have been ported to `stable`. But they were not, and we renamed `staging` to `master` instead. This was due to personal issues and not technical ones, though. I guess we can't really say if the branch model failed.
Now to the current proposition. Again, we have the idea to have one more and one less stable branch. But this time they would drift apart on purpose, focusing on different subsets of program- mers and chips, AIUI.
I would not object to continue development on two branches. Personally, I would most likely work on the stable "version 2" only. However, the naming would really be a tough nut to crack. Given my experience with this project, I would expect a branch that focuses on stability to be the more "modern" one very soon. Simply because it's much easier to add new features to something stable.
I wouldn't mind if people try such a "version 3". But it seems risky. I fear it might lose focus quickly and be abandoned again.
Cheers, Nico
[1] https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFs... [2] https://www.flashrom.org/index.php?title=Development_Guidelines&oldid=22...
The idea behind the naming was the idea that the "modern" branch would drop all the old hardware that is no longer available, making it easier to develop and test. Presumably this would be the branch that the Google changes would continue on in. I'd assumed from previous conversations that the preference for the "classic" branch would be to drop those Google changes. Assuming that the split does happen this way, I'm pretty sure that both trees would see continued development.
Hopefully, both branches would be stable - modern through hardware testing, and classic by rigorous review and a slower development pace since not everything is available to test.
I do agree that the trees would probably diverge quickly an no longer be compatible unless some APIs were developed to keep everything well contained.
Martin
On Sat, Jun 25, 2022 at 15:01 Nico Huber nico.h@gmx.de wrote:
Hi flashrom fellows,
something that's on the agenda for the next dev meeting (30th June)[1]:
Should we look at forking flashrom between version 2 (Classic, Legacy, or “Stable” flashrom) and version3 of flashrom (Modern, Tested or Contemporary), where new features are added?
I think such a question deserves more attention, hence this email.
My own thoughts about the topic are quite mixed. First of all, it's not the first time the idea to work on two branches comes up. When we switched to Git and Gerrit in 2017, we started with a `stable` and a `staging` branch[2].
There were reservations, of course. Most of all that the `staging` branch could fall out-of-sync quickly, so it would be too hard to port anything from there to `stable`. Maybe such problems could be be avoided by allowing merges from `stable` to `staging`.
Eventually, we had a lot of new patches on the `staging` branch, including many fixups, so the features could have been ported to `stable`. But they were not, and we renamed `staging` to `master` instead. This was due to personal issues and not technical ones, though. I guess we can't really say if the branch model failed.
Now to the current proposition. Again, we have the idea to have one more and one less stable branch. But this time they would drift apart on purpose, focusing on different subsets of program- mers and chips, AIUI.
I would not object to continue development on two branches. Personally, I would most likely work on the stable "version 2" only. However, the naming would really be a tough nut to crack. Given my experience with this project, I would expect a branch that focuses on stability to be the more "modern" one very soon. Simply because it's much easier to add new features to something stable.
I wouldn't mind if people try such a "version 3". But it seems risky. I fear it might lose focus quickly and be abandoned again.
Cheers, Nico
[1]
https://docs.google.com/document/d/18qKvEbfPszjsJJGJhwi8kRVDUG3GZkADzQSH6WFs... [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.org
Hi Martin,
On 26.06.22 15:35, Martin L Roth wrote:
The idea behind the naming was the idea that the "modern" branch would drop all the old hardware that is no longer available, making it easier to develop and test. Presumably this would be the branch that the Google changes would continue on in. I'd assumed from previous conversations that the preference for the "classic" branch would be to drop those Google changes. Assuming that the split does happen this way, I'm pretty sure that both trees would see continued development.
thanks for elaborating. I see a lot of potential misunderstandings when we talk about "Google changes". To wrap it up: not all changes by Google are problematic of course. The reoccurring idea to remove problematic code mostly targets programmer drivers that are not tested. For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google. Sometimes the code wasn't even working when it was merged.
So if we'd remove the problematic code from one branch and remove code we can't test from another, that might actually hit the same code and remove it from all branches. And we don't need to fork to remove code that everybody wants gone, I guess ;)
That's when speaking about problematic additions. On the other end there's indeed a lot of legacy code that we also can't test. But maybe we should first discuss if it helps to remove it? The last time I stalled a patch for testing it wasn't because of super legacy code but rather because of compatibility to ~6 year old platforms. And the patch didn't fix or add anything anyway, so it wasn't slowing develop- ment down.
Hopefully, both branches would be stable - modern through hardware testing, and classic by rigorous review and a slower development pace since not everything is available to test.
In my experience, developers working on older platforms actually test much more. But that might change of course, once you have a branch that demands full testing.
Nico
On Sun, Jun 26, 2022 at 7:14 AM Nico Huber nico.h@gmx.de wrote:
Hi Martin,
For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google.
Which ones in particular did you have in mind here?
Stefan
Hi Stefan,
On 26.06.22 19:30, Stefan Reinauer wrote:
On Sun, Jun 26, 2022 at 7:14 AM Nico Huber nico.h@gmx.de wrote:
Hi Martin,
For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google.
Which ones in particular did you have in mind here?
hmmm, from the top of my head, I read this about the realtek_mst_i2c_spi programmer recently [1]:
Fixups suggest that the original code wasn't properly tested, was it by now?
It worked the last time I wanted to use it, but nothing uses this in production so it's not actively tested.
I guess that's still testable. But would it be worth the effort if we decided to keep only tested hw support?
The two extreme cases I remember were EC interfaces, ene* something and mec* something. We removed them again already. They were merged about last year, but turned out to be for some of the first chromebooks. After some fixups to the integration, people wanted to write unit tests for them, and then we realized that the code couldn't work.
Nico
On Sat, Jun 25, 2022 at 11:00:35PM +0200, Nico Huber wrote:
Hi flashrom fellows,
something that's on the agenda for the next dev meeting (30th June)[1]:
Should we look at forking flashrom between version 2 (Classic, Legacy, or “Stable” flashrom) and version3 of flashrom (Modern, Tested or Contemporary), where new features are added?
I think such a question deserves more attention, hence this email.
My own thoughts about the topic are quite mixed. First of all, it's not the first time the idea to work on two branches comes up. When we switched to Git and Gerrit in 2017, we started with a `stable` and a `staging` branch[2].
There were reservations, of course. Most of all that the `staging` branch could fall out-of-sync quickly, so it would be too hard to port anything from there to `stable`. Maybe such problems could be be avoided by allowing merges from `stable` to `staging`.
Eventually, we had a lot of new patches on the `staging` branch, including many fixups, so the features could have been ported to `stable`. But they were not, and we renamed `staging` to `master` instead. This was due to personal issues and not technical ones, though. I guess we can't really say if the branch model failed.
Now to the current proposition. Again, we have the idea to have one more and one less stable branch. But this time they would drift apart on purpose, focusing on different subsets of program- mers and chips, AIUI.
I would not object to continue development on two branches. Personally, I would most likely work on the stable "version 2" only. However, the naming would really be a tough nut to crack. Given my experience with this project, I would expect a branch that focuses on stability to be the more "modern" one very soon. Simply because it's much easier to add new features to something stable.
I wouldn't mind if people try such a "version 3". But it seems risky. I fear it might lose focus quickly and be abandoned again.
Cheers, Nico
I do not understand why anyone would want two versions.
First off, coreboot-2. But i guess one would need to be old enough to remember that.
Secondly, whenever i have been on the receiving end of a fork with graphics drivers, the following happens with users: - if something does not work on the one - it gets attempted with the other - if the second works, the first never gets a fix, or even a bug report. And vice-versa.
And by the time a user has attempted the second version, and that does not work either, he has done double the work already, and is much more likely to throw in the towel instead of spending the time to file a bugreport or to even debug things. And where would he file the bugreport, the first or the second?
So both sides of that coin are much, much worse off than before.
The same was true when a secondary modesetting path was introduced in my first big graphics driver project. This was the cause of the fork, and the forked driver had a config time switch between the paths. They ended up adding a third path on top of that a few years later. They never had anything reliable before the hardware was totally obsolete.
Also, what does one gain from two versions? Are there not effectively two version of flashrom already? The google one, and the formal one? Is this not just a veiled attempt to christen the google branch as formal?
Luc Verhaegen.
It is probably a good idea to create two branches but probably more for the sake of very old hardware not so easily accessible, par masters springs most to mind. Exceedingly old Intel/VIA could also be included although I am not sure which year to pick as the line in the sand there for 'old'? Specifically to freeze them on a branch and let them live out the rest of their life?
Honestly the same could be archived by EOL'ing them in release notes of a stable flashrom release? What we really need to ask is - how long is their life, is it finite, what is tractable for the community to maintain and have access to? This seems like the key question beyond the branching which is more the mechanism of solving this question.
The key motivation for two branches would be to allow flashrom as a project in terms of core logic (driver API / remove global state / etc) to progress forwards with well supported (tested) hardware that we can maintain. That means, essentially, removing the fear of breaking exceptional old hardware drivers that the majority of active contributors do not have the means to test with practically speaking.
The Google vs. ~Google dichotomy is an unbounded loop of discussion that suffers from the halting problem. An easier approach is to create a bound on - flashrom active contributors - and what they realistically have available to them. Google can just buy some hardware if it is required for them to collaborate effectively with the wider community and shouldn't be a burden on the community imho. However if the hardware is only available via ebay once a year that requires some old cyrix cpu that may not fall within the realistically accessible hardware set.
I think we are pretty keen on continuing to invest in testing on our side, so aklm unit-testing is one river of contribution on this front from our side and evanbenn has picked up ownership of flashrom-tester to drive on the E2E testing front.
Regarding the claim;
The reoccurring idea to remove problematic code mostly targets programmer
drivers that are not tested. For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google. Sometimes the code wasn't even working when it was merged.
This is a bit hyperbole, the only known case of this I am aware of in the current environment was the ene*/mec* and this was dealt with already. Unit-tests written for this and the maintenance burden came from Google anyway. Regarding realtek_mst_i2c_spi, this is maintained by Peter and is absolutely tested. The request for better documentation for realtek_mst_i2c_spi and lspcon man page updates were fulfilled. If this was a significant pattern from the past before my time then I cannot speak for that however focus has continued to sharpen more and more on this not happening as broken things serve to no one's benefit.
Older drivers that have fallen into disrepair from way before my time are also being looked into https://review.coreboot.org/c/flashrom/+/65378 - actually aklm has a bug to look into them.
I can say the older EC paths for ChromeOS were extremely undocumented [I couldn't even find out if we were meant to be supporting them or not!] when I began deforking flashrom so the ene*/mec* situtation misstep was a unfortant mistake of trying to do the right thing by giving community open support to our hardware with a team of only half a person at the time. Mistakes were owned and rectified, however the lesson was learnt - for example no one is pushing cros_ec in the ChromiumOS tree upstream as it is clearly not suitable [code quality, no tests, no documentation and too many layering violations due to EC state management].
On Mon, 27 Jun 2022 at 06:09, Luc Verhaegen libv@skynet.be wrote:
On Sat, Jun 25, 2022 at 11:00:35PM +0200, Nico Huber wrote:
Hi flashrom fellows,
something that's on the agenda for the next dev meeting (30th June)[1]:
Should we look at forking flashrom between version 2 (Classic, Legacy, or “Stable” flashrom) and version3 of flashrom (Modern, Tested or Contemporary), where new features are added?
I think such a question deserves more attention, hence this email.
My own thoughts about the topic are quite mixed. First of all, it's not the first time the idea to work on two branches comes up. When we switched to Git and Gerrit in 2017, we started with a `stable` and a `staging` branch[2].
There were reservations, of course. Most of all that the `staging` branch could fall out-of-sync quickly, so it would be too hard to port anything from there to `stable`. Maybe such problems could be be avoided by allowing merges from `stable` to `staging`.
Eventually, we had a lot of new patches on the `staging` branch, including many fixups, so the features could have been ported to `stable`. But they were not, and we renamed `staging` to `master` instead. This was due to personal issues and not technical ones, though. I guess we can't really say if the branch model failed.
Now to the current proposition. Again, we have the idea to have one more and one less stable branch. But this time they would drift apart on purpose, focusing on different subsets of program- mers and chips, AIUI.
I would not object to continue development on two branches. Personally, I would most likely work on the stable "version 2" only. However, the naming would really be a tough nut to crack. Given my experience with this project, I would expect a branch that focuses on stability to be the more "modern" one very soon. Simply because it's much easier to add new features to something stable.
I wouldn't mind if people try such a "version 3". But it seems risky. I fear it might lose focus quickly and be abandoned again.
Cheers, Nico
I do not understand why anyone would want two versions.
First off, coreboot-2. But i guess one would need to be old enough to remember that.
Secondly, whenever i have been on the receiving end of a fork with graphics drivers, the following happens with users:
- if something does not work on the one
- it gets attempted with the other
- if the second works, the first never gets a fix, or even a bug report.
And vice-versa.
And by the time a user has attempted the second version, and that does not work either, he has done double the work already, and is much more likely to throw in the towel instead of spending the time to file a bugreport or to even debug things. And where would he file the bugreport, the first or the second?
So both sides of that coin are much, much worse off than before.
The same was true when a secondary modesetting path was introduced in my first big graphics driver project. This was the cause of the fork, and the forked driver had a config time switch between the paths. They ended up adding a third path on top of that a few years later. They never had anything reliable before the hardware was totally obsolete.
Also, what does one gain from two versions? Are there not effectively two version of flashrom already? The google one, and the formal one? Is this not just a veiled attempt to christen the google branch as formal?
Luc Verhaegen. _______________________________________________ flashrom mailing list -- flashrom@flashrom.org To unsubscribe send an email to flashrom-leave@flashrom.org
On Mon, Jun 27, 2022 at 11:12:35AM +1000, Edward O'Callaghan wrote:
It is probably a good idea to create two branches but probably more for the sake of very old hardware not so easily accessible, par masters springs most to mind. Exceedingly old Intel/VIA could also be included although I am not sure which year to pick as the line in the sand there for 'old'? Specifically to freeze them on a branch and let them live out the rest of their life?
Is this about chipsets, or is this about programmers attached to network/storage devices?
If this is about chipsets, i do not understand the reasoning behind deprecation.
First, for context, i am the guy who introduced board enables to flashrom. I also came up with modesetting (which would have been better named "structured display driver development") while fixing, then cleaning up, then rewriting the display side of the via/unichrome driver. Which also led me to introduce the first fully native display initialization to coreboot, as back in the mid 2000s i was the only person who saw that it was possible to rid display drivers off of their shortsighted dependence on int10/vga/vesa.
When i tried flashrom on my unichrome based laptop (which was still alive the last time i tried), it turned off my backlight. So then it was clear that the chipset enable had to be split up.
I also am the author of the wild asus P5A board enable. This was just because i wanted to see how things were done with hardware a decade older. While this might sound like a good candidate for immediate deprecation, it turns out that the P5A is still a very popular retro-computing platform today.
Enough history.
From where i sit, as the guy who introduced structure in display drivers, flashrom is trivial.
1) Even though pci-ids were introduced in the 90s, and board ids were only really getting used properly (mostly) towards the end of that decade, pci-ids is still what we have today, even with the newest pcie standards. So detecting pci style devices has to work today, just as it did 25 years ago. Nothing changes there.
2) Since the hardware is this trivial, both chipset and superio enables are for whole families of chipsets, sometimes covering nearly a decades worth. If you really need to test the "bulk" of this code, all you need is one working example of what usually is a vast range of possible hardware. And if the chipset enable does break, it is much more likely that a user will file a bug report.
3) 90% of the time board enables is about gpio pins which need to be raised or lowered, and the code to do so is shared as well. If you break that code you usually break all the boards with the same family of chipsets.
4) chipset, superio and board enables are absolutely trivial. How anyone who is slightly dilligent could potentially break these is beyond me.
So no amount of rewriting the infrastructure should break older chipsets or board enables.
To me, this reeks of an unwillingness to deal with supporting slightly older hw, or to deal with chipsets/superios/boards at a time where we backslid into depending on BIOS hooks again.
Luc Verhaegen.
On 27.06.22 03:12, Edward O'Callaghan wrote:
It is probably a good idea to create two branches but probably more for the sake of very old hardware not so easily accessible, par masters springs most to mind. Exceedingly old Intel/VIA could also be included although I am not sure which year to pick as the line in the sand there for 'old'?
Why pick an arbitrary year at all? IMHO, if it ever comes to this, we should use existing lines, like what hardware interface they use.
Also, what's your experience with the code for Intel/VIA? where is it causing trouble?
Specifically to freeze them on a branch and let them live out the rest of their life?
They all benefit from the current and future layout work, for instance. Especially Intel devices since ~2009 with the IME. I don't see how to freeze that. All the documentation in the world about flashrom would have to make exceptions, e.g. "if you use legacy flashrom, you need to do this instead...". That alone seems much more effort than keeping a few lines of code around.
The key motivation for two branches would be to allow flashrom as a project in terms of core logic (driver API / remove global state / etc) to progress forwards with well supported (tested) hardware that we can maintain. That means, essentially, removing the fear of breaking exceptional old hardware drivers that the majority of active contributors do not have the means to test with practically speaking.
It's all open source, you know. There is a simple way to test any patch: reading and reasoning. You make me believe that people are actually afraid to read and understand the existing code that could break.
Regarding the claim;
The reoccurring idea to remove problematic code mostly targets programmer drivers that are not tested. For half of the programmers Google adds, it turns out soon after that they are unused and nobody can test them, not even at Google. Sometimes the code wasn't even working when it was merged.
This is a bit hyperbole, the only known case of this I am aware of in the current environment was the ene*/mec* and this was dealt with already.
Sorry for rounding incorrectly. 2 out of 5 then?
Unit-tests written for this and the maintenance burden came from Google anyway.
WDYM?
I can say the older EC paths for ChromeOS were extremely undocumented [I couldn't even find out if we were meant to be supporting them or not!] when I began deforking flashrom so the ene*/mec* situtation misstep was a unfortant mistake of trying to do the right thing by giving community open support to our hardware with a team of only half a person at the time. Mistakes were owned and rectified, however the lesson was learnt - for example no one is pushing cros_ec in the ChromiumOS tree upstream as it is clearly not suitable [code quality, no tests, no documentation and too many layering violations due to EC state management].
Why not fix it then? I think a driver for CrOS ECs would be very useful.
Nico
I'm not entirely convinced that this is what is best for the project, even though it was my suggestion. I think it solves a lot of difficult issues about how to run the project, but it also splits the developers and possibly the users. On the other hand, it would let the two different development philosophies present in the group each reach their own potential, so would be very interesting in that respect.
On Mon, Jun 27, 2022 at 11:35 AM Nico Huber nico.h@gmx.de wrote:
... All the documentation in the world about flashrom would have to make exceptions, e.g. "if you use legacy flashrom, you need to do this instead...". That alone seems much more effort than keeping a few lines of code around.
Currently existing documentation would reflect the legacy flashrom. Upcoming documentation could reference either, but should probably specify which it's referencing. I don't see a big issue.
The key motivation for two branches would be to allow flashrom as a
project
in terms of core logic (driver API / remove global state / etc) to
progress
forwards with well supported (tested) hardware that we can maintain. That means, essentially, removing the fear of breaking exceptional old
hardware
drivers that the majority of active contributors do not have the means to test with practically speaking.
It's all open source, you know. There is a simple way to test any patch: reading and reasoning. You make me believe that people are actually afraid to read and understand the existing code that could break.
I don't think reading and reasoning actually qualifies as testing. While I agree that it's obviously good, it's just not the same as testing. Classic flashrom could be maintained this way if desired, but Modern flashrom should (in my opinion) be tested on actual hardware to verify that everything is working. This also gives an easy way of what should be kept in modern vs being removed. The preferred method for deciding what to keep would be based on whether or not there's hardware easily available for testing. If there is, we keep it. If we can't find hardware to test something, we remove it from modern, and let it be maintained in the classic branch as desired.
My thinking is also that each branch would also have different people in charge of making decisions about the branch and how it's run. This would allow for a significantly different development pace between the two branches. For example, one branch could have quarterly or biannual scheduled releases, while the other branch releases only when its developers feel it's ready to be released.
Another question is how we'd want to request that package managers handle this. We'd want to make it clear that this is a philosophical split, and that they should make their own choice, or even include both flashrom versions.
Martin
On Tue, 28 Jun 2022 at 04:32, Martin L Roth gaumless@gmail.com wrote:
We'd want to make it clear that this is a philosophical split, and that they should make their own choice, or even include both flashrom versions.
I think a lot of *users* are already confused that fwupd and flashrom both exist, and having flashom and flashrom-legacy is going to make it even more complicated.
Richard
-
Edward O'Callaghan -
Luc Verhaegen -
Martin L Roth -
Nico Huber -
Richard Hughes -
Stefan Reinauer