Thanks Greg and Ismael! -s On Wed, Sep 19, 2018 at 6:39 PM Greg Stein <gst...@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 <san...@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 <ieme...@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 <san...@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 <ma...@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 < > > dave2w...@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 <san...@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 < > > dave2w...@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 <lupe...@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 <san...@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-unsubscr...@incubator.apache.org > > > > > >> For additional commands, e-mail: > > general-h...@incubator.apache.org > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > > > For additional commands, e-mail: general-h...@incubator.apache.org > > > > > > > > >
