Hi Carl-Daniel, thank you for your feedback!
* Carl-Daniel Hailfinger <c-d.hailfinger.devel.2...@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 -- coreboot mailing list: coreboot@coreboot.org http://www.coreboot.org/mailman/listinfo/coreboot