[coreboot] Changes to the coreboot Project Structure -- one small step for bike sheds
Let's think of a few things which makes gerrit annoying: * -2 is a de-facto veto * -1 is not persistent on updates, encouraging -2 to be given The end result is that we're encouraging vetoing of patches. Proposal: * Submitability of a patch is based on overall review score ** Need at least a score of +2 for patch to be submitted ** Maybe (?) a score of +3 to require at least two sets of eyes * A review of -2 is not a veto ** Patch still submittable if overall score is +2 (or +3) * Score of -1/-2 is persistent until reviewer retracts it Requiring a review of +2 is possible, but not necessarily needed. Since only persons with +2 rights can submit a patch, their submitting a patch based on a +1/+1 review is effectively an approval. This has the effect of increasing the significance of -1/+1 scores, which, in the old scheme, were somewhat useless (an infinite number of -1 scores would not prevent a patch from being submitted). I think we should try this system, and see how well it works. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way
Not so long ago, Stefan announced some pretty drastic changes to the project structure. While I believe he wanted to discuss the direction and find a mutually agreeable direction, his email still raised the aneurysm level to over nine thousand. So, how about we take the good ideas out of there and start putting them in practice. Today, I'll be focusing on the idea of MAINTAINERS. While it's nice to jump straight to maintainer trees, that's a long ways away, and I'm not even sure we reached consensus on it. Couple that with the changes needed to be done to _both_ gerrit configuration, _and_ gerrit workflow, this matter is better left for another day. What we can do, however, is to start assigning maintainership of different sub-directories. Two ways to do it: (i) One big MAINTARES file in top-level directory (ii) One small MAINTAINER file in each directory with an assigned maintainer Number (i) is human friendly, while (ii) is parser-friendly (I would hope). Now comes the fun part: For directories with a maintainer, gerrit implements a MMA criteria. That's short for Maintainer Must Approve. People are still welcome to do reviews, bikeshed, etc, but the maintainer has veto power. For directories without a maintainer, the old workflow applies (no MMA). This should reduce confusion from conflicting reviews, and definitely reduce number of incidents where a patch gets merged with a review from a person who is not fully qualified to, well, do the review. Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way
Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke: Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. While we're specifying behaviour: what should happen to changes that affect multiple maintainer domains? (and before you say they shouldn't exist, refactorings regularily hit the entire tree) Patrick signature.asc Description: This is a digitally signed message part -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure -- the non-aneurysmal way
On Wednesday, March 26, 2014 03:32:12 PM Patrick Georgi wrote: Am Mittwoch, den 26.03.2014, 09:22 -0500 schrieb mrnuke: Masters, of Gerrit, the pleasure of training gerrit to implement this change is left entirely to you. While we're specifying behaviour: what should happen to changes that affect multiple maintainer domains? Add each maintainer to the MMA list. A little clumsy? Yeah. On the other hand, it encourages splitting of patches in maintainer-domain chunks. (and before you say they shouldn't exist, refactorings regularily hit the entire tree) And that's one of the few cases where the above splitting may not be possible. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* ron minnich rminn...@gmail.com [140325 06:34]: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? Keeping old boards in a branch of coreboot that is not moving as fast as upstream will reduce breakage and stabilize the code base for those systems. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Tuesday, March 25, 2014 06:56:13 PM Stefan Reinauer wrote: * ron minnich rminn...@gmail.com [140325 06:34]: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? Keeping old boards in a branch of coreboot that is not moving as fast as upstream will reduce breakage and stabilize the code base for those systems. This model works for linux with really old releases being maintained by interested people. It is doable. It is reasonable. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* mrnuke mr.nuke...@gmail.com [140325 19:13]: On Tuesday, March 25, 2014 06:56:13 PM Stefan Reinauer wrote: * ron minnich rminn...@gmail.com [140325 06:34]: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? Keeping old boards in a branch of coreboot that is not moving as fast as upstream will reduce breakage and stabilize the code base for those systems. This model works for linux with really old releases being maintained by interested people. It is doable. It is reasonable. Yes, absolutely. These old releases live in extra branches. Same thing we need to do. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
Dear Stefan, dear coreboot folks, Am Donnerstag, den 20.03.2014, 22:55 +0100 schrieb Stefan Reinauer: Changes to the coreboot Project Structure We -- the coreboot project -- have succeeded beyond our wildest expectations, with every major laptop vendor using our code. Going forward, this will require a few structural changes that will ensure that the vendors shipping coreboot products can count on a stable, reliable code base. With that incredible success, there is also a lot of work to be done to make sure the project is scaling and keeping up with the requirements of the millions of new users that coreboot gets every year. There is a large number of new corporate entities investigating their possible involvement in coreboot, and we need to make sure that their integration is working smoothly while still keeping the project’s interests and goals stable and alive. thank you once again for bringing up this discussion on the list! I’ll reply in a separate thread about coreboot’s interests and goals. Moving forward, we need to make sure that we can welcome these possible new contributors without the friction that we have seen in the past. Could you please name the friction seen in the past? The coreboot community currently consists of about 80 contributors with varying levels of activity. Among these contributors, three groups can be identified as the major stakeholders in the project: Sage Electronic Engineering (the largest coreboot IBV), From a community perspective there is currently not a lot of interaction between the community and Sage Electronic Engineering. The last commits in the upstream repository are also a few months back. Secunet and Google Inc. (delivering all new Chrome OS devices with coreboot based firmware). Did you count AMD contributions to Sage Electronic Engineering? Individuals employed by these three stakeholders make up for the majority of code contributions. According to Ohloh, roughly half of the coreboot contributions are done by the top ten contributors. Over the project life time, over 80% of those have been made by corporate contributors. Do you have an URL? As always such statistics should be taken with a grain of salt. Especially how AGESA is counted for example and regarding that a lot of board code is copied over and is not unified. While there is a fairly good understanding of the project direction and interest between those individual contributors, there are also an increasing need for making sure that the coreboot project’s scalability and its viability for mobile / consumer products and servers is guaranteed. As written above, to me the direction and interest is not so clear to me. (See my (future) reply in a separate thread.) Also the reasons for the need is not so clear. Could you please elaborate on that? The only thing I imagine is the long time it takes to upstream a board for Google because they do not use the upstream infrastructure right away. The goal of this proposal is to enable all of the community to have a strong voice and make strong contributions to the project while allowing the major stakeholders to steer the project direction and pursue ownership of the components they provide. I thought that is the case currently. Traditionally the development model of coreboot was very similar to the model of the Linux kernel in many ways, including coding guidelines, the requirement of a sign-off process for contributions, and active leadership provided by a “benevolent dictator”. Commit rights were traditionally given to few of the top contributors of the project. With the introduction of git as coreboot’s version control system and its multi-branch nature as well as gerrit for code reviews, the landscape of the project has slightly shifted towards a more anocratic development model in which different interest groups sometimes worked on opposing strategies, and thus affecting the project’s overall stability and suitability for large scale deployment negatively. The advent of these new tools requires the original project founders and major stakeholders to provide stronger leadership and strategic direction for the project. Could you please give examples? My view is, that the problem is simply missing communication. If the companies develop something in secret without announcing and discussing their plans and miss what the community does, then this is solved by improving the communication with the community. Also in the past, my impression is, that (almost(?)) always the community gave in and reworked their patches and adapted the “corporate” code and improved that. Measures to improve the coreboot Development Model * Require authors to acknowledge changes made in their name (Forge-Author) This change allows contributors to decide when their OWN changes are ready for being integrated into the project, preventing unfinished and experimental work to be submitted accidentally
Re: [coreboot] Changes to the coreboot Project Structure
Hi folks, ok, sorry to those who thought that I was missing in action. It feels good to have a weekend to get out into the sun every now and then, and let the dust settle a little bit in a maybe too heated discussion. I will address your concerns. * mrnuke mr.nuke...@gmail.com [140320 23:42]: On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote: * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes [...] This is somewhat what linux does, and it works well for them. When we (Ron, Marc, Patrick, Peter, Aaron and I) wrote up the document, we tried to introduce some of the Linux kernel habits that might work well for us. Might be a little OT/irrelevant, but why not make gerrit need a maintainer must approve before making the change submittable. Yes, that would be a great way of implementing this. * Look into making gerrit automatically add reviewers based on maintainer lists [...] Can we find something better than gerrit? I think gerrit encourages too much bikeshedding. It also encourages people to filter out gerrit emails, so that any such maintainers would not get the message. This has come up before and we should consider that option. Gerrit is very convenient because it never loses a patch. Our mailing list based approach in previous years was way less reliable. Also, the integration of jenkins is very convenient. There might be other solutions that have both of these advantages. * Import previous code reviews and results The tree major stakeholders in the project all own internal code review systems, some of which are public (e.g. the Google Chrome OS repository) and have code reviews that include representatives outside of Google to ensure general code quality and making sure the improvements made for products don’t negatively impact upstreamability. For those cases it would be extremely helpful to honor the code reviews already done in the upstream repository Status: TO BE INVESTIGATED I couldn't disagree more. First of all, the idea of representatives outside of company to ensure general code quality is contrary to the idea of allowing the community to scrutinize to-be-upstreamed contributions. When you combine that with the idea of [blindly] honoring code reviews already done upstream, you have effectively eliminated the scrutiny and review from the community. When rebasing to a new coreboot version, e.g. the Chromium OS project does [blindly] honor code reviews already done upstream. On the contrary, I think that this strengthens the community instead of eliminating its reviews. I've seen mostly cases of great external reviews, but have also seen a fair share of bodged, nonsensical ones where terrible patches have been accepted without much thought. If the community has to accept code reviews done under closed doors, these contributions are effectively code dumps. I do not remember this ever being beneficial to the community, and usually results in the community needing to clean up afterwards. See linux for details. These reviews are not happening under closed doors. The Chromium OS project is open source and completely transparent in that manner. What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. Will it work for 100% of commercial contributors? No. However, this should be the preferred method for upstreaming contributions. See linux for an explanation why this works best. The intent of these suggestions is to move the non-commercial and commercial contributors in the community closer together. One example is the board ownership that would prevent people from messing with other people's boards without their consent. Also, if you are keeping an eye on both the Chromium OS coreboot tree and the upstream coreboot tree you will notice that basically all structural changes land in the upstream tree first, whereas the only thing that ends up in the Chromium OS tree first is code supporting specific components. This has proven to be somewhat successful as it keeps the person working at three a clock in the morning to ship a product under a tough deadline from going crazy because the target keeps moving under him. This is not a bad thing at all. It's the separation of feature development and product development, in a way. Google even does this for each of the Chrome OS devices, internally (as you can see in the Chromium OS repository) At some point there's a branch of the Chromium OS top of tree coreboot used as the basis for further product development and no new features go into that product branch (e.g. firmware branch) unless needed and carefully selected. I am sorry to say this Stefan, but, in my opinion, you
Re: [coreboot] Changes to the coreboot Project Structure
Hi Carl-Daniel, thank you for your feedback! * Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net [140321 01:39]: I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Those six people would not be required to take the full burden of code reviews. Nothing will change w.r.t that, because that would indeed create a huge bottleneck. This is just about the actual push. Any of the six can push any patch (given that the maintainers and/or authors have reviewed) - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. That is absolutely understood. However, I truly believe it is important to have community committers in place, even if it is a huge effort. Look at the subsystem maintainers of the Linux kernel, they don't have to review every single patch but often trust their peers in the community. I think that is a good model. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. The problem with flashrom is that in the last six months is has been a one man show (or two men, but only stefanct actually committed stuff). You guys are also worried to brick a system, whereas in the coreboot environment we know that we brick systems. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. This is not unlike the Linux kernel community. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. Let's keep this simple for now. As always, we will adjust our implementation bit by bit to the problems we'll actually hit. If we really go ahead with a fixed number of committers, each person should have a substitute who can take over. That would be a total committer number of twelve. I was thinking that these six would be substitutes for each other. With 12 people we would have more active committers than we have now. To be honest, regardless of who will be the community gatekeepers, some people are going to be disappointed. There would have to be a metric for determining community committers. It should be people that are best suited to act in the interest of the complete project. I don't think simple metrics like lines of code or numbers of reviews is sufficient for making a good decision here. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* David Hubbard david.c.hubbard+coreb...@gmail.com [140323 10:56]: Coreboot can be relevant even if it only supports obsolete silicon. Coreboot was the first to bring sub-second boot times to laptops. There are more examples. Yes, we worked hard to get to that goal. If it were about obsolete hardware it would have never happened though. But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. For a number of contributions Google's community members have worked upstream first (Think ARM port and rmodtool) A lot of times that was critized, as the expectation is on the other hand, that corporate entities provide ready to ship solutions, and not work in progress. However, we are keeping it up for many patches, especially those that introduce structural changes to coreboot, because we want to make it as easy as possible for our fellow community members to engage in meaningful conversation about these things. Mind you, at no time does any coreboot development work at Google happen behind closed doors. Everything, including the code reviews and up-to-date code repositories are visible and accessible by anyone out there. I don't feel limited. Corporate contributors are of necessity restricted -- e.g. to large commits after the product ships. I grok that. Is there a way to *reduce* the restrictions, and burdens in general, of corporate contributors? To get them to work directly upstream? Yes, and we continue to do that. Timely upstreaming/downstreaming is a vital part of the process, and it's not always easy. There will never be anybody trying to ship coreboot on any device working on top of tree upstream just because nobody wants to do another week of testing because some unrelated patch comes in last minute, or your target is broken overnight on the day that you ship a firmware image to a factory. However, all of the development process is completely open and anybody can look at the changes Google is doing to coreboot, upstreamed or not, in real time. I don't see anywhere in Stefan's *only* email on this subject that he suggested a community branch. Branches were Alex's idea: http://www.coreboot.org/ pipermail/coreboot/2014-March/077660.html My original suggestion for a name of the coreboot branch with the old boards (that get removed from top of tree) was community-2014. I believe this led to a lot of confusion among the ones wild at heart. The name seemed reasonable at the time because it would contain all the boards that you can get on ebay but not in a store anymore. I don't think we need to get hung up on names though, anything is fine, really, as long as it's not too hard to type and somewhat descriptive ;) Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
* David Hubbard david.c.hubbard+coreb...@gmail.com [140323 20:33]: On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. Tried to do so in the other mail... There's too much risk involved in working directly on upstream. The downsides just outweigh the benefits (for everybody, really) For example, when getting to the hot phase of a new product, we don't even use our chromium top of tree, but create a firmware branch specifically for a new product. Patches relevant to that product go into that branch (and top of tree, aka HEAD) but NOTHING else. For every firmware image that is released, there are also tests involving thousands and thousands of reboots and suspend/resume cycles to make sure that the product is absolutely stable. Because if 1/100k resumes crashes that means for a million users there are ten users every day whose computers crash. This level of testing is simply not possible when aiming at a moving target. Stefan -- 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 phco...@gmail.com [140321 04:31]: The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. This is absolute nonsense, Vladimir. You cannot treat community as some kind of corporate entity. Nobody tries to do that. 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. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. Your mere idea that there is some sort of corporate conspiracy acting against the interest of the community from which you automatically exclude anybody working on open source software for a day job is flawed. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. Please note that the committers don't have to be the ones to do the code reviews. If you feel like you want to work on a fork of coreboot, you are most welcome to do so. Many projects have forked over time, and some forks have died off, or taken over the role of the main project. Good luck. If this helps you get over your negative attitude you are spreading here, I fully support it. Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Vladimir, this has nothing to do with anybody pushing anybody out. Your behavior here is your personal choice. It's fine, but don't blame it one anybody else but yourself. You think I am hurting this project? Do your own. The grass is always greener on the other side, and you can do what you want over there. Stefan -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 02:33, Stefan Reinauer wrote: * David Hubbard david.c.hubbard+coreb...@gmail.com [140323 20:33]: On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. Tried to do so in the other mail... There's too much risk involved in working directly on upstream. The downsides just outweigh the benefits (for everybody, really) For example, when getting to the hot phase of a new product, we don't even use our chromium top of tree, but create a firmware branch specifically for a new product. Patches relevant to that product go into that branch (and top of tree, aka HEAD) but NOTHING else. For every firmware image that is released, there are also tests involving thousands and thousands of reboots and suspend/resume cycles to make sure that the product is absolutely stable. Because if 1/100k resumes crashes that means for a million users there are ten users every day whose computers crash. This level of testing is simply not possible when aiming at a moving target. I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. Stefan signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 25.03.2014 06:34, ron minnich wrote: On Mon, Mar 24, 2014 at 10:20 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com mailto:phco...@gmail.com wrote: I don't see how this prevents any of my propositions for the bulk of the boards. The problem you describe isn't going away with your proposition. We still want to have a top which is supposed to work on all boards. All boards? The Arima HDAMA, 12 years old now, not sold for maybe 10? All boards? Are you sure? That's why I added *supposed to*. I'm aware that some boards are probably broken and not much we can do about it. ron signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Mon, Mar 24, 2014 at 10:37 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: That's why I added *supposed to*. I'm aware that some boards are probably broken and not much we can do about it. Except remove them, right? ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Can you guys stop fucking worrying about a fork for the time being? We'll fork if we have to, but right now, we should be focused on refactoring the development process. If we do the latter rather than the former, chances are we'll find a mutually agreeable and better process. Stop pulling out rulers and unzipping your pants. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sat, Mar 22, 2014 at 9:10 PM, Peter Stuge pe...@stuge.se wrote: 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. Peter, you make good points. As a purely community contributor I'd be happy to sign any necessary NDAs to contribute on Google designs. Take a look at the Linux Foundation NDA program: http://www.linuxfoundation.org/programs/developer/nda Coreboot can be relevant even if it only supports obsolete silicon. Coreboot was the first to bring sub-second boot times to laptops. There are more examples. But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. 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. I don't feel limited. Corporate contributors are of necessity restricted -- e.g. to large commits after the product ships. I grok that. Is there a way to *reduce* the restrictions, and burdens in general, of corporate contributors? To get them to work directly upstream? 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. Reviewers could reject patches as incomplete. Ron, Alex, can you please list specific commits that (for Ron) broke multiple boards unnecessarily / (for Alex) bodged, nonsensical terrible ones? Those commits seem to be at the heart of this question. 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. So let's affect this. 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? I don't see anywhere in Stefan's *only* email on this subject that he suggested a community branch. Branches were Alex's idea: http://www.coreboot.org/pipermail/coreboot/2014-March/077660.html Stefan appears to be missing in action. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sun, 23 Mar 2014 03:56:35 -0600 David Hubbard david.c.hubbard+coreb...@gmail.com wrote: Stefan appears to be missing in action. No, well, he has stated that he want to wait till everybody has calmed down (on IRC). It looks to me that he may have to wait indefinitely though, and I would also like to see some reaction from him to the harsh opinions given. I can't comment on the substance of the proposal, but the reactions from the (for me) most diligent and competent community members tells me that something in it or how it was presented is clearly flawed. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
David Hubbard wrote: Unfortunately, considering how the hardware industry works, individual contributors in the community can't work on code for current hardware. Peter, you make good points. As a purely community contributor I'd be happy to sign any necessary NDAs to contribute on Google designs. Take a look at the Linux Foundation NDA program: http://www.linuxfoundation.org/programs/developer/nda Coreboot can be relevant even if it only supports obsolete silicon. Not in the firmware market it can't. Coreboot was the first to bring sub-second boot times to laptops. But that doesn't matter unless coreboot is available for the machines that are built today. Otherwise noone who is building machines today can use it. Which is what I want. There are more examples. Unfortunately no technical properties or features of coreboot matter. If coreboot does not support machines that are built today it is irrelevant. I don't want that. But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. I think Alex has his heart in the right place but I also think that it is a bit naïve to believe that coreboot would be able to do anything to allow commercial contributors to work directly upstream. This isn't up to coreboot, it isn't something coreboot can influence in any other way than by becoming more relevant in the firmware market. You're right, and it's exactly why individual community contributors are so limited in what we can do in coreboot. I don't feel limited. Do you have preview silicon access? I know I don't, and I don't believe I could ever get it. Corporate contributors are of necessity restricted -- e.g. to large commits after the product ships. I grok that. Is there a way to *reduce* the restrictions, and burdens in general, of corporate contributors? To get them to work directly upstream? There's nothing that the coreboot project can do. The restrictions may change with time, but since they don't come from coreboot there's no change coreboot can make to affect them. I hope that makes sense? Reviewers could reject patches as incomplete. Patch authors usually do not understand why patches are incomplete without mentoring. That does not scale. 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. So let's affect this. The way to do so is to for coreboot to continue to become more relevant in the firmware market. //Peter -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
David, When you go out of line with a private email, expect to find yourself on a public list. Alex On 03/23/2014 05:04 AM, David Hubbard wrote: On Sun, Mar 23, 2014 at 1:26 AM, mrnuke mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Can you guys stop fucking worrying about a fork for the time being? We'll fork if we have to, but right now, we should be focused on refactoring the development process. If we do the latter rather than the former, chances are we'll find a mutually agreeable and better process. Stop pulling out rulers and unzipping your pants. Honestly, Alex, we'll fork if we have to, and you'll be ignored. When we fork, it'll be you holding the ruler. Contributing to coreboot hasn't made us any money, any glory, and that's perfect. Coreboot for me is about not paying $100 to Microsoft to get a license to boot my OS on my computer. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
Hello! Please don't next time. Its considered to be rather rude, especially if the sender asked you to keep it off the list. I don't pretend to know what David H, was thinking, but I surmise he was indeed thinking of that. - Gregg C Levine gregg.drw...@gmail.com This signature fought the Time Wars, time and again. On Sun, Mar 23, 2014 at 1:01 PM, Alex G. mr.nuke...@gmail.com wrote: David, When you go out of line with a private email, expect to find yourself on a public list. Alex On 03/23/2014 05:04 AM, David Hubbard wrote: On Sun, Mar 23, 2014 at 1:26 AM, mrnuke mr.nuke...@gmail.com mailto:mr.nuke...@gmail.com wrote: On Sunday, March 23, 2014 07:34:32 AM Vladimir 'φ-coder/phcoder' Serbinenko wrote: On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Can you guys stop fucking worrying about a fork for the time being? We'll fork if we have to, but right now, we should be focused on refactoring the development process. If we do the latter rather than the former, chances are we'll find a mutually agreeable and better process. Stop pulling out rulers and unzipping your pants. Honestly, Alex, we'll fork if we have to, and you'll be ignored. When we fork, it'll be you holding the ruler. Contributing to coreboot hasn't made us any money, any glory, and that's perfect. Coreboot for me is about not paying $100 to Microsoft to get a license to boot my OS on my computer. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sat, Mar 22, 2014 at 11:34 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 04:10, Peter Stuge wrote: That isn't too different from creating a fork? Fork is better. With fork we don't have to deal with the same people who pushed the community out in the first place. Vladimir, these are strong words, so I'd like to repeat my question. The concern seems to be about the notion of gatekeepers. But every project I've been on has gatekeepers. We've had them on coreboot since the beginning, even as we iterated through four different code management systems. One level currently is that some people don't get +2, and the new proposal is to limit the set of committers. So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The times I've seen problems with gatekeepers have all concerned responsiveness, not the number of gatekeepers, 9front forked Plan 9 because the gatekeepers of Plan 9 commits were felt to be not sufficiently responsive. The result has not been positive, however, as the forks of Plan 9 now number at least 5, and the community has really fragmented. So, is the issue the limitation of the numbers, your view that the committers won't be responsive, or just the idea of gatekeepers? I have friends who commit to grub2, and there seem to be gatekeepers there; how do you manage that process? I think it makes more sense to drop the heat level of this conversation and work toward a mutually agreeable situation. Let's take it easy. The changes have not happened, the discussion is ongoing, and I don't see a point to taking action too quickly. Of course, the nature of the project is that you can fork any time. That's your call. But it would be a shame. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sunday, March 23, 2014 05:37:37 PM Peter Stuge wrote: David Hubbard wrote: But Peter, what's your take on Alex's suggestion: What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. I think Alex has his heart in the right place but I also think that it is a bit naïve to believe that coreboot would be able to do anything to allow commercial contributors to work directly upstream. In the current model, where every patch needs to go through our gerrit, and be met by highly experienced shed builders, no there's nothing we can really do. However, if we're going to change the model, this remains a valid point to look at. This isn't up to coreboot, it isn't something coreboot can influence in any other way than by becoming more relevant in the firmware market. Sure it can... by adopting a development model that makes sense to said commercial entity... by eliminating some of the unnecessary hurdles in upstreaming the code. I sense your comments are under the assumption that everyone uses AMD's model -- write lots of code with NDA'd docs, then scrub it clean before upstreaming. It's still up to the vendor how closely they want to work with upstream, but they ain't gonna do it if the process ain't friendly. As an upstream, we need to provide a friendly way of doing business. And yes, we can do that. Alex -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 23.03.2014 19:24, ron minnich wrote: I have friends who commit to grub2, and there seem to be gatekeepers there; how do you manage that process? In case of grub2 I admit we have exactly the problems I described. I'm open to having more maintainers but right now it doesn't seem to be feasible. I proposed co-maintaining to some skilled people but they didn't accept as of now. Here you have a chance of more people willing to help maintain coreboot. Use this resoiurce. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Sun, Mar 23, 2014 at 12:58 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 23.03.2014 19:24, ron minnich wrote: So I believe the problem is not the idea of gatekeepers, but the manner in which they are proposed to work. Can you tell me what about this upsets you? I want to understand. The problem is that the proposal is that all commits go through gatekeepers. It's bottleneck. It makes much more sense to have per-path maintainers and tiered code. E.g. we could keep all boards rather than shooting them and the ones that are considered to be too old can have less stringent requirements on commits. This will free the qualified people time to concentrate on boards where it's most important. Also it will benefit unimportant boards as well as they'll be easier to keep. Then per-path maintainer and gatekeeper are contradictory concepts. How one can be maintainer if he can't commit to his maintained code. I feel, for example, that nehalem code and resulting boards are my responsibility and I should be able to commit there easily. Getekeeprs will make this impossible as I'm more or less the only one who knows nehalem code *and* cares about it. I feel like the top-level maintainers would be only about overall structure, not about details in Board:foo/bar they've never even seen and solving disputes. Making everything go through 6 people is unfeasible as 6 people can't represent broad range of interests and some parts of code will get neglected more that they have to be of simple scarceness of resources. Without speaking for anyone or about anything else, can Stefan comment on this proposal by Vladimir? It seems relatively cool and reasonable. I publicly, sincerely apologize for my part in heating this thread up. David -- 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] 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
Re: [coreboot] Changes to the coreboot Project Structure
On Thu, Mar 20, 2014 at 9:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko phco...@gmail.com wrote: On 21.03.2014 01:39, Carl-Daniel Hailfinger wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. You cannot treat community as some kind of corporate entity. 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. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. I will be joining you on the community fork. We can call it FedoraBoot (just kidding). This Google-sponsored takeover of the coreboot leadership cannot be allowed to succeed. I appreciate all that Google has done to promote coreboot. I want them to continue. But Google and the community need to talk more about Google's code dumps, unexplained demands, and closed development. If instead Google finds it more convenient to just co-opt coreboot by Significantly reduce number of submitters then coreboot.org is no more open to committers than chromium.org. We will fork. David -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 03/20/2014 11:55 PM, Stefan Reinauer wrote: Changes to the coreboot Project Structure .. * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): Current suggestions: Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google) Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) Status: TO BE IMPLEMENTED Hi Just for quick reference, I have read this proposal previously with following comments: For now I am not declining, at least (from becoming a gatekeeper). It finally depends a lot of the final structure of this hierarchy and what goals it sets. One thing you need to add to this document is how project leaders plan to proceed with on-going and further violations of GPL copyright holders rights, as IBV/ODM/OEM chain refuses to make the distributed firmware binaries traceable to the sources they were built from. 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 2:55 PM, Stefan Reinauer stefan.reina...@coreboot.org wrote: * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes Aiming for top notch code quality, the coreboot project is generally trying to provide a solid and scalable framework for development as well as a number of generic cross-chipset components. Changes to these parts of the coreboot code affect a large number of supported systems. Hence it is important to have gatekeepers in place to guarantee they stay operational. For non-common code, I am curious if it's possible to make MAINTAINERS hierarchical, perhaps by using multiple files or adding an optional path next to the person's name in the top-level file. For example, if somebody has a particular interest in the x201, they can echo $NAME src/mainboard/lenovo/x201/MAINTAINERS or echo $NAME src/mainboard/lenovo/x201 MAINTAINERS and then have gerrit add $NAME as a reviewer to any patches that touch the subdirectory. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- 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 5:39 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Companies that get open-source development don't operate that way, thankfully. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Flashrom's problems run a lot deeper than that. Rather than regurgitate old discussion, I'll point to this thread: http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. Anybody can review a patch and give it a score. AFAICT gatekeepers are necessarily tasked with scrutinizing code, and in fact that will be impossible in many cases where documentation for a new chip isn't public. The way I read it, a committer ensures that patches meet quality/consistency guidelines, adds additional reviewers/stakeholders when appropriate, and can optionally do a more thorough review, with the intention of helping authors to navigate the review process effectively. How many times have community members sent their patches for review only to have them bitrot for days, weeks, or even months? There have been many occasions where Stefan and Ron spend a weekends hanging out in a coffee shop and just going thru stale patches on gerrit to try to reduce the backlog. I doubt the intention is to make the review process more bureaucratic or increase the backlog. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. MAINTAINERS file? Having gerrit automatically add reviewers would be tremendously helpful too. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On Fri, Mar 21, 2014 at 11:52 AM, David Hendricks dhend...@google.comwrote: On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger c-d.hailfinger.devel.2...@gmx.net wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. Companies that get open-source development don't operate that way, thankfully. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Flashrom's problems run a lot deeper than that. Rather than regurgitate old discussion, I'll point to this thread: http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. Anybody can review a patch and give it a score. AFAICT gatekeepers are necessarily tasked with scrutinizing code, s/are/are NOT and in fact that will be impossible in many cases where documentation for a new chip isn't public. The way I read it, a committer ensures that patches meet quality/consistency guidelines, adds additional reviewers/stakeholders when appropriate, and can optionally do a more thorough review, with the intention of helping authors to navigate the review process effectively. How many times have community members sent their patches for review only to have them bitrot for days, weeks, or even months? There have been many occasions where Stefan and Ron spend a weekends hanging out in a coffee shop and just going thru stale patches on gerrit to try to reduce the backlog. I doubt the intention is to make the review process more bureaucratic or increase the backlog. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. MAINTAINERS file? Having gerrit automatically add reviewers would be tremendously helpful too. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc. -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
[coreboot] Changes to the coreboot Project Structure
Changes to the coreboot Project Structure We -- the coreboot project -- have succeeded beyond our wildest expectations, with every major laptop vendor using our code. Going forward, this will require a few structural changes that will ensure that the vendors shipping coreboot products can count on a stable, reliable code base. With that incredible success, there is also a lot of work to be done to make sure the project is scaling and keeping up with the requirements of the millions of new users that coreboot gets every year. There is a large number of new corporate entities investigating their possible involvement in coreboot, and we need to make sure that their integration is working smoothly while still keeping the project’s interests and goals stable and alive. Moving forward, we need to make sure that we can welcome these possible new contributors without the friction that we have seen in the past. The coreboot community currently consists of about 80 contributors with varying levels of activity. Among these contributors, three groups can be identified as the major stakeholders in the project: Sage Electronic Engineering (the largest coreboot IBV), Secunet and Google Inc. (delivering all new Chrome OS devices with coreboot based firmware). Individuals employed by these three stakeholders make up for the majority of code contributions. According to Ohloh, roughly half of the coreboot contributions are done by the top ten contributors. Over the project life time, over 80% of those have been made by corporate contributors. While there is a fairly good understanding of the project direction and interest between those individual contributors, there are also an increasing need for making sure that the coreboot project’s scalability and its viability for mobile / consumer products and servers is guaranteed. The goal of this proposal is to enable all of the community to have a strong voice and make strong contributions to the project while allowing the major stakeholders to steer the project direction and pursue ownership of the components they provide. Traditionally the development model of coreboot was very similar to the model of the Linux kernel in many ways, including coding guidelines, the requirement of a sign-off process for contributions, and active leadership provided by a “benevolent dictator”. Commit rights were traditionally given to few of the top contributors of the project. With the introduction of git as coreboot’s version control system and its multi-branch nature as well as gerrit for code reviews, the landscape of the project has slightly shifted towards a more anocratic development model in which different interest groups sometimes worked on opposing strategies, and thus affecting the project’s overall stability and suitability for large scale deployment negatively. The advent of these new tools requires the original project founders and major stakeholders to provide stronger leadership and strategic direction for the project. Measures to improve the coreboot Development Model * Require authors to acknowledge changes made in their name (Forge-Author) This change allows contributors to decide when their OWN changes are ready for being integrated into the project, preventing unfinished and experimental work to be submitted accidentally. Status: ACTIVELY ENFORCED BY GERRIT * Define owners for (sets of) mainboards and require these to act as maintainers / gatekeepers, being the controlling instance to submit these mainboard changes. Providing support for a new mainboard / chipset / component in coreboot is a major contribution that requires the contributors to invest dozens / hundreds / thousands of man hours. In the light of this we would like to give those who provide support for one of these components stronger ownership. The submitters of a component need to have the last word about what becomes part of their component and what does not. This will also give component providers a certain freedom of the actual implementation of the component, that might, in some rare cases, be different from the implementational structure of the framework and generic code. Status: TO BE ENFORCED BY POLICY * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes Aiming for top notch code quality, the coreboot project is generally trying to provide a solid and scalable framework for development as well as a number of generic cross-chipset components. Changes to these parts of the coreboot code affect a large number of supported systems. Hence it is important to have gatekeepers in place to guarantee they stay operational. Status: TO BE ENFORCED BY POLICY * Look into making gerrit automatically add reviewers based on maintainer lists In order to streamline the code review process in a project that on average now has over 200 contributions per month, maintainers / owners
Re: [coreboot] Changes to the coreboot Project Structure
On Thursday, March 20, 2014 10:55:57 PM Stefan Reinauer wrote: Changes to the coreboot Project Structure Measures to improve the coreboot Development Model * Require authors to acknowledge changes made in their name (Forge-Author) [...] Couldn't agree more. * Define owners for (sets of) mainboards and require these to act as maintainers / gatekeepers, being the controlling instance to submit these mainboard changes. [...] * Build a MAINTAINERS file for common code, and encourage people to keep subsystem maintainers in the loop for changes [...] This is somewhat what linux does, and it works well for them. Might be a little OT/irrelevant, but why not make gerrit need a maintainer must approve before making the change submittable. * Look into making gerrit automatically add reviewers based on maintainer lists [...] Can we find something better than gerrit? I think gerrit encourages too much bikeshedding. It also encourages people to filter out gerrit emails, so that any such maintainers would not get the message. * Import previous code reviews and results The tree major stakeholders in the project all own internal code review systems, some of which are public (e.g. the Google Chrome OS repository) and have code reviews that include representatives outside of Google to ensure general code quality and making sure the improvements made for products don’t negatively impact upstreamability. For those cases it would be extremely helpful to honor the code reviews already done in the upstream repository Status: TO BE INVESTIGATED I couldn't disagree more. First of all, the idea of representatives outside of company to ensure general code quality is contrary to the idea of allowing the community to scrutinize to-be-upstreamed contributions. When you combine that with the idea of [blindly] honoring code reviews already done upstream, you have effectively eliminated the scrutiny and review from the community. I've seen mostly cases of great external reviews, but have also seen a fair share of bodged, nonsensical ones where terrible patches have been accepted without much thought. If the community has to accept code reviews done under closed doors, these contributions are effectively code dumps. I do not remember this ever being beneficial to the community, and usually results in the community needing to clean up afterwards. See linux for details. What do we need to do to allow commercial contributors to work directly upstream? And before you discount this question for menial technical reasons, please take a moment to keep this conversation open, and let's try to find an answer. Will it work for 100% of commercial contributors? No. However, this should be the preferred method for upstreaming contributions. See linux for an explanation why this works best. * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I am sorry to say this Stefan, but, in my opinion, you would not make a good benevolent dictator. Over the past years, I have found you to be extremely biased towards the needs of the commercial developers, whilst being less interested and attentive to the needs and wished of the non-commercial part of the community. I do not believe that someone biased towards one part or another of the community can make a great leader. You also, on some occasions, delayed good NC contributions in order to merge less-than-ideal commercial contributions, which later had to be cleaned up by the NC guys. You are a great person, but I believe that having you as the leader, we would have a benevolent dictator for the commercial contributors, where the non- commercial ones would see have a mere dictator. On the other hand, I have found Ron Minnich to be very unbiased and equally receptive to ideas from both sides of the community. While I am certain some people might come to point out mistakes Ron had done in the past, unlike you, I did not find a pattern of bias in them. I think Ron is the best candidate for the role of President and Benevolent Dictator of Coreboot. Current suggestions: Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google) It has been this way for years, so to speak. I also find you to be a much better candidate as the representative/maintainer for Google contributions. I think you can do much more good
Re: [coreboot] Changes to the coreboot Project Structure
ah, blush, somebody wants me to be dictator. However, I can't do it. First off, if you're not going to let me invade some country, it's no fun. Secondly, it's hard to find Dictator clothes that look good on me. Just won't work. Thirdly, Stefan has been doing this very well for at least 7 years, and he even held coreboot together in the Dark Days when all seemed lost. Just my $.02 here: Google saved coreboot. We lost our biggest industrial sponsor when LNXI folded, and it was a real problem keeping it going. And without a commercial entity, and its mass, we're nowhere. Want to know why Intel is hiring coreboot people? Go look at the Amazon stats on laptops. There's your answer. So I have a very natural fondness for the commercial sector. LNXI kept us on the map for a while, and now Google does. And, in fact, Google put coreboot over the top, which was quite a gamble on Google's part and entirely due to the vision of the ChromeOS team. But don't worry, I'm going to continue my role as Aging Curmudgeon, so I will be ever-present and ever-annoying as always. But, seriously, I do appreciate the kind words. ron -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. AFAICS the reason to reduce the number of coreboot committers is to have gatekeepers who actually enforce guidelines by looking at patches before they commit them. That essentially introduces an additional review step. While such a step may be desirable, it would have to be made clear whose obligation it is to carry out commit+review step for new contributors, and how any fallback/failover mechanisms are implemented. If we really go ahead with a fixed number of committers, each person should have a substitute who can take over. That would be a total committer number of twelve. Current suggestions: Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google) The corporate committer suggestions seem to make sense. Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community) To be honest, regardless of who will be the community gatekeepers, some people are going to be disappointed. There would have to be a metric for determining community committers. Is the amount of code written a useful metric? Should we instead look for the amount of code reviewed/committed? Lines of code or commits? How far back should we go? Lines of code written during the last three years maybe? Or we simply allow all active (any nontrivial code submission in the last 3 years) community developers to nominate one community committer and pick those with the highest number of votes. Status: TO BE IMPLEMENTED I would welcome further discussion. Regards, Carl-Daniel -- http://www.hailfinger.org/ -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Changes to the coreboot Project Structure
On 21.03.2014 01:39, Carl-Daniel Hailfinger wrote: Hi Stefan, streamlining development and maintenance is definitely absoutely worthwhile. Getting rid of unmaintained code is also a good thing. The guidelines presented in your mail look mostly good IMHO, but I'd like to comment on a few things. Am 20.03.2014 22:55 schrieb Stefan Reinauer: * Significantly reduce number of submitters 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. The suggested structure will need to value both community interests and corporate interests equally and hence a good setup would be to have a final amount of six developers with submit rights, three community representatives and three corporate representatives (on from each major stakeholder): I see a huge bottleneck in restricting the number of committers to six. - Corporate committers will be primarily obliged to get the stuff of their own employer committed, but if they are ill or on vacation, someone else would have to take over. This would either be another corporate committer (in which case their own employer would have to authorize spending time for a different company) or a community committer. - Community committers are not paid, and commit in their spare time. Spare time is not necessarily abundant all year round. Speaking from experience, the flashrom project has no shortage in developers or submitted patches, but a real and painful shortage in reviewers/committers. The flashrom project patch backlog is huge due to this. Doing a commit is easy, but making sure that a commit follows certain guidelines is a huge time sink with none of the fun of writing code. - New contributors (corporate or community) would have to find a sponsor to actually commit their code. With a large committer base, this can happen rather quickly. With only six committers facing their own deadlines or other shortages of time, this could take quite a while. The proposition of gatekeepers would essentially kill community effort. Even in current infrastructure reviewing is a major slowdown. With small number of gatekeepers there wouldn't be any significant contributions as the gatekeepers wouldn't be able to review them in reasonable time, which will, in turn discourage contributions. You may as well just stop accepting community contributions right now: it turns out to be the same thing, just a little bit quicker. You cannot treat community as some kind of corporate entity. 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. You can't realistically put such burden on few people. If you want a corporate version of coreboot, I think you have to use a workflow similar to Fedora vs Red Hat Enterprise Linux. The changes you proposed would effectively make coreboot into corporate project. I'd expect a community fork to emerge quickly, outside of this new limiting infrastructure and I'll be surely moving to community fork. signature.asc Description: OpenPGP digital signature -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot
