Re: [coreboot] [announce] coreboot for the 21st century
On Fri, Mar 21, 2014 at 4:50 PM, David Hubbard david.c.hubbard+coreb...@gmail.com wrote: I've been thinking about it all day and it seems Vladimir is pretty much spot on, The proposition of gatekeepers would essentially kill community effort. There's just something I'm clearly not understanding here. For the first year or so of linuxbios, I was the gatekeeper. Nobody but me could push into the repo. We had lots of involvement. For many open source projects I've been contributing to, there's always a set of gatekeepers, and there's tons of community involvement. E.G., Go has a restricted set of people who can let a patch go into the upstream, and there is no shortage of people contributing. When I worked on FreeBSD, I was never one of the people who could push a patch into the repo, but my changes were accepted. It never bothered me much; those were the rules and I thought they made sense. So what is the issue again? I'm trying to understand. Is it the limited number? Is it the existence of gatekeepers at all? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Friday, March 21, 2014 09:18:07 PM 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. Let's be honest. Upstreaming contributions from Google has been a long and tedious O(n^2) process. Even though we've improved a bit in terms of jenkins build time (optimizations to abuild et. cetera) so that we don't have to wait one week for a bomb to verify, the workflow of one review per patch is still sub-optimal. So, first, the intent of the six gatekeeper idea is, in part, to be sure we're being very careful about what goes in. [...] Six seems a very arbitrary, even number. [...] 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. I think we need to restart this discussion without the implicit assumption that gerrit is a part of the workflow. We can do what Linux does. Different individuals maintain different sub-somethings of the coreboot tree. I'm not trying to establish any criteria for maintainer status. Short answer: 1* Google team (*) assigns a coreboot representative 2* Rep decides it's time to merge some good branch 3* Rep takes internal branch, and works on top of branch 4* Rep makes branch mergeable 5* Rep submits pull/merge request to maintainer (**) of touched code 6* Maintainer reviews branch as one unit and requests changes 7* Rep applies changes on top of branch 8* Repeat 6 and 7 as needed 9* Maintainer likes what he's seeing, merges branch to his tree (*) They're still welcome to hang on IRC, ML, and/or submit individual patches. (**) Maintainer and rep must be different persons, preferably not from the same team and/or not from teams working on the same thing. This process eliminates the *twice* review. Individual patches are no longer reviewed upstream; however, a review is still done, and corrections are still applied. Since a logical change is a branch rather than a patch, the overhead is reduced significantly without eliminating the community scrutiny phase. You keep all the goodies and reduce review complexity from O(n^2) to O(1). Sound good so far? But wait! There's more! As a bonus, considering that individual patches are no longer altered, we have the hashes of shipping firmware. So, why is this better than the gatekeepers idea? * We don't bottleneck patches by limiting number of submitters/maintainers * Maintainers can focus on the part of tree matching their expertise * Reduces patch bikeshedding as maintainers have the final word Take this a step further: maintainer trees are not the master tree. Maintainers still have to periodically get their branches merged with master. Finally, a simple question here: how many gatekeepers are there for the final full released version of each version of the Linux kernel? Do you want me to answer that in binary, ternary, octal, or hexadecimal? Those gatekeeprs don't deal with individual patches, do they? My $.02 anyway. Keep on sending them. A few hundred more of them, and I'll have enough for a cigar. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
If you're going to make big changes to what happens at coreboot.org, you have to get buyin from the folks who do all the work. I'm not the right person to propose this to :-) Put simply, it's above my pay grade. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
On Friday, March 21, 2014 11:19:42 PM ron minnich wrote: If you're going to make big changes to what happens at coreboot.org, you have to get buyin from the folks who do all the work. If we're going to refactor the development model, I insist we do it right. Patrick was discussing gitlab as a possible alternative to gerrit. I think it's time to closely evaluate our options. I'm not the right person to propose this to :-) I think I CC'd the ML. Yup, I did. Put simply, it's above my pay grade. Ran out of $0.02 on this? :) Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
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 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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Thu, Mar 20, 2014 at 10:55:57PM +0100, Stefan Reinauer wrote: Changes to the coreboot Project Structure We -- the coreboot project -- have succeeded beyond our wildest expectations, with every major laptop vendor using our code. [...] To ensure consistency, scalability and conformity with the general coreboot strategy, we need to define a clear committer structure that defines the original project structure of having a benevolent dictator aka project leader (Stefan Reinauer) and gatekeepers in place. I think it would be a great to clearly define and document who the ultimate decision makers for patch acceptence are. So, all in all, this sounds like a good thing to me. Just my $.02. -Kevin -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] [announce] coreboot for the 21st century
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Regarding name for community branch (for maintaining old boards). On 20/03/14 21:33, Stefan Reinauer wrote: Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Oldboot. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTLj14AAoJEP9Ft0z50c+UFHoH/3jQI8NoQig3c/awn75AZlLb D0WHy0IHsrVdi23+SpAB4rwo5rQe0/c+cjAxujGjpuHDfxXHABnI235as8An1q83 JYQ55dRtTB+bOLsf+Oa3/xKhR/VRUm7JKNmo7HM9bL+K0u9xMJfxWt9uwJ2rNssE rX55Z66jN1groIVqK56I+dydVy0dn66sxaeUPxzF10nbFLUiH+LcITLn0fzLNwHS GO7+zVGCvI5mU7AwD4Dr8pJ4HJLk6kJBQJv461KEhjq26SZrND2LDuneNFSt2Emv 2hL1kT9BXhJdbECUToBGbTy3AVYbfJV2jXmVfKQgKxWYy0vPhr7Ble/YF/odIws= =G+E3 -END PGP SIGNATURE- -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
Vladimir 'φ-coder/phcoder' Serbinenko wrote: The proposition of gatekeepers would essentially kill community effort. That might not be a bad thing. Unfortunately, considering how the hardware industry works, individual contributors in the community can't work on code for current hardware. coreboot is only relevant once it supports the hardware that is being designed in. After design is done the window is closed; a firmware has been chosen, and coreboot wasn't on the table. By current hardware I don't mean what is shipping or what is being implemented in coreboot. Current hardware is what is being designed by silicon vendors. The time between design and shipping products is on the order of several years and the longer it takes for coreboot to run on that silicon the less relevant coreboot is. By the time individual contributors can make significant contributions for a particular silicon that silicon is long obsolete, so those efforts will only tend to support coreboot as a pointless niche project. That's not why I contribute to coreboot. Even in current infrastructure reviewing is a major slowdown. As it should be. The purpose of peer review is to increase quality of the codebase by having one or more peers review changes. Of course that will take time. The more complex a project is, the less development will be about writing code. Writing code is just typing. The hard work happens before, trying to create a design the implementation of which will actually solve the problem, and after, trying to find out whether the implementation actually *does* solve the problem as intended and without introducing unforeseen issues. A high rate of change means that all time is spent on writing code and no time is spent either on thinking about the problem beforehand or on analyzing results after the fact. That will decrease quality. The discussion about slow or fast is distinct from the one about if and how commercial and community can work together. Both are important and I think now is a good time to have them. You cannot treat community as some kind of corporate entity. You're right, and it's exactly why individual community contributors are so limited in what we can do in coreboot. Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Sounds like a joke. While Peter is competent, he's also very busy. I'd expect his review thoughtput of perhaps a patch a week. I think your estimate may even be on the optimistic side. You can't realistically put such burden on few people. As I understand the proposal, the kind of work that gatekeepers would do would be drastically different from the kind of work that reviewers must currently do. The burden for reviewers is currently very high because so many changes are not finished when they are proposed for review. Compare with Linux, where contributors more frequently than not send perfect patches which are very quick to review. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. I would find it highly undesirable for coreboot to be anything like Fedora. My experience with Fedora leaves quite some things to be desired. The changes you proposed would effectively make coreboot into corporate project. It already is and as Ron described it actually always was. It's not possible to make significant contributions for current hardware as an individual contributor. I think coreboot may have an opportunity to affect this, but certainly not by using brute contributor force. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. Try to mentally balance the commit graph a bit differently. I think part of the proposal was essentially to have a community branch? That isn't too different from creating a fork? //Peter pgp4CmbztPnCx.pgp Description: PGP signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
