[coreboot] What commits, pushed by inexperienced people, broke the tree in the last 2-3 years? (was: coreboot for the 21st century)

[Paul Menzel]

Dear coreboot folks,


Am Samstag, den 22.03.2014, 19:44 +0200 schrieb 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 am interested in this too, as I heard this argument very often, but
according to my memory the claim is not true.

> 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.

[…]


Thanks,

Paul
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140329/62f8fec9/attachment.sig>