[coreboot] A case for branching AGESA

[Patrick Georgi]

2015-11-01 21:29 GMT+01:00 Alex G. <mr.nuke.me at gmail.com>:
>>> Patch trains from google and other contributions to non-AGESA code gain a 2x to 3x
>>> speedup in server time, while users of AGESA can continue to contribute
>>> and work on the codebase.
>> ... and diverge...
>
> And that's expected. Convergence is a dream. AGESA boards use BuildOpts
> for configuration, and not much Kconfig/devicetree.cb, versus most other
> boards in the tree. Except for VX900 and sandybridge, every chipset
> implements its own SPD parsing routines. I can go on and on. Even within
> one branch, significant divergence exists, so non-divergence is a moot
> point.
So you picked three examples. Let me give several counter examples:
1. cbfs/fmap (backward and forward compatible): extended attributes,
file-level compression, hashes
2. vboot2/verstage integration
3. SPI flash driver infrastructure
4. supporting build tool development (eg. Kconfig improvements,
tighten lint rules) + the fallout to keep the tree compliant to the
new standards.

All of these would be painful to port between code bases (and some
were, see the chromeos-2013.04 branch).

Just because your three go-to items aren't as wonderful as (you claim)
you'd like them to be doesn't mean that you get to inflict damage on
other developers.


Patrick
-- 
Google Germany GmbH, ABC-Str. 19, 20354 Hamburg
Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg
Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle