[coreboot] release engineering process

[Patrick Georgi]

Hi all,

those walls of text recently certainly gave a lot of information to digest. I'd like to discuss one aspect that got indirect coverage only, which is the desire to have some boards be "stable" (for some definition of stable). It comes up every now and then and this time it was in the form of "please leave boards X, Y, Z alone".

We have a pretty chaotic development process that allows for lots of velocity all over the place. Unfortunately that makes the only useful stable name in our repository ("master") quite unreliable for users. The board-status script and wiki page is a nice approach, but given that every board is tested on a different commit id, I wouldn't trust a "green" box there to say anything more than that _exactly_ the tester's configuration is going to work. For all I know, a theoretically suspend-capable board tested without that feature enabled (never-mind that board-status doesn't say anything about wake-up in the first place), may not even build with suspend enabled because that part of the tree was broken in just that revision.


With that in mind, I want to throw out some ideas:

* Let's have regular release cycles. maybe quarterly, eg in the middle of each quarter (that is, feb 15, may 15, aug 15, nov 15) to avoid certain vacation-heavy periods.

* A number of weeks (2? 4?) before the official release date, we branch and only accept bug fixes into the branches.

* for each release, we tag from the branch (so we have a _single_ commit id for everything), do a nice write-up on which boards we know are functional, known issues, and what notable changes there are compared to the previous release.

* board-status gets extended to track branches and tags properly (we need that for the classic branch already, since some boards are on the way out on master)

IMHO this gives us a couple of advantages over the current non-process:
It gives us the opportunity for exposure to the world since releases tend to draw some media attention.
And it may encourage some more focussed testing (on board-status) than the current approach, which may increase participation - having your port listed as working on the 2015.08 release notes is a bigger incentive than some green box on some obscure wiki-page.
We can point people to certain revisions with more confidence (and with a nicer name than a SHA1 of a random tree), which will make vendors' lives easier (and in combination with that media exposure, also community support on #coreboot and the list when people ask what revision to use).


This is definitely written for discussion, not a blueprint I intend to implement ASAP.
I'm not even sure if I still like the proposal tomorrow.
Any specifics are just there to give the concept more meat, I have no idea if they work out.
Maybe we don't even need anything like this?
Consider it a conversation starter and add your comments :-)


Thanks,
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/20141106/27e6b823/attachment.asc>