we had our last big discussion about building coreboot releases in
November. It quickly moved to the topic of removing boards that don't
comply to any kind of metric, and the discussion mostly went down with
So, since I really like to get a release process up and running, let me
a 'minimum viable' proposal here:
Let's decide on a schedule and create releases, with only minimal
testing for now.
There's no support and no guarantees which things work (before you
scream, see below).
The main goal is to learn how to do releases, and go from there.
From my point of view, a release entails the following:
- a timeline (for now, an announcement akin to 'next release will be on
- a git tag
- a tarball that contains that tree state
- release notes and changelog (a bit more than just git log)
For the first few releases, until we broaden the scope, those release
notes need to be very clear about the nature of these releases (and that
they are merely code dumps, not tested pieces of engineering).
From there, we could set ourselves goals, for example 'by the release
date the board(s) I maintain work with a commit that is at most a week
old, and I'll provide board-status reports with the released version'.
This provides us with a record of what happened between two points in
time. It provides goalposts to attach goals to. And we're building
experience with what kind of 'things work' guarantees are actually
realistic for us and which aren't.
From there we can discuss further ways to make use of those goalposts
(including dropping boards or chipsets, at some point). Or drop the
release concept if all that turns out not to be worthwhile - but with
the knowledge why it isn't.