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

[Kyösti Mälkki]

On 03/22/2014 06:18 AM, ron minnich wrote:
> 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.

Hi

Ron, would you be so kind and identify by commit hash some of these code 
merges by "inexperienced guys" from last 2-3 years that "broke a bunch 
of boards". I would like to see from gerrit history how these problems 
were ultimately dealt with and hopefully we could all learn from the 
mistakes that were made.

I could list some breakage, but the ones I can remember were all 
submitted by experienced long-term commercial contributors, and would 
not exactly match the criteria of your argument. If we look closer, 
probably every suggested gatekeeper is involved with merging such commits.

For an extreme sample of review process try follow this:

AMD CAR: Fix issue with gcc 4.8.x
http://review.coreboot.org/#/c/4205/

We have everything there -- a change in CAR init already approved in 
Chromium git without testing, test results for boards the changed code 
is never built for, test results for boards the change is not built for 
because of a Kconfig option not being set. We have developers from 
Chromium, SAGE and AMD involved in review. We have a couple commmunity 
developers involved. And all this to avoid breakage in some mostly 
obsolete K8 or fam10 platform we have in the tree.

Some changes to review process are certainly welcome. I just hope Stefan 
would have included separate section of the current problems and more 
details of the goals his proposal tries to address. Even some of the 
obvious ones are not answered. For example, are there actual plans to 
bring coreboot trees from coreboot.org and Chromium back in-sync?

Regards,
Kyösti