[Pulp-dev] Pulp Code Owners

Milan Kovacik mkovacik at redhat.com
Tue Aug 14 15:42:30 UTC 2018


On Tue, Aug 14, 2018 at 5:11 PM, Dana Walker <dawalker at redhat.com> wrote:

> 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?
>

lazy myself excuse would be: meh I'm not an SME here, I don't review that
PR part

My concern is we should use the tools in a way that motivate reviews to
both spread the domain knowledge (i.e to become a commit bit owner and/or
an SME eventually) and help the review process speed and quality.

I suggest adopting formal criteria that would promote this; implementation
can be thru Code owners just mind to create/update the codeowners file a
commit bit is required too.

--
milan


>
> --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
>>
>>
>
> _______________________________________________
> 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/32caa784/attachment.htm>


More information about the Pulp-dev mailing list