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