[coreboot] What commits, pushed by inexperienced people, broke the tree in the last 2-3 years? (was: coreboot for the 21st century)
paulepanter at users.sourceforge.net
Sat Mar 29 00:34:19 CET 2014
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.
> 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
> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 181 bytes
Desc: This is a digitally signed message part
More information about the coreboot