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