spark-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Hyukjin Kwon <gurwls...@gmail.com>
Subject Re: Auto-closing PRs when there are no feedback or response from its author
Date Wed, 09 Oct 2019 06:40:45 GMT
> 1. Although we close old JIRA issues on EOL-version only, but some issues
doesn't have `Affected Versions` field  info at all.
>    - https://issues.apache.org/jira/browse/SPARK-8542

For this case actually, I thought we resolved such cases all .. maybe some
of them slipped out of my hand.
Few years ago, we made affected version a required field:
[image: Screen Shot 2019-10-09 at 3.36.15 PM.png]
It should be good to resolve them at least to let reporters to update the
affected versions. and all such JIRAs will be old JIRAs anyway.


> 2. Although we can do auto-close PRs that have a merge conflict and
haven't been updated in months, but some PRs don't have conflicts.
>     - https://github.com/apache/spark/pull/7842 (Actually, this is the
oldest PR due to the above reason.)

Yea, this is a good point. This might be one of the reasons for that manual
tagging way to identify case by case.



2019년 10월 9일 (수) 오후 3:02, Dongjoon Hyun <dongjoon.hyun@gmail.com>님이
작성:

> Thank you for keeping eyes on this difficult issue, Hyukjin.
>
> Although we try our best, there exist some corner cases always. For
> examples,
>
> 1. Although we close old JIRA issues on EOL-version only, but some issues
> doesn't have `Affected Versions` field  info at all.
>     - https://issues.apache.org/jira/browse/SPARK-8542
>
> 2. Although we can do auto-close PRs that have a merge conflict and
> haven't been updated in months, but some PRs don't have conflicts.
>     - https://github.com/apache/spark/pull/7842 (Actually, this is the
> oldest PR due to the above reason.)
>
> So, I'm +1 for trying to add a new manual tagging process
> because I believe it's better than no-activity status and that sounds
> softer than the direct closing due to the grace-period.
>
> Bests,
> Dongjoon.
>
>
> On Tue, Oct 8, 2019 at 7:26 PM Sean Owen <srowen@gmail.com> wrote:
>
>> I'm generally all for closing pretty old PRs. They can be reopened
>> easily. Closing a PR (a particular proposal for how to resolve an
>> issue) is less drastic than closing a JIRA (a description of an
>> issue). Closing them just delivers the reality, that nobody is going
>> to otherwise revisit it, and can actually prompt a few contributors to
>> update or revisit their proposal.
>>
>> I wouldn't necessarily want to adopt new process or tools though. Is
>> it not sufficient to auto-close PRs that have a merge conflict and
>> haven't been updated in months? or just haven't been updated in a
>> year? Those are probably manual-ish processes, but, don't need to
>> happen more than a couple times a year.
>>
>> If there's little overhead to adoption, cool, though I doubt people
>> will consistently use a new tag. I'd prefer any process or tool that
>> implements the above.
>>
>>
>> On Tue, Oct 8, 2019 at 8:19 PM Hyukjin Kwon <gurwls223@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > I think we talked about this before. Roughly speaking, there are two
>> cases of PRs:
>> >   1. PRs waiting for review and 2. PRs waiting for author's reaction
>> > We might not have to take an action but wait for reviewing for the
>> first case.
>> > However, we can ping and/or take an action for the second case.
>> >
>> > I noticed (at Read the Docs,
>> https://github.com/readthedocs/readthedocs.org/blob/master/.github/no-response.yml)
>> there's one bot integrated with Github app that does exactly what we want
>> (see https://github.com/probot/no-response).
>> >
>> > 1. Maintainers (committers) can add a tag to a PR (e.g.,
>> need-more-information)
>> > 2. If the PR author responds with a comment or update, the bot removes
>> the tag
>> > 3. If the PR author does not respond, the bot closes the PR after
>> waiting for the configured number of days.
>> >
>> > We already have a kind of simple mechanism for windowing the number of
>> JIRAs. I think it's time to have such mechanism in Github PR as well.
>> >
>> > Although this repo doesn't look popular or widely used enough, seems
>> exactly matched to what we want and less aggressive since this mechanism
>> will only work when maintainers (committers) add a tag to a PR.
>> >
>> > WDYT guys?
>> >
>> > I cc'ed few people who I think were in the past similar discussions.
>> >
>>
>

Mime
View raw message