+1.
Apache CarbonData will try it to clean invalid pull requests and jira
issues, thanks.
Regards
Liang
--
Sent from: http://apache-incubator-general.996316.n3.nabble.com/
-
To unsubscribe, e-mail:
Will do.
-s
On Wed, Sep 19, 2018 at 8:02 PM Dave Fisher 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
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 wrote:
>
> Thanks Greg and Ismael!
> -s
>
>>
Thanks Greg and Ismael!
-s
On Wed, Sep 19, 2018 at 6:39 PM Greg Stein 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*
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
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 wrote:
> While I agree that autoclosing
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
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
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
A stale PR is defined by a policy -- for example, 60 days without any
movement on the PR.
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.
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 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
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.
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 wrote:
>
> Im also interested in this PR policy
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 wrote:
> Hi Folks!
> I wanted a policy-driven approach to
14 matches
Mail list logo
