Adding a MAINTAINERS file
Rick Altherr
raltherr at google.com
Wed Nov 2 01:35:26 AEDT 2016
Thanks Brendan. Given the projects usage of Gerrit for most of repos, would
there be an advantage to using Gerrit to enforce the reviewer and
maintainer roles? How will we prevent MAINTAINERS from getting out of sync
with commit privileges?
On Tue, Nov 1, 2016, 1:04 AM Brendan Higgins <brendanhiggins at google.com>
wrote:
> For those who were not present, there was an OpenBMC meetup of sorts
> last week. One issue that Nancy Yuen, Abhishek Pandit, and myself
> brought up for non-IBM contributors was ownership and organization of
> projects; this went in a couple directions, but at some point somebody
> proposed a Linux kernel style MAINTAINERS list as a way to find people
> relevant for discussions in the various sub-parts of the project.
>
> I made an initial implementation:
> https://gerrit.openbmc-project.xyz/#/c/944/
>
> Most of it should be pretty self-explanatory (if not please join in
> the discussion). Nevertheless, I distinguished between reviewers and
> maintainers; whereas a reviewer is someone who is familiar enough with
> a given part of a project that she is a good person to address
> questions to concerning that component and should be included on code
> reviews; a maintainer is someone who's approval is required to check a
> patch set into a repository.
>
> I chose reviewers based on the amount of commits contributed to a
> given repository; I know this is not the best way to decide whether
> someone should be considered an expert on a particular part of the
> code base, but I thought it was a reasonable place to start.
> Additionally, breaking things up only at the repo level is probably
> also not the most useful as people may become experts within a
> particular part of a given repository, but again I think this is a
> reasonable starting place and I added semantics for breaking it down
> further.
>
> For maintainers, I chose two people for each repository; the first is
> the person who already has the authoritative access I described above;
> the second was chosen to be a major contributor. For Linux, u-boot,
> ipmi-tool, and qemu that is some combination of Joel, Cédric, and
> Jeremy. For everything else, all of the userland stuff and yocto, that
> is Patrick and Brad. I recall discussing adding Brad as a maintainer
> for the userland stuff in the meeting, but I figure it is something we
> should also discuss on the email list for everyone's benefit. We had
> not discussed adding a second maintainer for anything else, but I
> figure it is probably best practice to have more than once person who
> can submit code in all cases.
>
> I fully expect that the MAINTAINERS file I uploaded will require a
> good deal of discussion before it is ready to submit, but I figured it
> would be easiest to start with something to talk over.
>
> Cheers
> _______________________________________________
> openbmc mailing list
> openbmc at lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/openbmc
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20161101/3a176541/attachment-0001.html>
More information about the openbmc
mailing list