[coreboot] release engineering process

[Patrick Georgi]

Am 08.11.2014 um 19:04 schrieb ron minnich:
> So, if I understand correctly: We have no master tag as patrick says.
> The tags are always of the form yyyy.q where q is 1, 2, 3, 4
If we go that route - I brought up the quarterly releases, but maybe
something else is more useful.

Counter points to my proposal of mid-{feb,may,aug,nov} (that were
brought up on IRC):
- q3 is historically a slow time in the project, due to northern
hemisphere summer.
- the q1 date I proposed, february 15th, sometimes collides with chinese
new year.
- we might want to coordinate with important conference dates (eg.
fosdem) or OS release schedules.

> When you checkout you get the current latest branch.
Users get a choice:
Either use the master branch (which is still the default, though it
looks like we can change that in gerrit), where anything goes. That's
useful for active development.

Or go for the release tag, if you want something that should work out of
the box.

The release tags can also serve as blueprints for the binaries that you
proposed elsewhere in the thread (once we get to do them).

> The test for being in the latest branch is that you booted and ran
> the new, simplified board status program (available as binary for 386
> or armv7 for situations where a compiler is not available) from
> coreboot.org <http://coreboot.org>. If it has not been run for a
> given board the board is not visible in that branch.
I'd iterate from what we have (ie. our script), but yes. And it should
be easy to use (ie. unlike now).


I'm not sure on the details of the process. It could work like this:

We have a public long-term calendar on which we schedule releases, so
people can plan.

One week before we branch master into a release branch, we announce that.
The expectation is that master becomes calmer for a week, so people
should avoid pressing the "submit" button for cross-tree changes for
that period.

On creation of the release branch, we announce the release candidate one
week later.
The release branch should only get board specific fixes, no "SMM rewrite
on i945 to fix intel/d945gclf" that may break other boards, to pick an
example from my TODO list. If a board requires something that large at
this point in the process, it's out of luck for this release.
One exception to the rule: just-introduced breakage inherited from
master could be reverted if there's agreement that it's the right thing
to do.
After the release branch is created, master is open for action again.

On creation of the release candidate tag, we announce the release one
week later.
This is the time to work on release notes on the wiki ("board X has cool
new feature Y", ...), and sending in release test results.

One week later, we drop all boards without successful testing (only
change between rc and release) and create the release tag.
Also, send an announcement to the list, do PR, fireworks, ...


We require testing at least in the week after the rc tag, but that's a
risky proposition, so whoever wants to get a board in should also test
shortly before the release branch (to be able to fix grave issues) and
in the week after (to find minor issues that reappeared).


The only difference between the release candidate tag and the release
tag is that the former still contains all boards as of master, while the
latter is pruned down to only the validated boards (ie removal of
directories inside src/mainboard/*).

Rationale: When we release, we want to be _really_ sure that last minute
changes don't break things. It should be possible to contain the impact
of removing mainboards (src/mainboard/*/Kconfig, and file removals for
dropped boards)
Ideally the mainboard removal can be scripted and its non-impact on
other boards tested to some degree. Otherwise it might be better for now
to keep other boards in the tree and refer to supported boards in the
release notes only.

> I like the idea of releases, and tags, but feel strongly that the 
> process has to have some teeth or it has no meaning. There has to be
> a qualification for being in the release besides "ran 3 years ago."
My main issue is that I'd like to see the release process work before we
give it teeth (eg. removal of boards from master). I guess that we'll
rework things the first few iterations as we see what works and what
doesn't (eg. where we need more or less time).

coreboot is different from other open source projects that we can't run
a test suite in some central location and "bless" the tree with a tag
once it passes. We need those testing phases.


Patrick

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141108/bb2812b1/attachment.asc>