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 01:48:08 GMT
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
> > >
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message