[Pulp-dev] Pulp Code Owners

[Dana Walker]

Can this idea of SME as code owner be used *only* for notification so that
we don't get flooded with them for every PR across the codebase and *not*
as a requirement for merging so other still can get things rolling, this
just covers the scenarios where a PR fell between the cracks unnoticed?

--Dana

Dana Walker

Associate Software Engineer

Red Hat

<https://www.redhat.com>
<https://red.ht/sig>

On Tue, Aug 14, 2018 at 11:05 AM, David Davis <daviddavis at redhat.com> wrote:

> The code owner feature in Github requests reviews from code owners when a
> PR is opened. This both notifies the responsible team when they have a PR
> to review and also makes it clear who should be reviewing a particular PR
> so that the PR author can follow up with those people.
>
> David
>
>
> On Tue, Aug 14, 2018 at 10:36 AM Bryan Kearney <bkearney at redhat.com>
> wrote:
>
>> On 08/13/2018 05:29 PM, David Davis wrote:
>> >
>> >
>> > # Problem Statement
>> >
>> > For Pulp's review process, there are several areas we could improve:
>> >
>> > 1. It’s not always clear who should review files. Over time we have
>> > developed subject matter experts for different areas of the codebase,
>> > but these are not codified anywhere. It would be useful for us to define
>> > teams need to review projects using code owners.
>> >
>> > 2. PRs go unnoticed. Github has a request-review feature, but only
>> > members of the github organization can click 'request review' button. It
>> > would be great if when a PR is opened people automatically received PR
>> > review requests.
>> >
>> >
>> > # Team Examples
>> >
>> > Functional Tests - The QE Team should be code owners of functional tests
>> > that test core or core-maintained plugins
>> > The Tasking System  - bmbouter, daviddavis, and dalley are the SME in
>> > this area
>> >
>> >
>> > # Solution
>> >
>> > 1. Configure the code-owners feature of Github
>> > (https://blog.github.com/2017-07-06-introducing-code-owners/). It will
>> > allow a team of 2 or more people to be notified and asked for review
>> > when a PR modifies a file within a certain area of the code.
>> >
>> > 2. Require code-owner review to merge. This is described in this
>> > section:
>> > https://blog.github.com/2017-07-06-introducing-code-owners/
>> #an-extra-layer-of-code-security
>> >
>> >
>> > # Process
>> >
>> > The code owner role is not related to the commit bit. It's designed to
>> > get better reviews. Well reviewed work can be confidently merged by
>> > anyone with the commit bit.
>> >
>> > To make a change to code owners, open a PR with the changes, and call
>> > for a lazy consensus vote by mailing list. Similar to the PUP decision
>> > making process, voting must be open for 10 days, and the committers of
>> > the respective repository are voting.
>> >
>> > The code owners file itself should be owned by the core committers of
>> > the repository.
>> >
>> If the problem statement is a slowdown in PRs, how does limiting who can
>> do the review/merge solve the issue?
>>
>> -- bk
>>
>>
>>
> _______________________________________________
> Pulp-dev mailing list
> Pulp-dev at redhat.com
> https://www.redhat.com/mailman/listinfo/pulp-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/pulp-dev/attachments/20180814/43badfea/attachment.htm>