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