v0.2: Upstream rebase strategy + first rebase #13

New issue

Closed

opened 2026-05-03 14:53:50 -04:00 by zgaetano · 0 comments

zgaetano commented

2026-05-03 14:53:50 -04:00

Owner

We forked from upstream datarhei/core commit 0de97f4 ("Add linux/arm/v8 build") on 2026-04-17. Upstream has shipped at least v16.16.0 since (per CHANGELOG.md). No documented merge cadence; the diff gets uglier every week we wait.

Scope

Written policy in docs/REBASE.md: cadence, conflict-handling rules, divergence boundaries (when do we accept upstream change vs reject because it conflicts with WebRTC subsystem)
Tag the current main as v0.1.0-dragonfork (already done) and pre-rebase-v0.1
Execute first rebase against current upstream main
Verify: make release, make test, latency CI gate, manual TrueNAS deploy smoke
Tag v0.1.1-dragonfork if no behavioural changes, else v0.2.0-dragonfork-rebase as the new floor

Why now

The longer we wait the more upstream commits to walk, and the harder the conflict resolution. Doing this before the metrics + UI work means those land cleanly on a fresh upstream baseline instead of compounding divergence.

Open questions for design

Rebase or merge-from-upstream? Rebase keeps history linear but rewrites; merge preserves provenance but adds noise.
Vendored deps — upstream may have churned vendor/; do we accept blanket or audit?
Can/should we automate "monthly upstream rebase" via CI (open a PR, run tests, await human review)?

Needs a short design doc.

We forked from upstream `datarhei/core` commit `0de97f4` ("Add linux/arm/v8 build") on 2026-04-17. Upstream has shipped at least v16.16.0 since (per CHANGELOG.md). No documented merge cadence; the diff gets uglier every week we wait. ## Scope - Written policy in `docs/REBASE.md`: cadence, conflict-handling rules, divergence boundaries (when do we accept upstream change vs reject because it conflicts with WebRTC subsystem) - Tag the current main as `v0.1.0-dragonfork` (already done) and `pre-rebase-v0.1` - Execute first rebase against current upstream `main` - Verify: `make release`, `make test`, latency CI gate, manual TrueNAS deploy smoke - Tag `v0.1.1-dragonfork` if no behavioural changes, else `v0.2.0-dragonfork-rebase` as the new floor ## Why now The longer we wait the more upstream commits to walk, and the harder the conflict resolution. Doing this before the metrics + UI work means those land cleanly on a fresh upstream baseline instead of compounding divergence. ## Open questions for design 1. Rebase or merge-from-upstream? Rebase keeps history linear but rewrites; merge preserves provenance but adds noise. 2. Vendored deps — upstream may have churned `vendor/`; do we accept blanket or audit? 3. Can/should we automate "monthly upstream rebase" via CI (open a PR, run tests, await human review)? Needs a short design doc.