Files

T

AndreasTharangandClaude Sonnet 5 ab416fb34c Projektwissen: Git-Vorgaben, Ticketzugriff, Tests und Einstieg

Erster Stand des Repositories AG_QGIS/Projektwissen (bisher Arbeitstitel
"Workspace", ADR 0006). Der lokale Ordner heisst weiter AG_QGIS, weil darin
auch die Plugin-Klone liegen.

Git verbindlich (ADR 0007), aus dem bisherigen Wiki-Konzept entwickelt:
- docs/leitfaden/05_git_arbeitsweise.md mit Kanal-Kette, Branch-Namen und
  Gitea-Branch-Schutz.
- Der Einstiegspunkt eines Fixes richtet sich nach dem Kanal, in dem der
  Fehler sitzt; ein Fix an testing oder stable ist erst mit der
  Rueckfuehrung nach unten abgeschlossen. Das fehlte bisher.
- Der stabile Kanal heisst stable, nicht main: der Release-Workflow in
  Repository:hidden/workflows fuehrt git checkout "$CHANNEL" aus, der
  Branchname muss also dem Kanalnamen entsprechen. Er existiert in keinem
  Plugin-Repo und ist vom Maintainer anzulegen.
- Der Mensch drueckt ab: .claude/settings.json sperrt push, merge, tag.
- scripts/hallo.py und /hallo holen den Stand aller Klone, per
  Fast-Forward wo gefahrlos; nie mergen, stashen oder verwerfen.

Ticketzugriff:
- scripts/gitea.py liest Issues, Kommentare und PRs ueber die oeffentliche
  API, ohne Token, nur GET. Schreibendes nur als Entwurf in entwuerfe/.
- Skill sn-ticket.

Tests (ADR 0009):
- docs/leitfaden/06_tests.md: Testebenen, Testpflicht, und wie eine
  Fachperson beurteilt, ob Tests fachlich sinnvoll sind.
- scripts/testkatalog.py erzeugt docs/tests/testkatalog.md per ast-Parsing,
  ohne Import und ohne QGIS. Befund: nur 100 von 332 Tests haben einen
  Docstring, sn_basis keinen einzigen von 87.
- Vorlage und erste Testkonzept-Seite mit Mermaid. Dabei gefunden und gegen
  origin geprueft: _ermittle_gebietstyp_aus_fbschl hat keinen Test, obwohl
  PR #44/#45 genau diese Funktion tolerant gemacht hat.
- docs/konzept/07_qgis_tests_plan.md: Stufenplan fuer Tests gegen echtes
  QGIS. Dabei aufgefallen: QGIS 3.40 ist seit Januar 2026 End of Life,
  qgis_min steht aber noch darauf.

Werkzeuge (ADR 0008):
- 04_werkzeuge_einrichten.md nur noch Claude Code als CLI und in VS Code.
- .vscode/ entfernt, brauchbare Einstellungen als persoenliche Vorlage.

Ausserdem: README als Einstieg neu aufgebaut, Mermaid-Diagramm in
schnittstellen.md repariert (unmaskierte Klammern, rendert seither nicht).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>

2026-09-04 11:57:26 +02:00

4.0 KiB

Raw Blame History

0007 – Branchmodell: drei Kanäle, `stable` als stabiler Kanal, Rückführungspflicht

Status: vorgeschlagen · Datum: 2026-09-04 · Beteiligte: AG QGIS

Kontext

