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...@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
signature.asc
Description: This is a digitally signed message part
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot