On 10/26/2015 02:51 PM, Martin Roth wrote:
I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree.
What other directories should be removed from the tree after the next release?
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native support, I don't think we want to haul around the AGESA implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little branch, but remove them from master. Gerrit is knows how to handle branches, so we already have the infrastructure in place to support this.
Alex
Alex G. wrote:
I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native support, I don't think we want to haul around the AGESA implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.
//Peter
Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.
So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.
When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.
BR Wim
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, October 27, 2015 9:35 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
Alex G. wrote:
I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native support, I don't think we want to haul around the AGESA implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
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
On Tue, Oct 27, 2015 at 9:01 AM, Wim Vervoorn wvervoorn@eltan.com wrote:
Sounds like a good idea to create a branch of these but shouldn't that be done for other boards as well.
So when you intend to remove boards to create version 4.2 you create a 4.1 branch of the existing state with those boards included. Then remove all boards that need to be dropped.
When it's handled this way it's probably easier to drop boards that aren't used actively and thereby dropping unnecessary maintenance work.
BR Wim
-----Original Message----- From: coreboot [mailto:coreboot-bounces@coreboot.org] On Behalf Of Peter Stuge Sent: Tuesday, October 27, 2015 9:35 AM To: coreboot@coreboot.org Subject: Re: [coreboot] Proposal: Removing obsolete & EOL boards and chipsets for 4.2 release
Alex G. wrote:
I'd like to start a discussion about boards, chipsets, drivers, or other code that can be removed from the tree.
All of AGESA fam10 and fam15. With Raptop Engineering upstreaming native support, I don't think we want to haul around the AGESA implementations, which have been troublesome in the past.
Actually, branch off those boards, keep them alive in their little branch, but remove them from master.
Hm maybe. It's important that the boards which use AGESA are still available somehow, so that they could be ported to coreboot init if someone has interest in doing that. Maybe a branch is good enough.
//Peter
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
-
Alex G. -
Martin Roth -
Peter Stuge -
Wim Vervoorn