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
-
Patrick Georgi