Hi.
Thinking about Aaron’s plans some more and discussing some details, I’d like to propose a way to move things forward that I believe avoids the traps of older attempts at rewriting coreboot while keeping everyone in the loop.
We’ll start a new branch, proposed name coreboot-experimental. It doesn’t start from scratch but is branched from master at some point. coreboot-experimental will operate under different rules than master that simplify breaking things to push the design forward:
1. abuild is modified to know about two classes of boards: those “on board” the experimental branch, and those which are not. This can be as simple as adding some tag to the board status file (proposal: “experimental”)
2. abuild builds everything and reports everything but only “fails” for “experimental” boards, to get a clear view on jenkins
3. the tree keeps all chipsets and mainboards, so we keep history
4. breaking changes are accompanied by setting “experimental” tags on boards supported by that change. We might want to establish a rule of reporting those changes (and how to cope with them) on http://www.coreboot.org/Flag_Days
5. Supported_Mainboards might need some work to report both branches properly (so people can see at a glance if a board is supported by master, experimental or both)
6. jenkins builds both branches
7. interested parties can revive boards by fixing them
8. changes to master can be ported to coreboot-experimental. The other direction likely breaks things
9. at some point coreboot-experimental is either a success and becomes the new master, or it’s not and vanishes (maybe after picking the good ideas). Ideally this happens fast enough that master didn’t diverge too badly.
Comments? Patrick