Skip to content

docs: upstream 동기 «정기 축» 판정 — 격차 기반 behind ≥ 20 [rustjava-upstream-sync-cadence-decision] - #29

Merged
Jun025 merged 4 commits into
mainfrom
feat/rustjava-sync-cadence-decision
Sep 4, 2026
Merged

docs: upstream 동기 «정기 축» 판정 — 격차 기반 behind ≥ 20 [rustjava-upstream-sync-cadence-decision]#29
Jun025 merged 4 commits into
mainfrom
feat/rustjava-sync-cadence-decision

Conversation

@Jun025

Copy link
Copy Markdown
Owner

판정

채택 제안 2026-09-04-sync-contract-stale-assets-decision#p0 에 대한 판정 회차다.

동기 회차는 git rev-list --count origin/main..upstream/main 이 «20 이상»일 때 연다.
시간(격주·월간)으로 열지 않는다.

신설 0(검사기·크론·워크플로) · .rs0줄 · allow 9곳 무접촉 · ★S9 미개시(behind 0).

★전제를 «먼저» 재서 제안의 전제를 «반증»했다

회차커밋새 충돌회차커밋새 충돌
S152S563
S215S6110
S319S711
S480S8128

상관계수 r = −0.169(커밋 수 ↔ 새 충돌) — 사실상 0이고 부호가 이다.
커밋 많은 4회차(37커밋) → 충돌 11 ↔ ★적은 4회차(8커밋) → 충돌 17.

누적 충돌도 포화한다(고정 base): 7커밋 16 → 10 17 → 21 17 → 32 17 → 33 19
⇒ ★26커밋을 더 벌려도 «+3».

⇒ ★★충돌을 만든 것은 «몇 개 왔는가»가 아니라 «무엇이 왔는가» — 우리 포크 지점 3곳 + 개명 스윕 같은 사건.

그래도 「아무것도 안 한다」로 가지 않았다 — 반증된 것은 «비용이 격차에 비례한다»는 기전이고,
제안이 지목한 «아무도 챙기지 않는다»는 위험은 그대로 참이다. ⇒ 축은 두되 임계를 포화점 뒤에 놓았다.

기각한 갈래와 이유

  • 시간 기반(⒜): upstream 이 ★37% 의 주에 커밋 0(12개월 144커밋/51주 · 주당 중앙 1) ⇒ ★behind 0 인데 회차를 여는 «빈 회차».
    그리고 충돌이 포화하는데 회차 오버헤드(티켓 3건)는 고정 ⇒ 자주 받으면 총비용이 는다.
  • 사건 기반(⒞): S3 의 충돌 9건은 upstream «신규» 파일에서, S8 의 8건은 전 트리 개명에서 왔다 ⇒ 경로 트리거가 대부분을 놓친다.
  • 축 미설치(⒟): 오늘 아무것도 알려 주지 않는다. 포화는 7~33 구간에서만 측정됐고 33 은 실제로 아팠다.

왜 «20» 인가 · 비용 · 방아쇠

  • 아래로 안 내림: 충돌이 7커밋에서 포화 ⇒ 더 자주 받아도 총량이 안 준다.
  • 위로 안 올림: 33 = 미측정 구역 입구(캠페인 시작점).
  • 실측 도달 중앙 44일 ⇒ ★연 6~8회 · 회차당 새 충돌 중앙 2.5 · 게이트② 사이클 8회차 중 7회가 1.
  • 방아쇠 = 기계가 «재고», 사람(총괄)이 «발권». 재는 자리 권고 = 이 repo 의 예약 워크플로
    (선례 rust-audit.yaml · upstream 은 read-only fetch발신 0). ★구현은 별건.

재측정 조건

3회차 뒤 다시 재라 — 회차당 충돌 중앙 ≥5 면 임계를 내리고, 도달 간격 ≤14일이면 올려라.
오늘의 값 = behind 0. ★**「오래됐다」는 재개 사유가 «아니다»** — 이 축은 시간이 아니라 격차로 열린다.

★인용 주의

★**「8회차가 들었다」를 «격차 33 의 비용»으로 읽지 마라** — 회차 경계는 §5 의 컷 분할이 정했고,
추가 비용의 큰 덩어리는 스쿼시로 계보가 접힌 것이며 merge_strategy: merge이미 닫혔다.

착지 형태

등재 repo ⇒ 게이트③은 --merge. ※형제 PR #27·#28approach.md·STATE.md·REPORT.md 를 함께 만진다 —
게이트③ 계약 2-c 의 «동봉 직후 재충돌은 정상» 그대로다.

