[demandal25]

Summary

scripts/upstream_canary.py priced an upstream sync against merge-base(recorded, theirs), but the sync itself merges against the recorded commit. The two differ whenever the target is on a diverged line, which is exactly the next sync: v0.7.3 and v0.6.18 sit on separate release branches. Against v0.7.3 the canary reported ~130 conflicts, mostly add/add on NVIDIA files the fork never touched; priced against the recorded base it reports the 30 the sync actually has to resolve.

What changed

• scripts/upstream_base.py — new sync_base(): the base a sync merges against. select() is unchanged, so amd_coverage --upstream-ref keeps its meaning.
• scripts/upstream_canary.py — uses sync_base(); the position line reads base (the recorded commit need not be a merge-base); the multiple-merge-base note fires only on the ancestry fallback.
• CONTRIBUTING.md — why git merge is wrong now names both failure modes, and the ours-count caveat matches the new base.

Architecture / design notes

theirs relative to the record	Base	Why
Contained by the record	theirs	Nothing to merge
Descends from the record	record	The normal next release on the same line — even if a merge -s ours already made it reachable, since that merge adds no content
Diverged (next release branch, upstream/main)	record	What merge-recursive $BASE -- HEAD theirs uses; a merge-base counts the recorded release's own commits as ours
Diverged, but ours reaches it (v0.5.3)	theirs, with a NOTE	Reachability cannot tell a content merge from an ancestry-only one, so the NOTE says so rather than claiming either

Measured on 8764a466b:

--upstream-ref	Before	After
v0.7.3	61a6c6518, ~130 conflicts	69ff11fc4, 30 (22 code)
upstream/main	61a6c6518, ~130	69ff11fc4, 30 (22 code)
v0.5.3	merge-base, 8	itself, nothing to merge (NOTE)
v0.6.18	clean	clean

The 30 are the files the v0.7.3 sync touches, including the pytest.ini / version.txt modify/delete pair.

Benchmark results

Not applicable: repo tooling and docs only, no kernel or runtime path is reachable from this diff.

Test plan

• pytest --noconftest tests/rocm/test_upstream_base.py tests/rocm/test_upstream_canary.py tests/rocm/test_amd_coverage.py tests/rocm/test_git_describe.py tests/rocm/test_repo_workflows.py — 230 passed, 9 skipped
• A/B: the diverged-line, next-release and canary-level tests fail on the old rule; the record-wins and ours-containment tests fail on the intermediate version
• Canary run against v0.7.3, upstream/main, v0.5.3 and v0.6.18 (table above)
• pre-commit run --from-ref origin/amd-integration --to-ref HEAD

[Copilot]

🟢 Approval recommended

No active review issues are reported for the update to use the recorded sync base in the upstream canary.

No open issues 🎉

What changed in this PR

Updates the upstream sync canary to estimate conflicts against the recorded sync base rather than a merge-base, matching the documented sync procedure for diverged release branches.

Changes:

• Adds sync_base() while preserving select() semantics for coverage tooling.
• Updates canary base selection, output labels, and reachability notices.
• Adds regression tests and clarifies the sync documentation.

File	Description
tests/​rocm/​test_upstream_canary.py	Verifies that diverged upstream releases use the recorded base.
tests/​rocm/​test_upstream_base.py	Tests sync-base selection across release and ancestry scenarios.
scripts/​upstream_canary.py	Uses sync_base() and adjusts base reporting and notices.
scripts/​upstream_base.py	Adds sync-specific base selection without changing coverage selection.
CONTRIBUTING.md	Explains recorded-base merging and the commit-count caveat.

_{Review effort: Balanced}

[github-actions]

Security scan found no critical or high findings on lines changed by this pull request

View the security scan run for complete reports.

“New” means the finding is located in a changed file on an added or modified line; it is not a base-versus-head findings delta.