Using the tests for Pulp 3 as example, since the code basis is hosted in
Pulp repos, I think that could be created a QE group to be involved in any
new code changes related to the tests.
My suggestion is at least one QE person should review changes to the code
basis related to the tests. This will
Doing some research on code owners, I found[0] that I was wrong in that
code owners have to have the commit bit:
*The people you choose as code owners must have write permissions for the
repository.*
I think this makes the code owners feature less useful to us. More
importantly though, it means t
On 08/14/2018 11:00 AM, Milan Kovacik wrote:
> hard unless the SME (and/or commit bit ownership) status is tied
> formally to review quality and rate.
>
I can see nagging the owners, but doing reviews of other parts of code
you dont know is a great way to (1) Learn it and (2) help the project.
--
On Tue, Aug 14, 2018 at 5:11 PM, Dana Walker 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
On Tue, Aug 14, 2018 at 5:05 PM, David Davis 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
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?
--Da
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 1
On Tue, Aug 14, 2018 at 4:36 PM, Bryan Kearney 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
On Tue, Aug 14, 2018 at 4:29 PM, Ina Panova wrote:
> +1 for the pup.
>
> Milan,
>
> I guess you are SME, when you are publicly recognized to understand the
> topic.
> You will ask *when* this public recognition is happening? When the answer
> to the such question like:
> -Who is person to contac
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 the
+1 for the pup.
Milan,
I guess you are SME, when you are publicly recognized to understand the
topic.
You will ask *when* this public recognition is happening? When the answer
to the such question like:
-Who is person to contact for X?
And the answer will be :
- It's this guy Y.
Rega
I know I said that code owners should be SMEs but I don’t think it should
it should be a strict requirement. The term SME and what constitutes an SME
are nebulous and hard to define. I think the lazy consensus model would be
a good first start as determining who qualifies for code ownership.
For h
On Tue, Aug 14, 2018 at 3:47 PM, David Davis wrote:
> On Tue, Aug 14, 2018 at 9:35 AM Milan Kovacik wrote:
>
>>
>>
>> On Tue, Aug 14, 2018 at 1:26 PM, David Davis
>> wrote:
>>
>>> The relevant party could either be a subset of the commit bit owners
>>> (e.g. task group) or a set of people who d
On Tue, Aug 14, 2018 at 9:35 AM Milan Kovacik wrote:
>
>
> On Tue, Aug 14, 2018 at 1:26 PM, David Davis
> wrote:
>
>> The relevant party could either be a subset of the commit bit owners
>> (e.g. task group) or a set of people who don’t have the commit bit (e.g.
>> QE). See the team examples fro
On Tue, Aug 14, 2018 at 1:26 PM, David Davis wrote:
> The relevant party could either be a subset of the commit bit owners (e.g.
> task group) or a set of people who don’t have the commit bit (e.g. QE). See
> the team examples from my original email.
>
So what you mean is actually a trusted sub
>
> Daniel, you are correct. The only caveat is that PRs can’t be merged if
> they touch a file owned by a team and haven’t been approved by that team.
Actually that's what I meant. In that case we just need to be careful
about getting into a situation where all 2-3-4 of the code owners are out
The relevant party could either be a subset of the commit bit owners (e.g.
task group) or a set of people who don’t have the commit bit (e.g. QE). See
the team examples from my original email.
Daniel, you are correct. The only caveat is that PRs can’t be merged if
they touch a file owned by a team
+0 who's the relevant party if not the commit bit owner?
+1 for commit bit owners receiving automatic notification to review
--
milan
On Tue, Aug 14, 2018 at 12:56 AM, Daniel Alley wrote:
> +1. My understanding is that this will not directly limit who can review
> or merge code, but should stre
+1. My understanding is that this will not directly limit who can review or
merge code, but should streamline the review process by notifying relevant
parties?
On Mon, Aug 13, 2018 at 5:29 PM, David Davis wrote:
> We have come up with initial proposal of how to use code owners feature in
> Pulp.
19 matches
Mail list logo
