nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Pierre Villard <pierre.villard...@gmail.com>
Subject Re: [DISCUSS] Stale PRs
Date Sat, 15 Sep 2018 15:51:05 GMT
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, None, 0 bytes)
View raw message