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

[Stefan Tauner]

On Tue, 10 Feb 2015 19:22:31 +0100
Patrick Georgi  wrote:
> 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

TBH I have not followed that discussion very closely, so maybe that's
clear for everybody but me... but WHY do we need releases at all?

From my perspective it does not make too much sense, the board status
thingy is good enough... coordinating people to obey arbitrary
deadlines creates some friction that requires some rationale IMHO.
I for one would rather read some changelog-like newsletters/blog posts
and rely on board status than have some real changelogs + coreboot
"versions". So, what advantages do you hope for?

[Peter Stuge]

Stefan Tauner wrote:
> WHY do we need releases at all?

Consumers are completely overwhelmed by dealing with repositories.
> From my perspective it does not make too much sense,

IMO it doesn't really, it's just psychological. Consumers use
releases to judge ongoing development and assume that releases
are significantly better than a given master. They also use it
as a reference.

I think it's learned from commercial software lifecycles.
> So, what advantages do you hope for?

Advantages come in the future when we know what promises we keep for
a given release. That allows consumers to set their expectations and
plan ahead to some degree, which matters a lot within the industry.

//Peter