<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger <span dir="ltr"><<a href="mailto:c-d.hailfinger.devel.2006@gmx.net" target="_blank">c-d.hailfinger.devel.2006@gmx.net</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Stefan,<br>
<br>
streamlining development and maintenance is definitely absoutely<br>
worthwhile. Getting rid of unmaintained code is also a good thing. The<br>
guidelines presented in your mail look mostly good IMHO, but I'd like to<br>
comment on a few things.<br>
<br>
Am 20.03.2014 22:55 schrieb Stefan Reinauer:<br>
<div class="">> * Significantly reduce number of submitters<br>
>   To ensure consistency, scalability and conformity with the general<br>
>   coreboot strategy, we need to define a clear committer structure that<br>
>   defines the original project structure of having a benevolent dictator<br>
>   aka project leader (Stefan Reinauer) and gatekeepers in place. The<br>
>   suggested structure will need to value both community interests and<br>
>   corporate interests equally and hence a good setup would be to have a<br>
>   final amount of six developers with submit rights, three community<br>
>   representatives and three corporate representatives (on from each major<br>
>   stakeholder):<br>
<br>
</div>I see a huge bottleneck in restricting the number of committers to six.<br>
- Corporate committers will be primarily obliged to get the stuff of<br>
their own employer committed, but if they are ill or on vacation,<br>
someone else would have to take over. This would either be another<br>
corporate committer (in which case their own employer would have to<br>
authorize spending time for a different company) or a community committer.<br></blockquote><div><br></div><div>Companies that "get" open-source development don't operate that way, thankfully.</div><div> </div>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
- Community committers are not paid, and commit in their spare time.<br>
Spare time is not necessarily abundant all year round. Speaking from<br>
experience, the flashrom project has no shortage in developers or<br>
submitted patches, but a real and painful shortage in<br>
reviewers/committers. The flashrom project patch backlog is huge due to<br>
this.</blockquote><div><br></div><div>Flashrom's problems run a lot deeper than that. Rather than regurgitate old discussion, I'll point to this thread: <a href="http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html">http://www.flashrom.org/pipermail/flashrom/2013-July/011271.html</a></div>

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"> Doing a commit is easy, but making sure that a commit follows<br>


certain guidelines is a huge time sink with none of the fun of writing code.<br>
- New contributors (corporate or community) would have to find a<br>
"sponsor" to actually commit their code. With a large committer base,<br>
this can happen rather quickly. With only six committers facing their<br>
own deadlines or other shortages of time, this could take quite a while. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">


<br>
AFAICS the reason to reduce the number of coreboot committers is to have<br>
gatekeepers who actually enforce guidelines by looking at patches before<br>
they commit them. That essentially introduces an additional review step.<br></blockquote><div><br></div><div>Anybody can review a patch and give it a score. AFAICT gatekeepers are necessarily tasked with scrutinizing code, 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.</div>

<div><br></div><div>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.<br>

</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
While such a step may be desirable, it would have to be made clear whose<br>
obligation it is to carry out commit+review step for new contributors,<br>
and how any fallback/failover mechanisms are implemented.<br></blockquote><div><br></div><div>MAINTAINERS file?</div><div><br></div><div>Having gerrit automatically add reviewers would be tremendously helpful too.</div><div>

<br></div><div>-- <br></div></div>David Hendricks (dhendrix)<br>Systems Software Engineer, Google Inc.
</div></div>