[coreboot] [announce] coreboot for the 21st century

[Paul Menzel]

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/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140324/3d549357/attachment.sig>