[coreboot] release engineering process

Kevin O'Connor kevin at koconnor.net
Fri Nov 7 19:56:54 CET 2014


On Fri, Nov 07, 2014 at 09:13:27AM -0800, ron minnich wrote:
> I'm fine with regular releases with one proviso: if we announce a
> release date, and a version, and a test, then we drop all boards that
> are not working as of that date.

That seems a bit harsh to me, but I'm not against it.  Again, just my
2 cents.

Another (softer) approach would be to mark the board as
deprecated/unstable in the build/kconfig, and then remove it from the
tree if it's not tested by the next release.

[...]
> Or else we add a level to mainboard:
> src/RELEASE/mainboard
> or we drop the mainboard as a name, and just have src/<release>/vendor/etc.

Git is better at that then some revision control systems, but it's
still not good at it.  So I wouldn't recommend it.

[...]
> a release to me means that everything I find in src/mainboard/* is
> working for that release.
[...]
>we need a process for killing old junk, and a release process is
> as good as any.

Agreed.

-Kevin



More information about the coreboot mailing list