[coreboot] Changes to the coreboot Project Structure

[David Hendricks]

On Fri, Mar 21, 2014 at 11:52 AM, David Hendricks <dhendrix at google.com>wrote:

>
>
>
> On Thu, Mar 20, 2014 at 5:39 PM, Carl-Daniel Hailfinger <
> c-d.hailfinger.devel.2006 at gmx.net> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.coreboot.org/pipermail/coreboot/attachments/20140321/fff461cd/attachment-0001.html>