[coreboot] Release Engineering (again)

[Patrick Georgi]

Hi,

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 
that.

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 
february 32th')
- 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.

Thoughts?


Patrick