sorb/ThreadNet-Web
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases 4 Wiki Activity

Doku: Merge-Risiko praeziser fassen - Art des Eingriffs, nicht Umfang

Browse Source 
Meine Aussage "ClamAV kostet mehr als das gesamte Branding zusammen" war so nicht haltbar: gemessen sind es ~130 zu ~104 Zeilen, der groesste Einzelpatch ist sogar Branding (HelpUserSettingsTab.tsx, 71 Zeilen).

Der Unterschied liegt woanders: Branding-Patches stehen am Rand und sind nach einem Umbau wiederfindbar, ClamAV-Patches stehen mitten in Entschluesselungs- und Fehlerpfaden. Dazu der eigentliche Haken - verschiebt Upstream die viewmodels/-Dateien, entsteht kein Konflikt, die Zeilen sind schlicht weg und Git meldet nichts. Deshalb ist dort ein Funktionstest maszgeblich, nicht die Merge-Ausgabe.

Refs axion1337.chat/ThreadNet-Web#7
This commit is contained in:
Thore Cimbal
2026-08-06 12:00:00 +00:00
parent 9ac56d671b
commit 965c456dee
1 changed files with 26 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/axion1337-fork.md
+26 -5
View File
@@ -101,11 +101,32 @@ Updates.
- `apps/web/src/components/views/messages/MImageBody.tsx`, `MAudioBody.tsx` - `apps/web/src/components/views/messages/MImageBody.tsx`, `MAudioBody.tsx`
- `apps/web/src/viewmodels/message-body/FileBodyViewModel.ts`, `VideoBodyViewModel.ts` - `apps/web/src/viewmodels/message-body/FileBodyViewModel.ts`, `VideoBodyViewModel.ts`
⚠️ **Die zweite Gruppe ist die teure.** Element baut die Medien-Anzeige gerade auf ### Nicht der Umfang entscheidet, sondern die Art des Eingriffs
MVVM um (`docs/MVVM.md`, `docs/MVVM-v1.md`) — die beiden `viewmodels/`-Dateien
existierten in älteren Ständen gar nicht. Genau dort, wo wir eingegriffen haben, Gemessen in geänderten Zeilen nehmen sich beide Gruppen wenig: **ClamAV ~130 Zeilen,
bewegt sich Upstream also aktiv. Ein Update wird an ClamAV mehr Arbeit machen als am Branding ~104**. Der größte Einzelpatch ist sogar Branding
gesamten Branding zusammen. (`HelpUserSettingsTab.tsx`, 71 Zeilen). Wer nur zählt, hält beide für gleich teuer.
Sie sind es nicht, und der Grund ist die Art des Eingriffs:
- **Branding-Patches stehen am Rand.** Ein zusätzlicher Default in `SdkConfig.ts`,
ein `<link>` im `<head>`, ein `<li>` in einer Settings-Liste. Wird die Datei
umgebaut, sieht man sofort, wo das eigene Stück wieder hin muss.
- **ClamAV-Patches stehen mittendrin** — in Entschlüsselungs- und Fehlerpfaden der
Medien-Pipeline, verschränkt mit Upstream-Logik. Ein geänderter Kontrollfluss
bedeutet nicht „Konflikt lösen", sondern „neu verstehen".
⚠️ **Und der eigentliche Haken: `viewmodels/`.** Element baut die Medien-Anzeige
gerade auf MVVM um (`docs/MVVM.md`; v1 ist dort bereits als deprecated markiert —
der Umbau läuft also schon in zweiter Runde). `FileBodyViewModel.ts` und
`VideoBodyViewModel.ts` gab es in älteren Ständen gar nicht. Unsere Änderung darin
ist mit je 6 Zeilen winzig — aber wenn Upstream diese Dateien verschiebt, umbenennt
oder auflöst, entsteht **kein Konflikt**: die Zeilen sind einfach weg, und Git meldet
nichts. Das ist gefährlicher als ein Konflikt, weil es stillschweigend passiert.
Praktische Folge: Nach einem Upstream-Update ist an ClamAV nicht die Merge-Ausgabe
maßgeblich, sondern ein **Funktionstest** — eine verschlüsselte Datei senden und eine
abgelehnte empfangen. Steht so auch in Abschnitt 2.
### Was daraus für künftige Änderungen folgt ### Was daraus für künftige Änderungen folgt