[coreboot] Changes to the coreboot Project Structure

Peter Stuge peter at stuge.se
Sun Mar 23 17:37:37 CET 2014


David Hubbard wrote:
> > Unfortunately, considering how the hardware industry works, individual
> > contributors in the community can't work on code for current hardware.
> 
> 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.

Not in the firmware market it can't.


> Coreboot was the first to bring sub-second boot times to laptops.

But that doesn't matter unless coreboot is available for the machines
that are built today. Otherwise noone who is building machines today
can use it. Which is what I want.


> There are more examples.

Unfortunately no technical properties or features of coreboot matter.
If coreboot does not support machines that are built today it is irrelevant.
I don't want that.


> 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."

I think Alex has his heart in the right place but I also think that
it is a bit naïve to believe that coreboot would be able to do
anything to allow commercial contributors to work directly upstream.

This isn't up to coreboot, it isn't something coreboot can influence
in any other way than by becoming more relevant in the firmware market.


> > 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.

Do you have preview silicon access? I know I don't, and I don't
believe I could ever get it.


> 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?

There's nothing that the coreboot project can do. The restrictions
may change with time, but since they don't come from coreboot there's
no change coreboot can make to affect them. I hope that makes sense?


> Reviewers could reject patches as incomplete.

Patch authors usually do not understand why patches are incomplete
without mentoring. That does not scale.


> > 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.

The way to do so is to for coreboot to continue to become more
relevant in the firmware market.


//Peter



More information about the coreboot mailing list