Am 07.11.2014 um 18:13 schrieb ron minnich:
I'm fine with regular releases with one proviso: if we announce a release date, and a version, and a test, then we drop all boards that are not working as of that date.
We could drop them in the release branches. That would be a nice project for a "clean out a coreboot tree" script that you give boards to kill, and it removes boards (and maybe even chipsets once their last user is gone), which I believe may also be of value in other places.
With the right Supported_Mainboards treatment, that gives us a good visualization of boards without maintenance over a longer period, which can help justifying cleaning out master. But before we can assert that no maintenance happens, we first have to collect data - as it stands we have none, and over time releases can provide useful signal. I'd still not kill boards entirely because they miss one release, since people are preoccupied with other stuff every now and then (both hobbyists and those with commercial backing). We'll see how things go, and we don't need to work out the precise board retirement schedule right now - we don't even have releases yet.
It's git, we can bring them back.
It's git, we can't. (git's notion of history is... interesting)
But a release to me means that everything I find in src/mainboard/* is working for that release.
That's reasonable - in a release branch/tag. (under my proposal we never "release" master)
of the 2015 Q1 release. Bringing a mainboard forward works like this: git mv src/2015.1/google/pepppy src/2015.2/google
git mv is a kludge, and git's heuristics break in our tree because we have so many files that look quite the same.
Tags also have the advantage of pointing to a single commit, unlike the "some commit in february 2015 used to work" signal of src/2015.2.
It does not move forward unless we have a passing test. We need to define a passing test. The ubuntu one looks as good as any.
I agree that board-status isn't the whole story, but I'd like to make that a standard test for us before we add all kinds of other requirements.
Simplifying the use of board-status would be a nice side-topic: build a disk image with board-status so that running it is a matter of writing to USB flash and booting from it.
But we need a process for killing old junk, and a release process is as good as any.
Again, these are different useful things that are vaguely related.
Patrick
Patrick, the tag idea is great.
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
When you checkout you get the current latest branch. 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. If it has not been run for a given board the board is not visible in that branch.
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."
Is this any closer to what you are thinking, Patrick?
ron
On Sat Nov 08 2014 at 2:05:01 AM Patrick Georgi patrick@georgi-clan.de wrote:
Am 07.11.2014 um 18:13 schrieb ron minnich:
I'm fine with regular releases with one proviso: if we announce a release date, and a version, and a test, then we drop all boards that are not working as of that date.
We could drop them in the release branches. That would be a nice project for a "clean out a coreboot tree" script that you give boards to kill, and it removes boards (and maybe even chipsets once their last user is gone), which I believe may also be of value in other places.
With the right Supported_Mainboards treatment, that gives us a good visualization of boards without maintenance over a longer period, which can help justifying cleaning out master. But before we can assert that no maintenance happens, we first have to collect data - as it stands we have none, and over time releases can provide useful signal. I'd still not kill boards entirely because they miss one release, since people are preoccupied with other stuff every now and then (both hobbyists and those with commercial backing). We'll see how things go, and we don't need to work out the precise board retirement schedule right now - we don't even have releases yet.
It's git, we can bring them back.
It's git, we can't. (git's notion of history is... interesting)
But a release to me means that everything I find in src/mainboard/* is working for that release.
That's reasonable - in a release branch/tag. (under my proposal we never "release" master)
of the 2015 Q1 release. Bringing a mainboard forward works like this: git mv src/2015.1/google/pepppy src/2015.2/google
git mv is a kludge, and git's heuristics break in our tree because we have so many files that look quite the same.
Tags also have the advantage of pointing to a single commit, unlike the "some commit in february 2015 used to work" signal of src/2015.2.
It does not move forward unless we have a passing test. We need to define a passing test. The ubuntu one looks as good as any.
I agree that board-status isn't the whole story, but I'd like to make that a standard test for us before we add all kinds of other requirements.
Simplifying the use of board-status would be a nice side-topic: build a disk image with board-status so that running it is a matter of writing to USB flash and booting from it.
But we need a process for killing old junk, and a release process is as good as any.
Again, these are different useful things that are vaguely related.
Patrick
-
Patrick Georgi -
ron minnich