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

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 [1] https://ticket.coreboot.org/issues/361

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 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

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