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:57:28 GMT
Jeremy,

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
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:51, Pierre Villard <pierre.villard.fr@gmail.com> 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 <alopresto.apache@gmail.com> 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
>> 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