[coreboot] release engineering process

[Marc Jones]

Hi Patrick,

Thanks for starting this discussion.

On Thu Nov 06 2014 at 11:58:03 AM Patrick Georgi <patrick at georgi-clan.de>
wrote:

> 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.
>
>
I suspect that quarterly might be too frequent. May 2 or 3 times a year.
That would give more time to test and stabilize.


> * A number of weeks (2? 4?) before the official release date, we branch
> and only accept bug fixes into the branches.
>
> I am concerned about branching too soon and trying to maintain both master
and branch. Personally, I would like to see master go through a bugfix
period before branching. I think it would keep master healthier and
minimize the merge back effort after release.


> * 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.
>
>
We could update the coreboot KERNELVERSION as part of the branch process.
That will be helpful for for derivative works.


* 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).
>
>
>
These are all very valid reasons and I support any improvement was can make
in releasing coreboot source.  Thanks for Starting the discussion

Marc





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
>
> --
> coreboot mailing list: coreboot at coreboot.org
> http://www.coreboot.org/mailman/listinfo/coreboot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141110/4559c881/attachment.html>