jun0 added 4 commits September 4, 2026 22:29
…nc-cadence-decision]
채택 제안 2026-09-04-sync-contract-stale-assets-decision#p0 에 대한 판정.
전제를 먼저 재서 제안의 전제를 반증했다.
반증: 회차 커밋 수 ↔ 새 충돌의 상관계수 r = −0.169(사실상 0 · 부호 음). 커밋 많은
4회차(37커밋)가 충돌 11, 적은 4회차(8커밋)가 충돌 17이다. 누적 충돌도 포화한다 —
고정 base 에서 7커밋 16 → 33커밋 19 로, 26커밋을 더 벌려도 +3. ⇒ 충돌을 만든 것은
「몇 개 왔는가」가 아니라 「무엇이 왔는가」(우리 포크 지점 3곳 + 개명 스윕 같은 사건).
그래도 「아무것도 안 한다」로 가지 않았다 — 반증된 것은 「비용이 격차에 비례한다」는
기전이고, 「아무도 챙기지 않는다」는 위험은 그대로 참이다. 축은 두되 임계를 포화점 뒤에.
시간 기반 기각: upstream 이 37% 의 주에 커밋 0(12개월 144커밋/51주 · 주당 중앙 1)이라
시간 축은 behind 0 인데 회차를 여는 빈 회차를 만들고, 회차 오버헤드(티켓 3건)가
고정이라 자주 받으면 총비용이 는다. 사건 기반 기각: S3 충돌 9건은 upstream 신규
파일에서, S8 8건은 전 트리 개명에서 왔다 ⇒ 경로 트리거가 대부분을 놓친다.
임계 20 근거: 아래로는 7커밋 포화점, 위로는 33 이 미측정 구역 입구(실제로 아팠던 값).
도달 중앙 44일 ⇒ 연 6~8회. 회차당 새 충돌 중앙 2.5 · 게이트② 사이클 8회차 중 7회가 1.
방아쇠: 기계가 재고 사람(총괄)이 발권한다. 재는 자리 권고는 이 repo 의 예약 워크플로
(선례 rust-audit.yaml · upstream 은 read-only fetch 라 발신 0), 대안 bin/healthcheck 는
orchestrator 소관이라 별건. 구현은 이 회차가 하지 않았다.
재측정 조건(3회차 뒤 · 충돌 중앙 ≥5 면 내리고 · 도달 간격 ≤14일이면 올린다)을 §5-B 에
오늘의 값(behind 0)과 함께 박았다. 「오래됐다」는 재개 사유가 아니다.
신설 0(검사기·크론·워크플로) · .rs 0줄 · allow 9곳 무접촉 · rust.yml·DoD 블록 무접촉 ·
S9 미개시 · upstream 발신 0(git fetch 읽기만).
…m-sync-cadence-decision]
게이트² request-changes(F1~F5) 승계. 표기만 — 코드 0줄. 판정(⒝ 격차 기반 behind ≥ 20 ·
시간/사건 기반 기각 · 방아쇠 주체 · 포화 논거)은 무접촉이다.
F1 — §5-B⒜ 표 8행이 «전부 맨 수»였다. 이 파일의 상시 규칙(§5 「충돌 수엔 base 를 반드시
병기한다」)을 그 표가 어겼고 실제로 기준이 섞여 있었다. §5 자신이 「기준을 섞으면 없는
계열이 만들어진다」를 이미 규탄했는데, 초판은 그 열로 우상향을 §5-B 는 같은 열로
상관계수를 읽었다 — 방향만 반대이고 방법은 같다. ⇒ 정본을 «누적»으로 통일하고
base·merge-base 를 병기했으며, 「r 은 정밀 추정치가 아니라 부호 판정으로만 읽어라」를
못박았다(n=8 · 회차 경계가 컷 분할로 정해진 비무작위 표본).
F2 — S4 칸의 0 은 실측이 아니라 계획서 예측이었다(원문: 예측 0 / 복원 전 20 / 복원 후 2).
§5 제안표의 그 칸만 한 번도 정정되지 않았고 같은 파일 정정 블록은 이미 20 → 2 를 적어
두고 있었다. 하필 그 칸이 논증의 최강 데이터였다. ⇒ 실측 2 로 고치고 세 열을 다 계산해
실었다: A 초판 r=−0.169 합 28 · B S4 정정 r=−0.134 합 30 · C 정본 전부 누적 r=−0.155
합 33. 세 열 모두 부호가 음이고 「많은4 < 적은4」가 유지된다 ⇒ 판정 불변.
F3 — S6 의 0 은 델타이고 누적은 1(string.rs)이다. §5 가 그 오독을 실사고로 이름 붙인
자리라, 규칙을 담은 파일이 그 오독을 다시 생산하고 있었다. S3 의 +9 도 델타이고 누적은
11 이다(착지 커밋 제목 「충돌 11」).
F4 — ⒟ 의 「33 은 실제로 아팠던 값」을 삭제. 그것은 바로 위 ⒝ 가 금지한 독법(8회차를
격차의 비용으로 읽는 것) 위에 서 있어 같은 절 안의 자기모순이었다. 「33 너머는 미측정
구역」 논거는 혼자 선다. STATE·REPORT·워크로그의 같은 문장도 함께 지웠다.
F5 — 「20」은 밴드(하한 7 포화 시작 · 상한 33 측정 상한) 안에서 «고른» 수임을 명시했다.
밴드는 실측이고 그 안 누적이 16→17→17→17→19 로 평평해 어디를 골라도 데이터는 같은 말을
한다. 고른 근거는 「도달 중앙 ≈6주 ↔ 회차 오버헤드 3티켓의 균형」이라는 판단이고 재측정
조건이 그것을 검증한다. 「44일」 상수 인용 주의도 넣었다(재측 41일 · 창 정의 ±3일 ·
결론 영향 0). upstream 속도표 자체는 다시 재지 않았다(non-goal).
…nce-decision]
게이트² request-changes 승계 + 부모 #28(18fbb6e) 착지로 생긴 REPORT.md 충돌 해소를
한 커밋에 접었다(검수자 권고 — 추가 비용 0). 코드 기여 0줄.
F4 잔존 — worklog .json summary 에 정정 표지 «밖»으로 살아 있던 「33 은 실제로 아팠던
값이다」를 지우고 표지를 달았다. 그 필드는 다음 회차가 통째로 인용하는 표면이고,
approach.md ⒟ 와 STATE.md 에서는 지워 놓고 여기에만 남아 저장소가 자기와 어긋났다.
상시 규칙 전파(approach.md §5 「병기 없는 충돌 수는 어디에도 쓰지 않는다」·「델타인가
누적인가도 밝혀라」) — summary·워크로그 .md 산문·STATE.md·json issues 의 「S3 충돌
9건」·「S8 8건」을 델타/누적 + base·merge-base 병기로 고치고, 「중앙 44일」에 창 정의
주의(41일·±3일)를 전파했다. ★표를 고쳤다고 문서가 고쳐진 것이 아니다 — 같은 파일
안에서 표는 정확한데 산문은 맨 수였다.
★전수를 «명령 + 출력»으로 다시 돌렸고 그 결과 반려에 없던 두 자리를 더 찾았다:
STATE.md:16 과 json issues:27 도 같은 맨 수였다. 둘 다 고쳤다.
문면 좁힘 — approach.md 의 「착지 커밋 제목이 그 값의 1차 사료」를 «S1~S7» 로 한정하고
S8 은 예외임을 적었다(a76b305 제목·본문에 충돌 수 0건). 값 8 은 무접촉 — 그 출처는
git merge-tree --write-tree --name-only 3fb08a8bd42427 재측이다.
충돌 해소 — REPORT.md 1건을 합집합·시간순으로(미착지 최신인 이 회차 항목 → #28#27).
항목 중복 0 · 마커 0. ★auto-merge 된 STATE.md·approach.md 를 눈으로 확인했다:
양쪽 기여가 둘 다 살아 있고(진행중 1 + 완료 2 · §5-B 와 §4 두 절 공존) 구조 파손 0.
리베이스 0 · force-push 0.
코드 기여 0 증명: git diff --stat origin/main -- '*.rs' scripts/ .github/ CLAUDE.md
→ 0줄. 핀 대비 diff 에 잡히는 check-dod-ci-parity.py 5줄은 병합이 가져온 main 기여이고
git diff --quiet origin/main -- 그 파일 → rc=0(바이트 동일)로 확인했다.
…dence-decision]
STATE.md 진행중 → 완료(게이트③ PR #29 · --merge · 등재 repo · 게이트② 3회차 만에
approve · 반려 둘이 모두 「수를 어떻게 적었는가」였고 그 규율은 「표를 고쳤다고 문서가
고쳐진 것이 아니다」 · 부모 #27·#28 착지로 두 번 CONFLICTING 이 됐고 그때마다 머지로
해소했으며 검사 1건 → 10건으로 그 기전을 확증했다) + worklog .json 게이트③ 집행 1줄
(동봉 전 head 가 핀과 일치했음 · fetch 를 먼저 쳐 거짓 일치를 막았음). 코드 변경 0.
@Jun025
Jun025 merged commit 4b91e8f into mainSep 4, 2026
10 checks passed
@Jun025
Jun025 deleted the feat/rustjava-sync-cadence-decision branch September 4, 2026 16:46
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant

@Jun025