epos. Another way to manage who can merge prs is to gate the
>> pr process using git actions, so that if an approved approver indicates a
>> pr is good then the raiser can merge – this would give us granularity on
>> write access – PyTorch follows this sort of process.
>>
>
indicates a
> pr is good then the raiser can merge – this would give us granularity on
> write access – PyTorch follows this sort of process.
>
> kind regards, David.
>
>
> From: Martijn Visser
> Date: Thursday, 12 October 2023 at 10:32
> To: dev@flink.apache.o
@flink.apache.org
Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
Hi everyone,
I'm overall +1 on Ryan's comment.
When we're talking about component ownership, I've started a
discussion on the Infra mailing list in the beginning of the year on
it. In principle, the "code
nk that
> component ownership helps scope the subset of prs to review / merge.
>
> Kind regards, David.
>
>
> From: Ryan Skraba
> Date: Wednesday, 4 October 2023 at 15:09
> To: dev@flink.apache.org
> Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale P
– I would think that
component ownership helps scope the subset of prs to review / merge.
Kind regards, David.
From: Ryan Skraba
Date: Wednesday, 4 October 2023 at 15:09
To: dev@flink.apache.org
Subject: [EXTERNAL] Re: FW: RE: Close orphaned/stale PRs
Hey, this has been an
Hey, this has been an interesting discussion -- this is something that
has been on my mind as an open source contributor and committer (I'm
not a Flink committer).
A large number of open PRs doesn't _necessarily_ mean a project is
unhealthy or has technical debt. If it's fun and easy to get your
c
Hi,
To add I agree with Martijn’s insights; I think we are saying similar things.
To progress agreed upon work, and not blanket close all stale prs,
Kind regards, David.
From: David Radley
Date: Wednesday, 4 October 2023 at 10:59
To: dev@flink.apache.org
Subject: [EXTERNAL] RE: Close orph
