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