incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sid Anand <san...@apache.org>
Subject Re: Auto-cleaning up Stale PRs
Date Thu, 20 Sep 2018 14:56:27 GMT
Will do.

-s

On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher <dave2wave@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 <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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message