Es gab eine erste Beschreibung des Git-Vorgehens (Wiki-Export „Git-Konzept"), die drei Branches main/testing/unstable beschrieb und den Branch-Schutz auf GitHub erklärte. Der Abgleich mit den Repositories am 04.09.2026 ergab vier Abweichungen:

Ein stabiler Kanal-Branch existiert in keinem Plugin-Repository. Vorhanden sind unstable, testing und in zwei Repos ein nicht mehr bespieltes oldstable. Der Skill sn-release vermerkt entsprechend „stable derzeit ohne Branch".
Der Branchname ist nicht frei wählbar. Der Release-Workflow in Repository, Branch hidden/workflows (Michael Otto, 19.06.2026), klont das Plugin-Repository und führt git checkout "$CHANNEL" aus. $CHANNEL wird im Workflow des Plugin-Repos (Michael Otto, 18.03.2026) aus dem Tag-Suffix abgeleitet und ist unstable, testing oder stable. Der Branch muss also genauso heißen wie der Kanal. Ein Branch main würde den stabilen Release-Pfad brechen.
Der Branch-Schutz wurde für GitHub beschrieben, wir arbeiten mit Gitea 1.27.
Branch-Namen sind uneinheitlich: bug/crash_on_exit, feature/Drucklayout-überarbeiten (Umlaut), alkis-nur-laden-stop und fix-fbschl-feldname (ohne Präfix).

Zusätzlich fehlte die Antwort auf die praktisch wichtigste Frage: Wo fängt ein Fix an, der einen Release-Kandidaten in testing betrifft?

Entscheidung

Die Kette lautet feature/* → unstable → testing → stable. Der stabile Kanal heißt stable und wird angelegt; er entspricht dem Feed plugins.xml und dem Tag ohne Suffix. oldstable wird als Altlast archiviert.

stable statt main, weil die vorhandene Release-Infrastruktur den Branchnamen aus dem Kanalnamen ableitet. main wäre möglich, würde aber eine Änderung an fremder, funktionierender Infrastruktur samt Testrelease erfordern — ohne fachlichen Gewinn. Der Name ist im Projekt ohnehin durchgängig verankert: CHANNEL-Variable, Tag-Logik, plugins.xml.

Der Einstiegspunkt eines Fixes richtet sich nach dem Kanal, in dem der Fehler auftritt, nicht nach seiner Dringlichkeit. Ein Fix an testing oder stable ist erst abgeschlossen, wenn er per Pull Request in alle darunterliegenden Kanäle zurückgeführt wurde. Ohne Rückführung verschwindet der Fix beim nächsten Hochstufen.

Branch-Namen: feature/, bugfix/, hotfix/, doku/, release/, jeweils mit Issue-Nummer, ASCII, klein, Bindestriche. Die drei Kanäle sind auf Gitea gegen direkten Push geschützt.

Push, Merge und Tag bleiben bei Menschen. KI-Agenten bereiten vor; die entsprechenden Kommandos sind in .claude/settings.json technisch gesperrt, damit die Regel nicht nur auf Zuruf gilt.

Vollständige Fassung: docs/leitfaden/05_git_arbeitsweise.md.

Folgen

Der Maintainer muss stable je Plugin-Repository anlegen und die Schutzregeln setzen (docs/konzept/08_repo_einrichten.md). Bis dahin endet die Kette bei testing und der stabile Feed bleibt leer. Jeder Fix an testing kostet einen zweiten Pull Request — das ist gewollt und billiger als ein wiederauftauchender Fehler. Vier verwaiste Branches im Bestand sind zu prüfen und zu löschen.

Wer den Branch später doch main nennen will, muss zuerst git checkout "$CHANNEL" in Repository:hidden/workflows um eine Kanal→Branch-Zuordnung erweitern und das mit einem Testrelease auf Plugin_Test_Action absichern. Diese Entscheidung wäre dann zu ersetzen.

Verworfene Alternativen

Den stabilen Kanal main nennen (vertraute Git-Konvention, bricht aber den Release-Workflow, solange die Infrastruktur nicht mit angepasst wird — Eingriff in fremde, funktionierende Automatisierung ohne fachlichen Gewinn); bei zwei Kanälen bleiben (dann gibt es dauerhaft kein produktionsreifes Ziel und plugins.xml bleibt leer); Fixes grundsätzlich in unstable beginnen und nach testing vorziehen (Cherry-Picks über mehrere Kanäle sind fehleranfälliger als der umgekehrte Weg).

4.0 KiB Raw Blame History Unescape Escape

0007 – Branchmodell: drei Kanäle, stable als stabiler Kanal, Rückführungspflicht