<div dir="ltr">On Sat, Mar 22, 2014 at 9:10 PM, Peter Stuge <span dir="ltr"><<a href="mailto:peter@stuge.se" target="_blank">peter@stuge.se</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">


<div>Vladimir 'ö-coder/phcoder' Serbinenko wrote:<br>
> The proposition of gatekeepers would essentially kill community effort.<br>
<br>
</div>That might not be a bad thing.<br>
<br>
Unfortunately, considering how the hardware industry works, individual<br>
contributors in the community can't work on code for current hardware.<br>
<br>
coreboot is only relevant once it supports the hardware that is being<br>
designed in. After design is done the window is closed; a firmware<br>
has been chosen, and coreboot wasn't on the table.<br>
<br>
By current hardware I don't mean what is shipping or what is being<br>
implemented in coreboot. Current hardware is what is being designed<br>
by silicon vendors. The time between design and shipping products is<br>
on the order of several years and the longer it takes for coreboot to<br>
run on that silicon the less relevant coreboot is.<br>
<br>
By the time individual contributors can make significant contributions<br>
for a particular silicon that silicon is long obsolete, so those efforts<br>
will only tend to support coreboot as a pointless niche project.<br>
<br>
That's not why I contribute to coreboot.<br></blockquote><div><br></div><div>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: <a href="http://www.linuxfoundation.org/programs/developer/nda" target="_blank">http://www.linuxfoundation.org/programs/developer/nda</a><br>


<br></div>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.<br><br></div><div class="gmail_quote">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."</div><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>> You cannot treat community as some kind of corporate entity.<br>
<br>
</div>You're right, and it's exactly why individual community contributors<br>
are so limited in what we can do in coreboot.<br></blockquote><div><br></div>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?<br>


</div><div class="gmail_quote"> <br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> You can't realistically put such burden on few people.<br>


<div>
<br>
</div>As I understand the proposal, the kind of work that gatekeepers would<br>
do would be drastically different from the kind of work that reviewers<br>
must currently do.<br>
<br>
The burden for reviewers is currently very high because so many<br>
changes are not finished when they are proposed for review.<br>
<br>
Compare with Linux, where contributors more frequently than not send<br>
perfect patches which are very quick to review.<br></blockquote><div><br></div><div>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.<br>


 <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The changes you proposed would effectively make coreboot into<br><div>
> corporate project.<br>
<br>
</div>It already is and as Ron described it actually always was. It's not<br>
possible to make significant contributions for current hardware as an<br>
individual contributor. I think coreboot may have an opportunity to<br>
affect this, but certainly not by using brute contributor force.<br></blockquote><div><br></div><div>So let's affect this.<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">



<div>> I'd expect a community fork to emerge quickly, outside of this new<br>
> limiting infrastructure and I'll be surely moving to community fork.<br>
<br>
</div>Try to mentally balance the commit graph a bit differently.<br>
<br>
I think part of the proposal was essentially to have a community branch?<br>
<br>
That isn't too different from creating a fork?<br></blockquote><div><br></div><div>I don't see anywhere in Stefan's *only* email on this subject that he suggested a community branch. Branches were Alex's idea: <a href="http://www.coreboot.org/pipermail/coreboot/2014-March/077660.html">http://www.coreboot.org/pipermail/coreboot/2014-March/077660.html</a><br>
<br>Stefan appears to be missing in action.<br>

<br></div><div>David<br></div></div></div></div>