nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andy LoPresto <alopresto.apa...@gmail.com>
Subject Re: [DISCUSS] Stale PRs
Date Sat, 15 Sep 2018 15:44:08 GMT
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
alopresto@apache.org
alopresto.apache@gmail.com
PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D EF69

> On Sep 15, 2018, at 08:33, Pierre Villard <pierre.villard.fr@gmail.com> 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] https://github.com/apache/beam/blob/master/.github/stale.yml
> 
> Pierre

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