[sdf-jkl]

Rationale for this change

Draft prototype for discussion; not ready for review or merge. Two PRs can each pass against an older main and still break when combined. A merge queue would require the combined candidate to pass CI before it reaches main.

This is separate from #55314, which experiments with moving contributor PR builds to forks. It provides the upstream check before merge that such a setup would need.

What changes are included in this PR?

• Reuse ten regular language and tooling workflows on merge_group, with one required Merge Queue result. Every suite must succeed; failed, cancelled, and skipped suites block the candidate. On PRs, the new check only permits queue entry; existing PR CI remains unchanged.
• Give reusable workflows distinct concurrency groups and exclude queue branches from ordinary push builds, avoiding cancellations and duplicate runs.
• Propose a main-only queue in .asf.yaml: squash merges, one candidate build at a time, and a six-hour check timeout. Merging this configuration would activate the queue. Extra, packaging, and release jobs remain outside the required gate.

This first step adds pre-merge validation rather than reducing CI usage. dev/merge_arrow_pr.py uses the direct merge API and cannot enqueue a PR; the prototype documents using GitHub's queue UI and closing the issue after the actual merge. That maintainer workflow needs agreement before activation.

Are these changes tested?

• Ten local tests pass, covering gate results and workflow wiring. The new workflow and reusable calls pass actionlint; existing matrix-expression warnings in Python/R Extra are unchanged.
• Full suite on the fork: running on the exact PR head. Lint, Ubuntu release/merge-script tests, and Archery (including the new tests) passed. ARM Linux C++ failed downloading ORC 2.2.1: the archive redirect timed out and the CDN fallback returned 404. Other builds continue; macOS jobs remain queued. The full suite is not green.
• Fork-only gate demonstration: confirmed the production gate accepts successful suites, rejects both failed and skipped suites, and permits PR queue entry. Its overall workflow is intentionally red because it injects failures.
• The new PR eligibility check also passed on this draft. It does not attest that the full suite passed.

The personal fork cannot enable GitHub's native merge queue. These runs test workflow execution and aggregation, not queue ordering, stale-candidate replacement, or automatic merging. Those need an organization-owned sandbox before activation. The smoke-test/bootstrap commit is on a separate fork branch and is not in this PR; the fork's main is unchanged.

Discussion points: do we want this upstream gate, which suites should initially be mandatory, and is the proposed queue/merge procedure acceptable? A tracking issue and dev-list discussion can follow once the prototype's scope is agreed.

Are there any user-facing changes?

No library API changes. The proposed configuration changes how maintainers merge PRs into main.

Was AI used for this PR?

Codex generated the implementation, tests, documentation, and description and performed the initial review. Human review is pending.

PR code and description written by:

• Human
• AI

Reviewed before submission by:

• Human
• AI
• Not reviewed

[github-actions]

Thanks for opening a pull request!

This pull request has been automatically converted to a draft because its title doesn't match Arrow's required format.

If this is not a minor PR, could you open an issue for this pull request on GitHub? https://github.com/apache/arrow/issues/new/choose

Opening GitHub issues ahead of time contributes to the Openness of the Apache Arrow project.

Then could you also rename the pull request title in the following format?

GH-${GITHUB_ISSUE_ID}: [${COMPONENT}] ${SUMMARY}

or

MINOR: [${COMPONENT}] ${SUMMARY}

After updating the title, you can mark the pull request as ready for review.

See also:

• Other pull requests
• Contribution Guidelines - Contributing Overview

[sdf-jkl]

@rok @raulcd @kou — would you support exploring a merge queue for main? I've put together this draft prototype to make the proposal concrete. Early feedback on the direction would help; it is not ready for review or merge.

The proposed upstream gate runs the regular language and tooling suites on the combined candidate before merging. This could provide the final upstream validation for the fork-CI experiment in #55314. This draft alone adds CI work; reducing PR build duplication would be a later step.

The fork demonstration confirms that the gate accepts successful suites and rejects failed or skipped suites. The full fork run has an ORC download failure and queued macOS jobs, so it isn't green. Native queue behavior still needs an organization-owned sandbox.

Would the regular suite be a reasonable initial required set, and would using GitHub's queue UI be acceptable while merge_arrow_pr.py remains unable to enqueue? The draft starts with one candidate at a time. Nothing has been enabled upstream.

[sdf-jkl]

Sorry the agent pushed this too early, I'd like to iterate a little myself before asking to take a look

[rok]

I think we might need this option soon, so thats for working on it.
Question - could we have this feature in https://github.com/apache/infrastructure-asfyaml and simply enable it the repo?