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