On Sat, Mar 22, 2014 at 9:10 PM, Peter Stuge <pe...@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
-- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot