Vladimir 'ö-coder/phcoder' Serbinenko wrote:That might not be a bad thing.
> The proposition of gatekeepers would essentially kill community effort.
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.
> 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.
> 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.
> 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 newTry to mentally balance the commit graph a bit differently.
> limiting infrastructure and I'll be surely moving to community fork.
I think part of the proposal was essentially to have a community branch?
That isn't too different from creating a fork?