[coreboot] Changes to the coreboot Project Structure

[Stefan Reinauer]

Hi Carl-Daniel,

thank you for your feedback!

* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2006 at gmx.net> [140321 01:39]:
> 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.

Those six people would not be required to take the full burden of code
reviews. Nothing will change w.r.t that, because that would indeed
create a huge bottleneck. This is just about the actual push. Any of the
six can push any patch (given that the maintainers and/or authors have
reviewed)

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

That is absolutely understood. However, I truly believe it is important
to have community committers in place, even if it is a huge effort. Look
at the subsystem maintainers of the Linux kernel, they don't have to
review every single patch but often trust their peers in the community.

I think that is a good model.

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

The problem with flashrom is that in the last six months is has been a
one man show (or two men, but only stefanct actually committed stuff).

You guys are also worried to brick a system, whereas in the coreboot
environment we know that we brick systems.

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

This is not unlike the Linux kernel community. 

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

Let's keep this simple for now. As always, we will adjust our
implementation bit by bit to the problems we'll actually hit.

> 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.
 
I was thinking that these six would be substitutes for each other. With
12 people we would have more active committers than we have now.

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

It should be people that are best suited to act in the interest of the
complete project. I don't think simple metrics like lines of code or
numbers of reviews is sufficient for making a good decision here.

Stefan