On Fri, Mar 21, 2014 at 6:52 PM, Alex G. mr.nuke.me@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