incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Fisher <dave2w...@comcast.net>
Subject Re: Auto-cleaning up Stale PRs
Date Thu, 20 Sep 2018 03:02:01 GMT
Hi -

No objections from me. I do ask you let the IPMC know in your podling report if this results
in any controversy from the creators of any autoclosed pull requests.

Regards,
Dave

Sent from my iPhone

> On Sep 19, 2018, at 6:48 PM, Sid Anand <sanand@apache.org> wrote:
> 
> Thanks Greg and Ismael!
> -s
> 
>> On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <gstein@gmail.com> wrote:
>> 
>> Hello all,
>> 
>> The confusion here was "write access to the repository" (not allowed)
>> versus "write access to Pull Requests" (allowed). It took the Beam folks
>> some research to determine that GitHub *does* differentiate between these
>> two write capabilities (historically, GitHub has not been very granular
>> with permissions).
>> 
>> So. When Airflow said Probot Stale needed write access, we took that to
>> mean *code*.
>> 
>> After the pointer to Beam, reminding Infra of the research Beam had done
>> (and my enabling of Stale for them) ... we realized that Stale *is*
>> perfectly fine because it doesn't touch the code repository.
>> 
>> Probot Stale has been enabled for Airflow.
>> 
>> Cheers,
>> Greg Stein
>> Infrastructure Administrator, ASF
>> 
>> 
>>> On Wed, Sep 19, 2018 at 7:47 PM Sid Anand <sanand@apache.org> wrote:
>>> 
>>> Ismael,
>>> Thanks for this pointer. I've re-opened my INFRA ticket and referenced
>> your
>>> Apache Beam one. Super helpful.. if we get it enabled, please collect a
>>> beer from anyone in the Apache Airflow community!
>>> 
>>> -s
>>> 
>>>> On Wed, Sep 19, 2018 at 7:39 AM Ismaël Mejía <iemejia@gmail.com>
wrote:
>>>> 
>>>> While I agree that autoclosing PRs can be unwelcoming. I don't see
>>>> clearly the argument of INFRA in the ticket.
>>>> 
>>>>> The policy of no-write-access for bots is a requirement by the
>>>> foundation legal team. We cannot allow write access to repos without an
>>>> ICLA.
>>>> 
>>>> Labeling and closing the PR in github does not imply write-access from
>>>> the bot into the 'real' gitbox repository, so I don't see how this can
>>>> be an issue, or are we in a gray area (in case bot automation of
>>>> metadata can have legal issues which I doubt since this is not part of
>>>> the source distribution).
>>>> 
>>>> As a precedent we had Probot/Stale enabled for Apache Beam so I
>>>> suppose that this should be possible for Airflow too.
>>>> https://issues.apache.org/jira/browse/INFRA-16589
>>>> 
>>>>> On Thu, Sep 13, 2018 at 5:55 PM Sid Anand <sanand@apache.org> wrote:
>>>>> 
>>>>> Apache Airflow has, at any point, >200 PRs open. During the slower
>>> summer
>>>>> months, we've been merging 100-200 PRs a month. We have been growing
>>> the
>>>>> community -- we have <600 contributors, ~200 companies using it, and
>>> 20+
>>>>> committers. A person is promoted to "Committer" in recognition for
>> work
>>>>> he/she has done without an expectation of future work in maintaining
>>> the
>>>>> code base. Hence, minting new committers doesn't always translate
>> into
>>>>> greater bench strength where merging PRs is concerned. That said, we
>>> are
>>>>> actively adding new committers. The last 4-5 committers we added have
>>>> been
>>>>> super active maintainers, so the coverage on PRs and questions has
>> been
>>>>> getting better.
>>>>> 
>>>>> There are many causes of Cold-case PRs:
>>>>> 
>>>>>   1. Submitter is not actively responding
>>>>>      1. One example is that we requested tests and they were never
>>>> written
>>>>>      2. Discussion ensued on the PR and the submitter did not accept
>>> the
>>>>>      community's feedback
>>>>>   2. Committers didn't get to it in a timely manner and after a
>> while
>>>> the
>>>>>   engagement fell
>>>>> 
>>>>> We are in a better position now to handle (2) -- this was not the
>> case
>>> a
>>>>> year ago. We're at least able to keep up with our in-flow of PRs
>>>>> week-to-week, but are still having challenges with the
>>>>> previously-established backlog. But, (1) is also a contributor to
>> stale
>>>> PRs.
>>>>> 
>>>>> We do have a lot of stale PRs to manually handle -- I spent all of
>>> Summer
>>>>> 2017 pinging submitters of old PRs and I find myself in the same
>>> position
>>>>> now.
>>>>> 
>>>>> Probot/stale is a useful tool. It has legitimate use-cases. A policy
>>>>> reflects the health/mentality/approaches of the community. A tool
>> like
>>>> this
>>>>> enforces the policy. Let's not overlook adoption of what would be a
>>> very
>>>>> useful tool to the community due to a meta conversation about
>> policy. I
>>>>> think everyone on this list cares about growing a healthy and vibrant
>>>>> community. We also care about being efficient with our spare time.
>>> This
>>>>> tools can help us manage both.
>>>>> 
>>>>> Also, I am not suggesting that we close JIRA, just stale PRs. JIRAs
>>> need
>>>> to
>>>>> be kept open so we don't lose visibility of bugs/features/etc... This
>>>> tool
>>>>> doesn't handle JIRA closing anyway.
>>>>> 
>>>>> -s
>>>>> 
>>>>> On Thu, Sep 13, 2018 at 1:37 AM Mark Thomas <markt@apache.org>
>> wrote:
>>>>> 
>>>>>>> On 12/09/18 19:16, Sid Anand wrote:
>>>>>>> A stale PR is defined by a policy -- for example, 60 days without
>>> any
>>>>>>> movement on the PR.
>>>>>> 
>>>>>> Automatically closing such issues is not going to do anything to
>> aid
>>>>>> community building and is likely to actively damage such efforts.
>>>>>> 
>>>>>>> Stale PRs would be bad experiences in general for community
>>> members,
>>>> but
>>>>>>> after no movement for 60 days, this is just about cleaning up
PRs
>>>> that
>>>>>> are
>>>>>>> not getting feedback from the committers or PR submitters.
>>>>>> 
>>>>>> That is the wrong solution the problem.
>>>>>> 
>>>>>> If reporters of issues are not responding to questions and there
is
>>>>>> genuinely nothing the community can do to progress the issue
>> without
>>>>>> their input then closing the issue is fair enough. But that should
>>> very
>>>>>> much be the exception rather than the rule. In projects I am
>> involved
>>>> in
>>>>>> I probably do that a handful of times a year. However, even in a
>> good
>>>>>> chunk of those cases, the main reason for the lack of response from
>>> the
>>>>>> OP is that the community did not respond to the original report for
>>> an
>>>>>> excessively long time.
>>>>>> 
>>>>>> If the committers are not responding to issues in a timely manner
>>> then
>>>>>> the solution is to start looking for more committers.
>>>>>> 
>>>>>> Reporting an issue is often the first interaction someone new to
>> the
>>>>>> community has with the project. It should be treated as an
>>> opportunity
>>>>>> to attract new members to the community and to grow the project.
>>>>>> 
>>>>>> Mark
>>>>>> 
>>>>>> 
>>>>>>> 
>>>>>>> -s
>>>>>>> 
>>>>>>> On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher <
>>> dave2wave@comcast.net>
>>>>>> wrote:
>>>>>>> 
>>>>>>>> Hi -
>>>>>>>> 
>>>>>>>> I was pointing out a potential community problem which is
what
>> we
>>>> are
>>>>>>>> about here in the Incubator.
>>>>>>>> 
>>>>>>>> On Sep 12, 2018, at 10:27 AM, Sid Anand <sanand@apache.org>
>>> wrote:
>>>>>>>> 
>>>>>>>> A stale PR has not activity for some length of time.
>>>>>>>> https://github.com/probot/stale
>>>>>>>> 
>>>>>>>> The policy file example shown on that link it pretty easy
to
>>>> follow, so
>>>>>>>> I'll avoid pasting a wall of text into this email.
>>>>>>>> 
>>>>>>>> This seems like a pretty valuable and much-needed piece of
>>>> management-y
>>>>>>>> software. Unfortunately, I was informed Apache Infra could
not
>>> grant
>>>>>> write
>>>>>>>> perms to this GitHub plugin. I'd like to understand how we
>> decide
>>>> which
>>>>>>>> plugins on GitHub get whitelisted?
>>>>>>>> 
>>>>>>>> 
>>>>>>>> The Incubator does not make these decisions. The Apache
>>>> Infrastructure
>>>>>>>> team makes these.
>>>>>>>> 
>>>>>>>> You can contact Infra -
>> https://www.apache.org/dev/infra-contact
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Dave
>>>>>>>> 
>>>>>>>> 
>>>>>>>> -s
>>>>>>>> 
>>>>>>>> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher <
>>> dave2wave@comcast.net>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Hi -
>>>>>>>> 
>>>>>>>> What if the stale PR is from a new community member who is
>> trying
>>> to
>>>>>> make
>>>>>>>> a contribution? Those should be handled by a committer with
>> direct
>>>>>>>> discussion.
>>>>>>>> 
>>>>>>>> Regards,
>>>>>>>> Dave
>>>>>>>> 
>>>>>>>> Sent from my iPhone
>>>>>>>> 
>>>>>>>> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko <lupesko@gmail.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>> Im also interested in this PR policy automation.
>>>>>>>> 
>>>>>>>> For Apache MXNet, there is no automation that I am aware
of that
>>>> handles
>>>>>>>> that. And it can be super helpful in handling stale PRs...
>>>>>>>> 
>>>>>>>> Hagay
>>>>>>>> 
>>>>>>>> On Tue, Sep 11, 2018, 12:07 Sid Anand <sanand@apache.org>
>> wrote:
>>>>>>>> 
>>>>>>>> Hi Folks!
>>>>>>>> I wanted a policy-driven approach to automatically label,
>> comment,
>>>> and
>>>>>>>> close inactive/stale PRs. Probot does this, but need some
write
>>>> perms to
>>>>>>>> GitHub.
>>>>>>>> 
>>>>>>>> https://github.com/probot/stale
>>>>>>>> 
>>>>>>>> I just learned this is not possible per
>>>>>>>> https://issues.apache.org/jira/browse/INFRA-17005
>>>>>>>> 
>>>>>>>> How are other projects solving this problem? And why is probot
>> not
>>>> on
>>>>>>>> 
>>>>>>>> say
>>>>>>>> 
>>>>>>>> an approved list of GitHub integrations?
>>>>>>>> 
>>>>>>>> -s
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail:
>> general-unsubscribe@incubator.apache.org
>>>>>>>> For additional commands, e-mail:
>>> general-help@incubator.apache.org
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>>>> 
>>>>>> 
>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
>>>> For additional commands, e-mail: general-help@incubator.apache.org
>>>> 
>>>> 
>>> 
>> 


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org


Mime
View raw message