[coreboot] [announce] coreboot for the 21st century

[ron minnich]

On Fri, Mar 21, 2014 at 6:52 PM, Alex G. <mr.nuke.me at gmail.com> wrote:

> The bad-ness or good-ness of motives is relative. Note that I'm not
> using "bad" in the sense of "evil". Let's look at the six gatekeeper idea:
>  * Easier for commercial entities to upstream code, therefore faster
> progress for coreboot (good motive). (a)
>  * Easier for commercial entities to upstream code, therefore we can get
> lazy even if code quality drops (bad motive). (b)

That's not the intent. The way you are stating this has a lot of
built-in assumptions, and you're mixing some things up. That's our
fault; the old rule is, that if someone did not understand what you
said, it's your fault, not theirs. So, speaking as one of the guys who
reviewed the email, I'm sorry it was not clearer.

So, first, the intent of the six gatekeeper idea is, in part, to be
sure we're being very careful about what goes in. We've had some cases
over the past 2-3 years where some inexperienced guys pushed 'commit'
on code that broke a bunch of boards -- in ways that were not obvious.
We would like to avoid that. As we've learned the hard way a few
times, there are not that many people who have the perspective of long
experience and a view of all the boards, and know how trivial changes
can have far-reaching consequences.

Now, can this be serious? Yes, very serious. There was a laptop (no
names mentioned here, ok?) I know of in which the vendor made a
trivial  several line change which caused memory corruption on resume.
It shipped. The BIOS was baked in; the recovery had to be implemented
in the OS. That kind of thing is not fun. But now that coreboot has
succeeded in such a big way, trivial changes can have very serious
consequences, and we need to be more careful than 15 years ago when it
was just us hackers. This is in part why I'm not generally happy with
unifying code -- because trivial changes can have unforeseen
consequences, and in the past one of the pain points has been
well-intentioned code unification ideas that resulted in propagating
bugs from one chipset to another.

As for "easier upstreaming for commerical guys", again, your summary
is wide of the mark -- again, not your fault. The review process has
gotten a bit tricky, for the simple reason that the same guys that can
+2 reviews to the chromeos coreboot repo end up having to do it twice
for the upstream. It's a consequence of the fact that the commercial
guys have to build coreboot for a product and end up having to develop
code they can't upstream immediately. Can we skip the whole discussion
of why this is necessary, btw? It is.

Coreboot has succeeded. Many people that are authoring coreboot code
also work at companies now -- kind of like what's happened with Linux.
It's not something we had to deal with 3 years ago.

But it makes no sense for, e.g., Duncan Laurie to have to +2 Aaron
Durbin's very fine code twice. First off, these two guys have full
time jobs (well, 2, really, packed into one, they work hard), they
write some of the best code that goes into the repo, and at least from
my point of view, a +2 from either of them is usually good enough for
me (that also applies to lots of people outside, btw; when I see +1 or
+2 from a lot of you folks, I know the review is going to be easier
than if I start from nothing. Some of you would be surprised how much
I depend on what you write, even when I complain about some of your
commit messages :-). Plus, the internal review process on the chromeos
coreboot repo is extremely rigorous (and annoying at times).

So it's not about "Easier for commercial entities to upstream code" --
it's about not having to do the full review process *twice*, given
that the code has been picked to pieces by experienced long-time
coreboot coders, most of whom (no offense intended) are better
qualified to review the code than almost anyone else. That's why I
claim what you are saying as not quite right.

Finally, a simple question here: how many gatekeepers are there for
the final full released version of each version of the Linux kernel?

My $.02 anyway.

ron