[coreboot] release engineering process

[ron minnich]

So here's a suggestion, inspired by the Go release process.

0. We have a standard go/no-go test, ideally a single command, that marks a
board as "good."

1. in a given quarter, we have a set of mainboards in src/mainboard that
are known good and are easily enumerable (via ls, ideally; i.e. I don't
have to go to a web site to see which boards are good). Call this Q+0.

2. in any given quarter, we are working on the mainboard release for the
following quarter. I.e., we are fixing code in src/mainboard. Call this Q+1.

3. Because a trivial chipset change can break many mainboards, the only
thing one can change for the following quarter is code in src/mainboard;
all other code changes can only apply to the quarter-after-next. Call this
Q+2.

4.  at the end of each quarter is the release; the set of boards "known
good" by the test (see 0) at the end of that quarter will be listed in (1)
as the known good set.


We hence have several overlapping activities, covering three quarters, made
more complex by the fact that fixing mainboard A can, if it involves
chipset code, break mainboard B. Hence the requirement that code other than
src/mainboard code can only apply to a release in the quarter-after-next.

ron
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141110/fb353fca/attachment.html>