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
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 to coreboot in this position.
Alex
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
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.me@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 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".
I have functioned as the BD of this project for the last 7 years now, and it has worked just fine in my opinion - and I think many others share this opinion. In fact it seems I was so benevolent that you didn't even notice the fact. ;-)
Those who have been with the project for a long time know that I am not the corporate shill you describe me as in your mails. Among many other things I have paid for the infrastructure running the coreboot project out of my private pocket since 2004, despite many offers from corporate entities to throw the few bucks over the fence. Why? Because coreboot as a project needs to be independent.
I have also worked on Open Source firmware ever since I started OpenBIOS in '97. Mind you, at that time Google didn't even exist.
If you like, we can share more thoughts and expiriences on that.
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 to coreboot in this position.
Thank you for your kind words. It's appreciated. I'm fine with having more than a single role, always have been since I joined the project more then a decade ago.
All the best,
Stefan
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
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.
On Thu, Mar 20, 2014 at 9:31 PM, Vladimir 'φ-coder/phcoder' Serbinenko < phcoder@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
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
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.
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
On Sat, Mar 22, 2014 at 11:34 PM, Vladimir 'φ-coder/phcoder' Serbinenko phcoder@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
On Sat, Mar 22, 2014 at 9:10 PM, Peter Stuge peter@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
* Vladimir 'φ-coder/phcoder' Serbinenko phcoder@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
On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger < c-d.hailfinger.devel.2006@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.
Hi Carl-Daniel,
thank you for your feedback!
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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
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
On Thu, Mar 20, 2014 at 2:55 PM, Stefan Reinauer < stefan.reinauer@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.
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
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.
Status: ACTIVELY ENFORCED BY GERRIT
In my opinion, this change was made due to one incident, which would not have been happened afterward as people were aware of this problem. But it is how it is.
- 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.
Where has this been a problem in the past? Please give specific examples.
Why is it necessary to divert? If it is needed and has advantages people won’t oppose anyhow even currently. But there have to be reason for diverting from the implementational structure of the framework and generic code. Otherwise the question is if this is only be happening in rare cases or going to be the norm.
(Also the maintainers/gatekeepers should (of course) have to adhere to current policies.)
How is that going to change anything anyhow? Do you believe the title is going to make the community developers spent more time on coreboot. My impression currently is they spent as much of their free time with coreboot already.
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.
I claim it is currently done the exact same way without having/needing a MAINTAINERS file.
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
That sounds good. But I had the feeling people know which people to add as reviewers.
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
As Kyösti pointed out, there is unfortunately the need to do the extra review, as it is apparent that for example the Google patches are mostly (of course) only developed and tested with their boards so it has to be made sure they do not decrease the overall quality, do not affect other boards/components and do not increase the maintenance burden for the community. Currently it is the way, that Google only upstreams after the code already ships and then goes on with the next product, while not maintaining the old boards anymore.
- 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 also do not see, why this is necessary and the current state has to be changed. Ron stated in the past that this is due to commits being pushed breaking things. But that was not the case in the last two or three years. And if it was, it were experienced submitters breaking the tree, which of course is more likely to happen when you do more reviews/write more code.
As Kyösti already asked, please provide the commit hashes of the commits that broke the tree and making you come up with the proposal.
Regarding the dictator, in my opinion the “dictator” main job is communication and not writing code as Linus Torvalds is doing it for Linux for example. In that regard, you were pretty silent (at least on the list, which is the medium for communication) especially since you stared working for Google. Ron is a little more active on the list, but also a little biased towards your employer, which is to be expected.
I guess the position for the dictator is not up for a vote, as you own the infrastructure anyhow I guess.
Patrick is very active in the IRC channel #coreboot (on <irc.freenode.net>) and a coreboot veteran.
In the end I did not miss a dictator the last three years and thought that a solution could always be found.
Current suggestions:
Patrick Georgi (Secunet) Marc Jones (Sage) Stefan Reinauer (Google)
In my opinion, Aaron Durban did a great job in the past year(?) keeping in touch with the community and addressing the concerns.
Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the coreboot community)
The community has very capable people for this kind of job in my opinion. Vladimir and Alexandru come to mind.
Status: TO BE IMPLEMENTED
I agree with others that the problems should be elaborated more and then solutions for them have to be thought of. From the current messages it is not clear what lead to the proposals. If the analysis of the problems is incorrect the solutions/proposals probably won’t solve the real problems or improve the situation.
So to summarize, in my opinion, there are the issues of upstreaming patches from Google which costs Google and the community a lot of time, money and developer’s nerves and missing communication/interaction between the community and companies. Other than that my impression is that the current process works fine.
For example it was never announced when Google added new tags to commit messages. It is a problem for community developers to look at changes in the Chrome OS repository and it is wasting their time to jump between different Web sites.
Maybe the infrastructure can be adapted too and also more automatic tests (tests of more Kconfig options) and checks be implemented. This would give developers more time on reviewing the actual code than looking at the trivial policy violations.
It should also be though of making some of the internal Google policies an upstream policy too like having to put that TEST tag in there.
Some solutions would be for Google (and Sage, AMD) (and probably cheaper than the spent developer time) to give out devices for free to developers so that these are maintained and tested even when the company went on to the next device. (See the board-status repository how many Google devices have been tested although Ron pushed for that board-status repository.)
Thanks,
Paul
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.
[…]
While there is a fairly good understanding of the project direction and interest between those individual contributors, […]
reading these lines I realized I do not have that understanding and I am not so certain anymore about the expectations, coreboot’s directions and the interest.
First I find “wildest expectations” a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult.
Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered.
I suspect that in the beginning of coreboot even Ron and you would not have expected anything like this to happen and not considered that such an image meets your expectations.
So I congratulate that coreboot is used by several vendors and has millions of users, but it is to be taken with a grain of salt. It is also clear, that you do not like this situation either, but it would be interesting what the expectation and direction should be.
Clearly, getting a system to boot is not the main goal as everybody can do that with the vendor BIOS/UEFI, which, by the way, lately greatly improved boot time too in my experience.
For Google and the laptop vendors, I guess the goal is simply to save the money per device that traditionally went to the BIOS/UEFI vendors. Of course the payload concept gives a lot of flexibility, which is nice too. But in the end it seems to come down to saving money and hoping to make more profit. I do not know, if that worked and works out and how much more time it costs to deal with the community and reviews compared to the interaction with the BIOS/UEFI vendors and paying the fee/tax or with the time to deal with Intel’s management engine.
The other sad development seems to be that AMD, until now being the company most supportive of coreboot by contributing code and employing developers – unfortunately only in the embedded section – working on coreboot, even *thinks* about only providing binary blobs of AGESA instead of (IP scrubbed) sources for AGESA. Unfortunately they do not seem to get the advantages of free software and understand free software in their AGESA department and although being of much smaller size than Intel, they seem already big enough to not being able to change or only being able to change slowly.
And the possible move to blobs is also kind of understandable, as despite being such a first class citizen, seeing that Intel (i945) gets chosen by the German government and Google chooses Intel for their Chromebooks and ships images with blobs. As Intel is bigger, Google probably hired more people from Intel than from AMD. Maybe the Google decision makers know the Intel decision makers and play Golf with each other. Anyway, it is another datapoint that it is not about free software at all.
So one could even say, that coreboot’s decision to allow binary blobs as the Management Engine and RAM init (MRC) even supported AMD’s current *plans* to go back to binary blobs as it is currently allowed for Intel. So it is questionable if the past decisions served the project well. I have no clue what would have been better and if this could have been avoided at all. Nobody can look into the future. So we have to take it as it is now, but it is clear that the opponents back then had valid points and that such decisions can have negative long term side effects.
It should also not be forgotten that thanks to the leaks from Edward Snowden, the current political and economic(?) situation is as good as never before for free software and coreboot. In the Internet business, companies in the USA already feel the consequences and loose contracts and money when their datacenters/servers are located in the USA.
The same will hopefully happen to hardware vendors shipping proprietary BIOS/UEFI firmware. AMD is currently the only feasible (x86) vendor and hopefully policies are going to be implemented only allowing government agencies to by AMD stuff with free firmware. (No idea how much the IT personal is educated and who is in charge for these decisions and if one can sue/request such policies, like the tax agency has to use AMD hardware with coreboot to adhere to privacy concerns.)
So there is hope and a chance for coreboot to get rid of these blobs once and for all.
So what are the expectations for the next years? What directions should coreboot go? I am interested in your views. Especially from the benevolent dictator and other old term contributors.
In my opinion, we should get the first AMD laptop supported as soon as possible as currently only Intel laptops are supported, so there is an option on the market government, people and companies can buy if they are interested. In the IRC channel #coreboot on <irc.freenode.net> [2] such things are discussed already and there might be even volunteers. This should be discussed in a separate thread though.
Thanks,
Paul
[1] http://www.coreboot.org/Binary_situation [2] http://www.coreboot.org/IRC
I keep wanting to drop out of this discussion but there are some things I just can't let go by,
On Mon, Mar 24, 2014 at 4:20 PM, Paul Menzel < paulepanter@users.sourceforge.net> wrote:
First I find "wildest expectations" a little exaggerated seeing the blobs (especially ME) shipped in all current Intel devices [1]. It is even worse that these blobs are not allowed to be distributed making building and flashing an image more difficult.
You're misunderstanding the blob situation completely, not surprising as it is so complex.
In The Beginning, we were blob free. Things changed. Now there are blobs. We got our first blobs in 2001 or so so we could do graphics. We did not have the money to do it any other way.
We don't like it. But if the choice is to ship on nothing, or ship with blobs, we'll ship with blobs. The X60 ports ship with blobs too, if you look at the big picture, because we still don't have EC source on those boxes. The OLPC shipped with blobs. This is not a simple problem.
Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered.
Dude, the commit is IN THE IMAGE. At least on the images I work with. As in: ro bios version | Google_Link.2695.1.133
from chrome:system on my link. I also just checked my falco and the hash is right there too from cbmem -c. I don't build all platforms; have you found some where this is not the case? Might you consider fixing it?
I'm going to call BS on this "not GPL" claim until you get a clear statement from the FSF that it is the case. I don't see the point of dropping FUD into this discussion. Make your case.
Of course, we have FSF people on this list and if they want to comment on this issue they are most welcome. That said, I've also been talking to those guys (including RMS) for 15 years and they've never hinted to me we're doing something wrong. I realize there are some armchair lawyers on this list who have their own interpretation, but I think I'll use the FSF as my authority in this case.
Clearly, getting a system to boot is not the main goal as everybody can
do that with the vendor BIOS/UEFI, which, by the way, lately greatly improved boot time too in my experience.
Gee, I get to call BS again. I have been telling people for 15 years that boot time is a nice side effect of using coreboot, and while it's key to many users and uses, it was not the primary or in many cases even a secondary goal. Getting control of your platform is one goal. Building custom systems (such as cluster nodes in my case) from generic hardware by changing the BIOS is another goal. There are lots of goals.
But if you're happy with UEFI you're more than welcome to use it.
For Google and the laptop vendors, I guess the goal is simply to save
the money per device that traditionally went to the BIOS/UEFI vendors.
You should not impute motive where you have no knowledge and I can tell you that in this case you have no knowledge. So let's move on.
The AMD situation, to which you refer, is again one in which you have little or no knowledge, so there's little point in speculation.
As Intel is bigger, Google
probably hired more people from Intel than from AMD.
And still more unfounded speculation. No offense intended, but you have no idea what you're talking about.
Maybe the Google decision makers know the Intel decision makers and play Golf with each other. Anyway, it is another datapoint that it is not about free software at all.
and more ...
and we get the NSA now ...
In my opinion, we should get the first AMD laptop supported as soon as possible
yes, well, I've been asking for help on this for some time, years in fact, but I can't do it all myself. It's part of my huge disappointment that our volunteers chose to put their time into (quite obsolete, no longer manufactured) X and T thinkpads instead of something modern and open. You can fault Google for their decision to go with Intel; but the volunteers have not done a lot better, in fact worse in my view. Frankly, it's a disappointment.
One option here is to focus less on the things you currently put your time on, and focus more on getting that AMD laptop working, eh? Because it's easy to talk about what we should do. It's better to start DOING IT. And getting that AMD laptop going is a lot more important than fixing spelling errors in AGESA.
But, Paul, stick with what you know and drop the speculation. Much of what you say is wrong or unfounded and it doesn't help this important discussion.
ron
* Paul Menzel paulepanter@users.sourceforge.net [140325 00:20]:
Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered.
Paul, I am not in the position to make any legal statement, nor do I want to.
As a word of advice, you should stop spreading this FUD and allegations when you refuse to do any research on the topic yourself.
All firmware builds are coming from open source and completely transparent firmware branches living in the chromium repositories.
You can access all of our code revies on the chromium gerrit, and community members can (and do, frequently) participate there.
Stefan
On Mon, Mar 24, 2014 at 5:46 PM, Stefan Reinauer < stefan.reinauer@coreboot.org> wrote:
- Paul Menzel paulepanter@users.sourceforge.net [140325 00:20]:
Additionally I heard claims, that the GPLv2 license is violated as it is currently impossible to rebuild the exact same image that is shipped with the devices as it is not even clear what commit was used to build the image and to my knowledge the requests on the list and in the IRC channel were not answered.
Paul, I am not in the position to make any legal statement, nor do I want to.
As a word of advice, you should stop spreading this FUD and allegations when you refuse to do any research on the topic yourself.
Also, throwing around such accusations is a great way to shut discussion. You have effectively Godwin'd your own thread.
As Ron said, if you have a legitimate concern please feel free to reach out to organizations such as the FSF. Spreading FUD on a mailing list like you have done is far more damaging to coreboot than anything you have accused others of doing.
-
Carl-Daniel Hailfinger -
David Hendricks -
David Hendricks -
David Hubbard -
Kevin O'Connor -
Kyösti Mälkki -
mrnuke -
Paul Menzel -
Peter Stuge -
ron minnich -
Stefan Reinauer -
Vladimir 'φ-coder/phcoder' Serbinenko