You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maka.apache.org by "Astro-Han (via GitHub)" <gi...@apache.org> on 2026/08/26 02:10:22 UTC
[D] [DISCUSS] Close pull requests that have had no new commits for 30 days [maka]
GitHub user Astro-Han created a discussion: [DISCUSS] Close pull requests that have had no new commits for 30 days
I propose we automatically close a pull request whose author has not pushed a new commit for 30 days, after a 7-day warning. Comments would not reset the timer — only a new commit does. A closed PR can be reopened at any time.
I intend to proceed by [lazy consensus](https://community.apache.org/committers/lazyConsensus.html): I will wait at least 72 hours, longer if discussion is still active, and summarize the outcome here before opening a PR.
**Where to object:** this Discussion is relayed to `dev@maka.apache.org`, but [the bridge is one-way](https://github.com/apache/infrastructure-github-discussions-notifier) — a reply sent to the list will not appear here. I will watch both and fold anything raised on the list back into this thread.
## Proposed workflow
```yaml
name: Close stale pull requests
on:
schedule:
- cron: '0 0 * * *'
workflow_dispatch:
permissions:
pull-requests: write
jobs:
stale:
if: github.repository == 'apache/maka'
runs-on: ubuntu-latest
steps:
- uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
with:
days-before-pr-stale: 30
days-before-pr-close: 7
ignore-pr-updates: true
exempt-draft-pr: false
exempt-pr-labels: 'pinned,security'
days-before-issue-stale: -1
days-before-issue-close: -1
operations-per-run: 200
stale-pr-message: >
This pull request has had no new commits for 30 days and has been
marked stale. It will be closed in 7 days unless a new commit is
pushed. Comments do not reset this timer — only a new commit does,
so that a maintainer following up cannot keep a PR open on the
author's behalf. If this PR is blocked on a decision rather than on
you, say so and we will apply an exempt label.
close-pr-message: >
This pull request has been closed because it had no new commits for
37 days. This is not a judgement on the merit of the change in any
way — it is only a way of keeping the review queue honest about what
is actually in flight. You can reopen it at any time and we will
pick the review back up.
```
## Why, from our own data
I read all 127 open PRs before writing this rather than copying another project's settings.
**Thirteen PRs have had no new commit for 14 days or more, and in twelve of them the ball is with the author** — the last event is a maintainer comment or a review-bot comment, and the author has not pushed since. The one exception is my own draft, #1916. Four of the twelve are already approved; the rest are split between `CHANGES_REQUESTED` and `REVIEW_REQUIRED`.
This matters because the strongest ASF argument against auto-closing is that it punishes contributors for our review latency. That argument is sound in general and does not describe this repository right now.
## Why the timer counts commits, not activity
`actions/stale` measures `updatedAt` by default, which any comment resets. Every Apache project I checked uses that default — Iceberg, Airflow, Spark, Beam, Arrow, Doris, Flink.
Here it would measure the wrong thing. Under the activity clock, **zero** of our 127 open PRs are stale at 30 days. Not because nothing is abandoned, but because maintainers sweep the queue and a review bot comments; almost every `updatedAt` currently traces to one batch of follow-up comments I posted on 2026-08-23. An activity clock would measure how often we nag. `ignore-pr-updates: true` decouples the two, so we can keep following up without silently keeping dead PRs alive.
## Why drafts are included
`AGENTS.md` asks contributors to open published PRs as drafts, so draft is our normal starting state, not a signal of abandonment. Exempting them would exempt much of the queue for no reason related to what we are measuring — and it would change little either way: of 17 open drafts, one has gone 14 days without a commit and none has gone 30.
## Why 30 days
Other projects' numbers are calibrated to their own tempo (Iceberg 30/7, Airflow 45/5, Spark 100/0), and Maka is about three months old. PRs with no new commit for at least N days:
| N | 7 | 14 | 21 | 30 | 45 |
|---|---|---|---|---|---|
| PRs | 28 | 13 | 8 | **1** | 0 |
45 days would be inert at our tempo. 14 is too aggressive — two weeks away should not cost you a PR. 30 is where the distribution thins out, and **today it would mark exactly one PR, #1253**. I would rather start with something close to a no-op that ages well than clear a backlog we do not have. Worth revisiting after a quarter with fresh data.
## The objection I expect
Closing an approved PR feels wrong, and four of the twelve are approved. I think it is still right: branch protection dismisses approvals on any new commit, and at our merge rate a branch untouched for 30 days is almost certainly conflicting already — #3299 and #3723 both went `DIRTY` within a day or two of `main` moving. The approval has not survived; closing only makes that visible, and reopening is one click.
If the community disagrees, an easy amendment is to exempt approved PRs and close them by hand.
## ASF notes
- I found no foundation-wide rule requiring or forbidding this; it is a per-project convention, and a common one — seven of the eight Apache projects I checked run a stale workflow.
- No INFRA allowlist request is needed: the [GitHub Actions Policy](https://infra.apache.org/github-actions-policy.html) allows `actions/*` without restriction. I pinned the SHA anyway, as Airflow and Iceberg do.
- Permissions are minimal and the trigger is `schedule` only, never `pull_request_target`. If the first run shows `issues: write` is also needed to label PRs, I will say so rather than widening it quietly.
- The 30-day window, the commit-based timer, and the wording of both bot messages all follow from [community over code](https://www.apache.org/theapacheway/): a distributed community participates asynchronously, a maintainer's nudge should not start anyone's clock, and closing must state plainly that it is not a judgement. The wording is adapted from Apache Iceberg's.
- Reversible: if it turns out wrong we delete one file, and nothing closed is lost.
Objections, different numbers, or a different measure entirely are all welcome.
---
*Disclosure per `AGENTS.md`: I used Claude Code (Opus 5) for the data in this proposal — the 127-PR survey, the commit-age distribution, the waiting-on-author classification, and the comparison against other Apache projects' `stale.yml`. I checked its output against the repository and the linked ASF pages. The position argued here is mine.*
GitHub link: https://github.com/apache/maka/discussions/3839
----
This is an automatically sent email for dev@maka.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org
Re: [D] [DISCUSS] Close pull requests that have had no new commits for 30 days [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
GitHub user Astro-Han added a comment to the discussion: [DISCUSS] Close pull requests that have had no new commits for 30 days
**Outcome: consensus holds, implementation moves to #4070.**
One +1 (@M4n5ter), no objections here or on dev@. But I am not opening the PR I promised, for two reasons.
#4070 opened two days after this thread and covers the same `stale.yml` from both sides. Merging this thread's numbers first would decide its PR half before it is done — for a policy that today would mark one PR and close none.
And the config I proposed here does not do what I said. I wrote that `ignore-pr-updates: true` means "comments do not reset the timer, only a new commit does." It does not: per the action's docs it switches the comparison from `updated_at` to `created_at`, i.e. pure age, so a PR opened six months ago and pushed to last week would be marked immediately. No option for "only a new commit resets" exists — it has to be computed.
Both points are now on #4070, along with the 30 + 7 thresholds from here, which match Iceberg. Continue there.
*(Drafted with AI assistance; I verified the `actions/stale` behaviour against its documentation myself.)*
GitHub link: https://github.com/apache/maka/discussions/3839#discussioncomment-18221050
----
This is an automatically sent email for dev@maka.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org
Re: [D] [DISCUSS] Close pull requests that have had no new commits for 30 days [maka]
Posted by Guangdong Liu <li...@apache.org>.
+1
On 2026/08/26 02:18:34 "M4n5ter (via GitHub)" wrote:
>
> GitHub user M4n5ter added a comment to the discussion: [DISCUSS] Close pull requests that have had no new commits for 30 days
>
> +1
> I approve of this
>
> GitHub link: https://github.com/apache/maka/discussions/3839#discussioncomment-18155998
>
> ----
> This is an automatically sent email for dev@maka.apache.org.
> To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
> For additional commands, e-mail: dev-help@maka.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org
Re: [D] [DISCUSS] Close pull requests that have had no new commits for 30 days [maka]
Posted by "M4n5ter (via GitHub)" <gi...@apache.org>.
GitHub user M4n5ter added a comment to the discussion: [DISCUSS] Close pull requests that have had no new commits for 30 days
+1
I approve of this
GitHub link: https://github.com/apache/maka/discussions/3839#discussioncomment-18155998
----
This is an automatically sent email for dev@maka.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org
Re: [D] [DISCUSS] Close pull requests that have had no new commits for 30 days [maka]
Posted by "Astro-Han (via GitHub)" <gi...@apache.org>.
GitHub user Astro-Han closed a discussion: [DISCUSS] Close pull requests that have had no new commits for 30 days
I propose we automatically close a pull request whose author has not pushed a new commit for 30 days, after a 7-day warning. Comments would not reset the timer — only a new commit does. A closed PR can be reopened at any time.
I intend to proceed by [lazy consensus](https://community.apache.org/committers/lazyConsensus.html): I will wait at least 72 hours, longer if discussion is still active, and summarize the outcome here before opening a PR.
**Where to object:** this Discussion is relayed to `dev@maka.apache.org`, but [the bridge is one-way](https://github.com/apache/infrastructure-github-discussions-notifier) — a reply sent to the list will not appear here. I will watch both and fold anything raised on the list back into this thread.
## Proposed workflow
```yaml
name: Close stale pull requests
on:
schedule:
- cron: '0 0 * * *'
workflow_dispatch:
permissions:
pull-requests: write
jobs:
stale:
if: github.repository == 'apache/maka'
runs-on: ubuntu-latest
steps:
- uses: actions/stale@4391f3da665fdf50b6810c1a66712fb9ba21aa93 # v11.0.0
with:
days-before-pr-stale: 30
days-before-pr-close: 7
ignore-pr-updates: true
exempt-draft-pr: false
exempt-pr-labels: 'pinned,security'
days-before-issue-stale: -1
days-before-issue-close: -1
operations-per-run: 200
stale-pr-message: >
This pull request has had no new commits for 30 days and has been
marked stale. It will be closed in 7 days unless a new commit is
pushed. Comments do not reset this timer — only a new commit does,
so that a maintainer following up cannot keep a PR open on the
author's behalf. If this PR is blocked on a decision rather than on
you, say so and we will apply an exempt label.
close-pr-message: >
This pull request has been closed because it had no new commits for
37 days. This is not a judgement on the merit of the change in any
way — it is only a way of keeping the review queue honest about what
is actually in flight. You can reopen it at any time and we will
pick the review back up.
```
## Why, from our own data
I read all 127 open PRs before writing this rather than copying another project's settings.
**Thirteen PRs have had no new commit for 14 days or more, and in twelve of them the ball is with the author** — the last event is a maintainer comment or a review-bot comment, and the author has not pushed since. The one exception is my own draft, #1916. Four of the twelve are already approved; the rest are split between `CHANGES_REQUESTED` and `REVIEW_REQUIRED`.
This matters because the strongest ASF argument against auto-closing is that it punishes contributors for our review latency. That argument is sound in general and does not describe this repository right now.
## Why the timer counts commits, not activity
`actions/stale` measures `updatedAt` by default, which any comment resets. Every Apache project I checked uses that default — Iceberg, Airflow, Spark, Beam, Arrow, Doris, Flink.
Here it would measure the wrong thing. Under the activity clock, **zero** of our 127 open PRs are stale at 30 days. Not because nothing is abandoned, but because maintainers sweep the queue and a review bot comments; almost every `updatedAt` currently traces to one batch of follow-up comments I posted on 2026-08-23. An activity clock would measure how often we nag. `ignore-pr-updates: true` decouples the two, so we can keep following up without silently keeping dead PRs alive.
## Why drafts are included
`AGENTS.md` asks contributors to open published PRs as drafts, so draft is our normal starting state, not a signal of abandonment. Exempting them would exempt much of the queue for no reason related to what we are measuring — and it would change little either way: of 17 open drafts, one has gone 14 days without a commit and none has gone 30.
## Why 30 days
Other projects' numbers are calibrated to their own tempo (Iceberg 30/7, Airflow 45/5, Spark 100/0), and Maka is about three months old. PRs with no new commit for at least N days:
| N | 7 | 14 | 21 | 30 | 45 |
|---|---|---|---|---|---|
| PRs | 28 | 13 | 8 | **1** | 0 |
45 days would be inert at our tempo. 14 is too aggressive — two weeks away should not cost you a PR. 30 is where the distribution thins out, and **today it would mark exactly one PR, #1253**. I would rather start with something close to a no-op that ages well than clear a backlog we do not have. Worth revisiting after a quarter with fresh data.
## The objection I expect
Closing an approved PR feels wrong, and four of the twelve are approved. I think it is still right: branch protection dismisses approvals on any new commit, and at our merge rate a branch untouched for 30 days is almost certainly conflicting already — #3299 and #3723 both went `DIRTY` within a day or two of `main` moving. The approval has not survived; closing only makes that visible, and reopening is one click.
If the community disagrees, an easy amendment is to exempt approved PRs and close them by hand.
## ASF notes
- I found no foundation-wide rule requiring or forbidding this; it is a per-project convention, and a common one — seven of the eight Apache projects I checked run a stale workflow.
- No INFRA allowlist request is needed: the [GitHub Actions Policy](https://infra.apache.org/github-actions-policy.html) allows `actions/*` without restriction. I pinned the SHA anyway, as Airflow and Iceberg do.
- Permissions are minimal and the trigger is `schedule` only, never `pull_request_target`. If the first run shows `issues: write` is also needed to label PRs, I will say so rather than widening it quietly.
- The 30-day window, the commit-based timer, and the wording of both bot messages all follow from [community over code](https://www.apache.org/theapacheway/): a distributed community participates asynchronously, a maintainer's nudge should not start anyone's clock, and closing must state plainly that it is not a judgement. The wording is adapted from Apache Iceberg's.
- Reversible: if it turns out wrong we delete one file, and nothing closed is lost.
Objections, different numbers, or a different measure entirely are all welcome.
---
*Disclosure per `AGENTS.md`: I used Claude Code (Opus 5) for the data in this proposal — the 127-PR survey, the commit-age distribution, the waiting-on-author classification, and the comparison against other Apache projects' `stale.yml`. I checked its output against the repository and the linked ASF pages. The position argued here is mine.*
GitHub link: https://github.com/apache/maka/discussions/3839
----
This is an automatically sent email for dev@maka.apache.org.
To unsubscribe, please send an email to: dev-unsubscribe@maka.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maka.apache.org
For additional commands, e-mail: dev-help@maka.apache.org