Hi Carl-Daniel,
thank you for your feedback!
* Carl-Daniel Hailfinger c-d.hailfinger.devel.2006@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