[Freifunk Franken] GitLab und Workflow-Diskussion auf der dev-Liste

Michael Fritscher michael at fritscher.net
Sa Feb 6 14:05:32 CET 2016


Flo schrieb:
> Elitär: überlese ich einfach. Geschlossen: Nicht geschlossener, als
> jedes andere Open Source Projekt.
> Kompliziert: liegt immer im Auge des Betrachters.
>
> Ich sehe das alles nicht so kritisch. Wir treffen uns ja heute zu dem
> Thema und jeder kann seinen Senf dazu
> abgeben. Sollte dabei raus kommen, dass die meisten Leute den aktuellen
> Ansatz weiter führen wollen,
> dann ist das auch ok. Nur weil Einzelne, zu denen ich ja auch gehöre, es
> anders gewohnt sind, ist das noch kein
> ausreichendes Argument, das umzustellen. Die Mehrheit muss davon
> überzeugt sein, dass uns ein neuer Ansatz und/oder
> System Vorteile bringt.
>
> Ich seh die "Schwächen" eigentlich wo anders:
>
> - Mir fällt es unheimlich schwer, zu sehen, an was gearbeitet wurde/wird
> und warum, und was ins nächste release mit rein kommt.
> - Mir fehlt ein vernünfiges Bugtracking und Issue-Management
> - Mir fehlen feature branches
> - Mit fehlt ein release management, das auch bugfixes in älteren
> releases berücksichtigt.
> - Mir fehlt ein ci-system, das merge-requests automatisch rejected, wenn
> diese nicht bauen oder andere regeln verletzen

Kann ich 100%ig unterschreiben.

Eine Sache noch (von Delphin):
>> Wer GitHub und dessen Erfolg kennt weis, das gerade der dort gelebte
>> dezentrale Ansatz, bei dem sich jeder ein Repository forken kann um
>> dann öffentlich seine Änderungsvörschläge als Pull-Request zur
>> Diskussion zu stellen, weitaus benutzerfreundlicher und dezentraler
>> ist
Ich persönlich mag den "auf Teufel komm raus" Fork-Ansatz garnicht. Er
weckt nämlich die Illusion, dass man sich mit dem ursprünglichen Autor
nicht absprechen muss. Anfangs geht es vielleicht sogar auch ohne, aber
spätestens wenn man seine Änderungen mergen lassen möchte muss man sich
mit dem ursprünglichen Autor abstimmen. Und das geht viel besser, wenn man
dies VOR dem Entwickeln macht, und den ursprünglichen Autor nicht vor
vollendete Tatsachen setzt (der vielleicht ähnliches geplant hat und jetzt
Arbeit doppelt gemacht hat, oder die Herangehensweise des Patches
problematisch ist). Die schlimmstmögliche Variante ist dann, dass 2
unabhängig voneinander entwickelte Versionen existieren, wo viel
Reibungsverlust entsteht. Bei Freifunk kommt noch dazu, dass
Inkompatibilitäten zwischen Versionen ernste Konsequenzen haben können.
Außerdem kann es massiv Ärger geben, wenn eine Firmware, wo Freifunk drauf
steht, großen Quatsch macht (Sendeleistung massiv hochdrehen, filtern
etc.) Das unterscheidet Freifunk von vielen OS-Projekten - ein Malprogramm
kann kein Netz lahmlegen.

Ich fürchte, dass so ein Ansatz bei Freifunk sehr kontraproduktiv ist -
v.a. auch gerade wegen der persönlichen Konstellation einiger Leute hier.
Wenn Leute aus emotionalen Gründen nichtmal mehr zu einem Treffen kommen
haben wir wesentlich gröbere Probleme - und da sind Ansätze, wo man meint,
erstmal ohne Absprache drauflosbasteln zu können und es beim Mergen "drauf
ankommen zu lassen" Gift.

Viele Grüße,
Michael




Mehr Informationen über die Mailingliste franken