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