[coreboot] Changes to the coreboot Project Structure

[Carl-Daniel Hailfinger]

Hi Stefan,

streamlining development and maintenance is definitely absoutely
worthwhile. Getting rid of unmaintained code is also a good thing. The
guidelines presented in your mail look mostly good IMHO, but I'd like to
comment on a few things.

Am 20.03.2014 22:55 schrieb Stefan Reinauer:
> * Significantly reduce number of submitters
>   To ensure consistency, scalability and conformity with the general
>   coreboot strategy, we need to define a clear committer structure that
>   defines the original project structure of having a benevolent dictator
>   aka project leader (Stefan Reinauer) and gatekeepers in place. The
>   suggested structure will need to value both community interests and
>   corporate interests equally and hence a good setup would be to have a
>   final amount of six developers with submit rights, three community
>   representatives and three corporate representatives (on from each major
>   stakeholder):

I see a huge bottleneck in restricting the number of committers to six.
- Corporate committers will be primarily obliged to get the stuff of
their own employer committed, but if they are ill or on vacation,
someone else would have to take over. This would either be another
corporate committer (in which case their own employer would have to
authorize spending time for a different company) or a community committer.
- Community committers are not paid, and commit in their spare time.
Spare time is not necessarily abundant all year round. Speaking from
experience, the flashrom project has no shortage in developers or
submitted patches, but a real and painful shortage in
reviewers/committers. The flashrom project patch backlog is huge due to
this. Doing a commit is easy, but making sure that a commit follows
certain guidelines is a huge time sink with none of the fun of writing code.
- New contributors (corporate or community) would have to find a
"sponsor" to actually commit their code. With a large committer base,
this can happen rather quickly. With only six committers facing their
own deadlines or other shortages of time, this could take quite a while.

AFAICS the reason to reduce the number of coreboot committers is to have
gatekeepers who actually enforce guidelines by looking at patches before
they commit them. That essentially introduces an additional review step.
While such a step may be desirable, it would have to be made clear whose
obligation it is to carry out commit+review step for new contributors,
and how any fallback/failover mechanisms are implemented.

If we really go ahead with a fixed number of committers, each person
should have a substitute who can take over. That would be a total
committer number of twelve.


>   Current suggestions:
>
>   Patrick Georgi (Secunet)
>   Marc Jones (Sage)
>   Stefan Reinauer (Google)

The corporate committer suggestions seem to make sense.


>   Peter Stuge, Kyösti Mälkki, N.N. (non-commercial part of the
>   coreboot community)

To be honest, regardless of who will be the community gatekeepers, some
people are going to be disappointed. There would have to be a metric for
determining community committers. Is the amount of code written a useful
metric? Should we instead look for the amount of code
reviewed/committed? Lines of code or commits? How far back should we go?
Lines of code written during the last three years maybe?
Or we simply allow all active (any nontrivial code submission in the
last 3 years) community developers to nominate one community committer
and pick those with the highest number of votes.


>   Status: TO BE IMPLEMENTED

I would welcome further discussion.


Regards,
Carl-Daniel

-- 
http://www.hailfinger.org/