On Fri, Mar 21, 2014 at 11:52 AM, David Hendricks <[email protected]>wrote:
> > > > On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger < > [email protected]> wrote: > >> 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. >> > > Companies that "get" open-source development don't operate that way, > thankfully. > > >> - 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. > > > Flashrom's problems run a lot deeper than that. Rather than regurgitate > old discussion, I'll point to this thread: > http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html > > >> 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. >> > > Anybody can review a patch and give it a score. AFAICT gatekeepers are > necessarily tasked with scrutinizing code, > s/are/are NOT > and in fact that will be impossible in many cases where documentation for > a new chip isn't public. The way I read it, a committer ensures that > patches meet quality/consistency guidelines, adds additional > reviewers/stakeholders when appropriate, and can optionally do a more > thorough review, with the intention of helping authors to navigate the > review process effectively. > > How many times have community members sent their patches for review only > to have them bitrot for days, weeks, or even months? There have been many > occasions where Stefan and Ron spend a weekends hanging out in a coffee > shop and just going thru stale patches on gerrit to try to reduce the > backlog. I doubt the intention is to make the review process more > bureaucratic or increase the backlog. > > 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. >> > > MAINTAINERS file? > > Having gerrit automatically add reviewers would be tremendously helpful > too. > > -- > David Hendricks (dhendrix) > Systems Software Engineer, Google Inc. > -- David Hendricks (dhendrix) Systems Software Engineer, Google Inc.
-- coreboot mailing list: [email protected] http://www.coreboot.org/mailman/listinfo/coreboot
