[coreboot] release engineering process

[ron minnich]

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 at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20141108/4830b772/attachment.html>