Dear Stefan, dear coreboot folks,
Am Donnerstag, den 20.03.2014, 22:33 +0100 schrieb Stefan Reinauer:
coreboot for the 21st century
setting up the project for the next decade
thank you for starting a public discussion!
Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855)
coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden.
- It is hard to keep 250+ mainboards working. Actually impossible.
- Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases
- We don’t test except on the very last stuff we’re working on
To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive.
For the first time in 2014, and every few years after that (e.g. every two years), we will create a new “community branch” that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports.
A question to the Git expert. Is there a way to model the requirements in a different repository structure, for example having a core coreboot repository and putting the chipset, Super IO and boards in separate repositories? I think, the OpenEmbedded/Yocto project does something like this and they call it layers [1]. I have no idea though how that worked out for them. My impression from when they started it was, that the initial setup was more difficult in comparison to having everything in one repository and I guess the layers break more often. Also incentive to care for all the layers might be not so high.
A policy has to set up though, when and how changes to the core repository can be made so that the maintained/supported board layers are not broken.
After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1.
I suggest to bump the major number by one, that means coreboot 5. Why not even use the year, so make it coreboot 2014, which is easier to recognize too.
Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner.
Where are these supporters/owners documented? What requirements do they have to fulfill, which if not met cause the board removal?
If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure.
I agree that, people wanting to keep a board in the tree have to help supporting it by at least testing them in a timely manner.
In 2016 we will do the same thing again, and it will become coreboot 6.0
As written above take the year as the version would be useful in my opinion. I also would increase the minor number each time a new board is submitted/merged or an unmaintained one is removed.
Appendix A: romcc boards to be removed
advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n
As others noted, it has to be decided what to do with boards, that do not adhere to current requirements due to missing hardware features and not because of lack of maintenance/support as the Bifferboard and DMP Vortex86 EX.
Thanks,
Paul
[1] http://www.openembedded.org/wiki/Layers_FAQ [2] http://layers.openembedded.org/layerindex/branch/master/layers/