[coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release

[Timothy Pearson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/27/2015 11:14 AM, Martin Roth wrote:
> The current thought is to create a new branch for 4.2, *THEN* remove
> the decided upon code from the master branch.
> 
> This removes the maintenance work on master going forward while
> providing a known point if someone wants to pick up the boards going
> forward.
> 
> I don't understand the question about creating a branch for other
> boards as well.  The branch would contain all current boards.
> 
> The question is really about what boards/code are inactive.  The code
> that's being updated right now for the ASUS/KGPE-D16 board looked
> inactive for a significant time.
> 
> 
> Personally, I think it's a bad plan to remove the AGESA code.
> Throwing away the code that AMD has given us is telling them that they
> were right, and they shouldn't bother opening the source.  This is a
> total contradiction of what we ACTUALLY want, which is the source code
> for the binary PI releases.
> 
> If it's still decided to remove the AGESA family 10/15 codebases, my
> thought would be to wait for at least the 4.3 release.  That's going
> to be 3 months from now, giving us some time to finish getting in the
> code that's supposed to replace it and giving it time to stabilize.
> 
> Martin

If I may add to this discussion, much of the rationale for dropping
AGESA has to do with the largely incompatible design (and coding style)
of AGESA versus the rest of coreboot.  By encouraging the use of AGESA
over native intialization, not only does the native initialization code
receive less attention, but development of new features (such as
timestamping and early CBMEM) is also hampered.

- From what I understand, what coreboot actually wants is access the
source code, but not necessarily to just use the source code as-is.
Would it make more sense to keep the vendorcode available, but put a
large warning on it that boards using said vendorcode are not supported
(and remove them from Jenkins builds, etc.)?  Maybe even moving those
boards to a different subdirectory (vendor_shim_mainboards) would help
reinforce this idea.

- -- 
Timothy Pearson
Raptor Engineering
+1 (415) 727-8645 (direct line)
+1 (512) 690-0200 (switchboard)
http://www.raptorengineeringinc.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJWL8fwAAoJEK+E3vEXDOFbaq8IAJM1L/hOMN5u1uitpqtNQVWW
s6iAWYmmemH/1vIzMCk1GBp6RRLpd1Na7fNFIIoCY8hBV2VQY+oLge7AQ2BMqhGQ
exzCKgDLaR9b1icktnho2kDXVShUkv+WMCQPetKXV4VPHZ4sudqjRS1GWqqVtXx2
fKPnopESqreOdBP+dg1fCygN1MeKtZM1Sort2+j0Uxfvog1VNHzZ18AMrZXNQNMr
armK/JwwxAq7Ku5MbxkH0+zV6G+VxrVYfkOV7bEtgcHtnpRRPA32dLGLIwcoM7Ea
xcqrsehZSN+5K8+dskRFGVVWekpb0i7cX+UBg1GiIC7nJXpfIAreRckmtcVkXOY=
=MdqC
-----END PGP SIGNATURE-----