[coreboot] Changes to the coreboot Project Structure

[Peter Stuge]

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.


> Even in current infrastructure reviewing is a major slowdown.

As it should be. The purpose of peer review is to increase quality of
the codebase by having one or more peers review changes. Of course
that will take time.

The more complex a project is, the less development will be about
writing code. Writing code is just typing.

The hard work happens before, trying to create a design the
implementation of which will actually solve the problem, and after,
trying to find out whether the implementation actually *does* solve
the problem as intended and without introducing unforeseen issues.

A high rate of change means that all time is spent on writing code
and no time is spent either on thinking about the problem beforehand
or on analyzing results after the fact. That will decrease quality.

The discussion about slow or fast is distinct from the one about if
and how commercial and community can work together. Both are
important and I think now is a good time to have them.


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


> >>   Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the
> >>   coreboot community)
> Sounds like a joke. While Peter is competent, he's also very busy. I'd
> expect his review thoughtput of perhaps a patch a week.

I think your estimate may even be on the optimistic side.


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


> If you want a corporate version of coreboot, I think you have to
> use a workflow similar to Fedora vs Red Hat Enterprise Linux.

I would find it highly undesirable for coreboot to be anything like
Fedora. My experience with Fedora leaves quite some things to be desired.


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


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


//Peter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140323/6f64e1a2/attachment.sig>