March 2014 - coreboot - mail.coreboot.org

Re: [coreboot] Changes to the coreboot Project Structure
by Stefan Reinauer March 25, 2014

March 25, 2014

* David Hubbard <david.c.hubbard+coreboot(a)gmail.com> [140323 20:33]: > On Sun, Mar 23, 2014 at 12:58 PM, Vladimir ' -coder/phcoder' Serbinenko < > phcoder(a)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

3 2

[announce] coreboot for the 21st century
by Stefan Reinauer March 25, 2014

March 25, 2014

coreboot for the 21st century setting up the project for the next decade Purpose: Purge all boards / chipsets / cpus that require ROMCC in romstage and known broken chipsets (sc520, i855) coreboot is now officially 15 years old. One and a half long decades with ups and downs. During this time we collected over 250 different mainboards. A great achievement, but also a great maintenance burden. * It is hard to keep 250+ mainboards working. Actually impossible. * Keeping them working comes at a cost. Keep old infrastructure around. Workarounds, special cases * We don’t test except on the very last stuff we’re working on To fix this issue, we suggest to establish a process to obsolete old hardware in a controlled way. Getting rid of old baggage is great and liberating for future products, but it is also one of the moves the strictly hobbyist community considers corporate driven. Hence, we want to satisfy both a speedy light-weight development process and keeping all the good coreboot legacy alive. For the first time in 2014, and every few years after that (e.g. every two years), we will create a new “community branch” that focusses on older mainboards. This branch will start out as an exact copy of ToT coreboot. Suggested name: “coreboot-community-2014” or “coreboot-v4.0”. Then this branch will not get any further new feature development (of features not available in ToT) but only bug fixes for boards to get them working and potentially backports. After the branch is created, all obsoleted mainboards are removed from the main repository. The version will be coreboot 4.1. Cleanup shall begin to remove all the cruft that we had around to get those old boards working. Each mainboard in v4.1 will have a supporter / owner. New mainboards are not admitted into V4.1 without a supporter / owner. If somebody in the community wants to keep a board / chipset alive in the tree, they can re-import them by cleaning up the board to work with the new, cruft free infrastructure. In 2016 we will do the same thing again, and it will become coreboot 6.0 Appendix A: romcc boards to be removed advantech/pcm-5820 asi/mb_5blgp asi/mb_5blmp axus/tc320 bcom/winnet100 bifferos/bifferboard digitallogic/msm586seg dmp/vortex86ex eaglelion/5bcm iei/juki-511p iei/nova4899r intel/jarrell intel/truxton intel/xe7501devkit supermicro/x6dai_g supermicro/x6dhe_g2 supermicro/x6dhe_g supermicro/x6dhr_ig2 supermicro/x6dhr_ig technologic/ts5300 televideo/tc7020 via/epia via/epia-m via/epia-n

10 14

Changes to the coreboot Project Structure
by Stefan Reinauer March 25, 2014

March 25, 2014

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 / gatekeepers should be added to the list of code reviewers automatically. Status: TO BE INVESTIGATED * 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 * 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

12 22

Re: [coreboot] Changes to the coreboot Project Structure
by Stefan Reinauer March 25, 2014

March 25, 2014

* David Hubbard <david.c.hubbard+coreboot(a)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

1 0

Re: [coreboot] GSoC-2014 Coreboot project
by Stefan Tauner March 24, 2014

March 24, 2014

On Fri, 21 Mar 2014 23:23:51 +0800 Allen Yan <lexkde(a)gmail.com> wrote: > Hi, everyone, > I've sent a preliminary proposal about "Tianocore as coreboot payload". > https://www.google-melange.com/gsoc/proposal/review/student/google/gsoc2014… > I'd like to get more feedback about the goal and the test environment. Does not seem to be public. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner

2 1

Re: [coreboot] Changes to the coreboot Project Structure
by Vladimir 'φ-coder/phcoder' Serbinenko March 23, 2014

March 23, 2014

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.

2 1

Re: [coreboot] Changes to the coreboot Project Structure
by Vladimir 'φ-coder/phcoder' Serbinenko March 23, 2014

March 23, 2014

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.

1 0

Re: [coreboot] Changes to the coreboot Project Structure
by Peter Stuge March 23, 2014

March 23, 2014

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

2 1

Re: [coreboot] Changes to the coreboot Project Structure
by Alex G. March 23, 2014

March 23, 2014

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.me(a)gmail.com > <mailto:mr.nuke.me@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

2 1

Re: [coreboot] Changes to the coreboot Project Structure
by Stefan Tauner March 23, 2014

March 23, 2014

On Sun, 23 Mar 2014 03:56:35 -0600 David Hubbard <david.c.hubbard+coreboot(a)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

1 0