nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <>
Subject Re: [DISCUSS] Stale PRs
Date Sat, 15 Sep 2018 15:57:28 GMT

What about in the scenario where the submitter does everything and we (the committers) are
slow? I’m not saying we shouldn’t try to fix all the problems, just that I see a lot more
of the latter happening. 

Andy LoPresto
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Sep 15, 2018, at 08:51, Pierre Villard <> wrote:
> Andy,
> Totally get your points. I imagine that introducing this approach would
> help keeping dynamic exchanges on pull requests.
> In case a PR needs complex/time consuming work (or in case the author is
> just not in a position to process comments), I think we could have two
> approaches:
> - the PR is considered stale after 60 days but is actually closed one week
> later. I think it leaves time for someone (ideally the author) to comment
> and give an update so that the PR is not considered stale anymore, no?
> - for important PRs, it's possible to "remove" this mechanism using
> specific labels but I guess we would have to ask ASF infra if we want to
> have rights to add labels on PRs (?)
> Pierre
> Le sam. 15 sept. 2018 à 17:44, Andy LoPresto <> a
> écrit :
>> Pierre,
>> I’m going to delay my response on that proposal while I ask for (aka
>> should gather on my own) some information. Is that really our problem? By
>> that, I mean are stale PRs where we are getting bogged down? I am sure
>> there are some old ones that should be closed out. My larger concern is
>> that even new PRs don’t get reviewed immediately for a number of reasons.
>> 1. Balance of committers to submissions. As the project continues to grow,
>> we have far more people providing code than can review it.
>> 2. Quality of PR. Not that the code is necessarily bad, but the PR doesn’t
>> clearly explain the problem and how they are solving it, provide test
>> cases, provide templates or a Docker container if interacting with an
>> external service, etc. All of these things add up to make the cost of
>> reviewing higher.
>> 3. What PRs cover. Previously, there was still a lot of low-hanging fruit,
>> and less complexity. While the project is still fairly cleanly organized,
>> many PRs now are less “add this simple functionality” and more “improve
>> this complicated feature.”
>> I guess I would not have a problem with your proposal, but I do wonder if
>> there are more effective ways to reduce the backlog by identifying other
>> areas of improvement.
>> Andy LoPresto
>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69
>>> On Sep 15, 2018, at 08:33, Pierre Villard <>
>> wrote:
>>> Hi,
>>> The number of open PRs is still growing and it could make think people
>> that
>>> the project is not healthy/active (even though a quick look at the last
>>> commit date or the commits rate is a clear indication that the project is
>>> healthy).
>>> In order to encourage people to review code and keep active discussions
>> on
>>> the PRs, I suggest to find a way to keep this number as small as
>> possible.
>>> To do so, I'd like to ask the wider community if the approach taken by a
>>> project like Apache Beam would be a good idea:
>>> "A pull request becomes stale after its author fails to respond to
>>> actionable comments for 60 days. Author of a closed pull request is
>> welcome
>>> to reopen the same pull request again in the future."
>>> This approach is managed by a file [1] in the .github directory of the
>>> repository.
>>> What do you think about this approach?
>>> [1]
>>> Pierre

  • Unnamed multipart/alternative (inline, 7-Bit, 0 bytes)
View raw message