Will do. -s
On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher <dave2w...@comcast.net> wrote: > 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 <san...@apache.org> wrote: > > > > 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 > >>>> > >>>> > >>> > >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
