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
signature.asc
Description: OpenPGP digital signature
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
