The approach in the last 24 years (of this unsustainable project :-) has been to get several mainboards of a type, and, once we have them, try to work out what code is truly common and what code is similar but not truly common.
Code that is truly common can then be factored out into places such as src/lib. Code then migrates out of specific mainboards and into common spaces. This progression has happened many times. And, yes, no question, this is an activity that likely occurs less than it should. Such is our industry. It is not possible to know, a priori, what those common pieces will be. So we are left with this admittedly non-ideal situation. There is the further risk (this has happened) that a seemingly harmless change is discovered to break some board, 1.5 years later. This has happened. To me. As has been pointed out, always in motion, the future is. On Tue, Jun 20, 2023 at 4:08 PM Peter Stuge <pe...@stuge.se> wrote: > (sorry if you receive this twice) > > David Hendricks wrote: > > it will be easier to refactor portions of the code with the large > > patches merged in a buildable and (hopefully) usable/testable state. > > That's pretty weak sauce and I think you all know deep down. > > Who pays for refactoring? Probably someone else. > > That's unsustainable for the project. > > It externalizes refactoring cost from those creating the initial > mainboard ports but that's not how any platform code can grow > into something well-engineered and versatile. > > One can certainly argue that well-engineered is just too costly for > our community to strive for but while that does seem the prevailing > group think I have to say I would consider it a sad resignation. > > > //Peter >
_______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
