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