[vz-dev] VZ Codebasis, Unit-Tests, und so

Justin Otherguy justin at justinotherguy.org
Sat Oct 5 18:48:57 CEST 2013


Hi Patrik,

Am 05.10.2013 um 12:22 schrieb Patrik Karisch:

> Gibt es denn nun mal Meldungen, wie es konkret mit dem Projekt weitergehen soll?

zuerst mal danke für deinen Einsatz - ne Antwort ist das mindeste, was du dir verdient hast, da hast du absolut recht.
Danke, dass du diese Diskussion angestossen hast und sorry, dass ich mich erst jetzt zu Wort melde.

In diesem Thread wurden mehrere Dinge diskutiert - Thorben hat die meisten Aspekte schon beantwortet (und mir ist keine Stelle aufgefallen, an der ich ihm hätte widersprechen können; obwohl ich das ja gerne mal tue).

Drum will ich auf ner anderen Ebene antworten:
das Wesentliche, woran es uns m.E. hier im Projekt mangelt (vlt.: bisher gemangelt hat?) waren Leute, die Zeit an der richtigen Stelle(TM) investiert haben. Die richtigen Stellen(TM) sind m.E.:
- Code-Beiträge: m.E. fehlen uns nicht die Commiter (also die mit commit-Rechten), sondern Contributoren (also die, die PRs stellen) und Tester (also die, die PRs testen)
- Unterstützung in git (sowohl Erklärbären als auch Leute, die mit den PRs kämpfen - vlt. ist git an sich auch mehr Problem als Lösung)
- Tests: Thorben hat schon angemerkt, dass auch Jemand ohne commit-Rechte ein "ich hab das so bei mir getestet, und zwar die folgenden 5 Features und es läuft alles total super" auf der Liste absetzen kann; dann kann ein Zweiter mit commit-Rechten das viel entspannter mergen, auch wenn er selbst gerade [keine Zeit | kein Equipment | kein *] hat; das sagt noch nichts darüber aus, ob wir zu wenige Commiter haben; von mir aus können das auch mehr Leute sein; mir geht es hier eher um ein 4-Augen-Prinzip. Als Voraussetzungen für commit-Rechte sehe ich im Wesentlichen: treibt sich schon ne Weile hier rum; commitet erst, wenn er sich überzeugt hat, dass der Commit nicht weh tut (selbst oder indem er auf die passende Info per Mail oder IRC wartet); ich halte es für klug, das Verhältnis "Anzahl Contributoren"/"Anzahl Commiter" überschaubar zu halten; im Zweifel könnt ihr euch gerne als Commiter anbieten. Wie gesagt: dass wir derzeit zu wenige Commiter hätten, sehe ich nicht; ob Unit-Tests die richtige Lösung sind kann ich nicht beantworten; klingt für mich erst mal gut - wenngleich ich befürchte, dass das (im Moment) ne Nummer zu groß ist; eine Checkliste scheint mir persönlich ein besseres "Aufwand/Nutzen"-Verhältnis zu haben
- Issues: wir haben einen - ziemlich verwaisten - Bugtracker; ob wir diesen oder den von github nutzen - für mich ist beides ok; unser Problem ist hier m.E. nicht das Werkzeug, sondern ein Mangel an a) Leuten, die Issues melden und (das drückt wesentlich mehr) b) Leuten, die Issues angehen; von mir aus kann das auch auf github sein
- Doku: das scheint mir nicht mehr zu unseren großen Sorgen zu gehören; das funktioniert mit dem Wiki m.E. gut genug (klar - das kann natürllch auch noch besser werden); ich denke tatsächlich, dass die Software insgesamt auf einem Stand angelangt ist, der es den meisten, die hier "angespült" werden erlaubt, diese zum Laufen zu bekommen (zur Not mit Hilfe aus der ML oder/und dem IRC - danke an der Stelle auch nochmal an die Helfer!); wobei: Doku zu den paar Standard-github-Prozessen ("wie merge ich einen PR, der nicht automatisch gemergt werden kann?", "wie...") wäre m.E. hilfreich; auf die passende Doku zu verweisen (nein, "man git" ist keine gültige Antwort) würde ja vlt. ausreichen

So kommen wir m.E. zum schnelleren Mergen von Patches, ohne dass das zu Lasten der Qualität geht. Ob uns dann weitere Unterzweige helfen, lasse ich offen - ich bin nicht dagegen; glaube aber, dass sie uns im Moment nicht helfen, sondern uns behindern.

Und noch mehr grundsätzliche Anmerkungen:
- ein Fork ist mit git (im Gegensatz zu cvs) keine Revolte mehr, sondern der naheliegendste Schritt, wenn du zum Projekt beitragen möchtest. Das kannst du immer tun - ich freu mich über Forks und PRs
- den Vorteil, weitere Entwickler zur github-Gruppe hinzuzunehmen, habe ich auch noch nicht verstanden; wir haben das bei vzlogger so gemacht (Idee wurde auf dem EC geboren - dazu weiter unten mehr), da wir hier alle, die aktiv an vzlogger entwickeln, unter einem Hut haben wollten (wie gut das funktioniert ist eine andere Geschichte); wenn du Entwickler bist und gerne zur github-Gruppe gehören möchtest: melde dich - warum nicht? Ich bin übrigens auch nicht der Einzige, der diese Rechte vergeben darf.
- ich halte es für wichtig, sehr sparsam mit Zeit umzugehen; daraus ergibt sich: sind wirklich die Werkzeuge unser Problem? dann sollten wir sie auswechseln; sind wirklich fehlende Berechtigungen unser Problem? dann sollten wir diese verteilen. Anderenfalls verbringen wir zu viel Zeit mit den falschen Problemen.
- ich bin sehr skeptisch mit Änderungen, die viel Zeit (Einzelner oder Mehrerer) erfordern; die Unit-Tests klingen für mich sehr gut; @Andreas: wenn du das bauen kannst (mit oder ohne Unterstützung): prima! Mir ist nicht klar, inwieweit das die Einstiegshürde für neue Entwickler erhöht (die scheint mir derzeit schon recht hoch); vlt. ist meine Befürchtung aber unbegründet (oder: zu sehr auf meine persönliche Sicht bezogen) - ich lasse mich gern überzeugen

Das Projekt läuft nun seit über 3 Jahren - ich freue mich, dass immer wieder neue Leute hierher finden und freue mich noch mehr, wenn Leute mit anpacken wollen. Wenn wir weiter kommen wollen, brauchen wir das auch.

Und jetzt noch drei ganz konkrete Punkte:
- dass Peters Erweiterungen an vzlogger es noch nicht in das Repo geschafft haben, finde ich sehr unbefriedigend; hier weiß ich, dass Peters Version derzeit die beste ist (naja - bei mir läuft sie ja auch prima...); es scheitert hier also schlicht daran, dass der Merge nicht per "click-click" zu machen ist. Wenn mir hier Jemand unter die Arme greifen möchte: gerne! Dafür lasse ich ne Tafel Schokolade deiner Lieblingssorte auf dem nächsten EC springen!
- demo.volkszaehler.org: den möchte ich schon ne ganze Weile auf eine andere Maschine umziehen; da wird es in nächster Zeit(TM) mal zu Unterbrechungen kommen; auch hier freue ich mich über Unterstützung; einer der konkreten Punkte: Thorben hatte schon mal vorgeschlagen, dass es einen "Disclaimer" für die Nutzung geben sollte; ein paar Ideen existieren schon - Details gerne per PM oder auch auf der Liste
- EC: das nächste Elektro-Camp findet am 1.+2. November in Texel (Holland) statt; wer das nicht kennt: komm hin - du wirst es nicht bereuen. Falls du aus dem Süden kommst: es gibt Fahrgemeinschaften (nein, für einen Sonderzug reicht der Zulauf noch nicht); Apropos Zulauf: derzeit sind auf der Registrierungs-Seite (http://developer.mysmartgrid.de/doku.php?id=ec1311-signup) erst 5 Leute eingetragen; lasst euch davon nicht täuschen - das waren bislang immer 30-40 Leute. Viel Spass und viel Lern. Versprochen. Wenn du tiefer in das Thema einsteigen willst oder den Austausch suchst: komm hin: http://developer.mysmartgrid.de/doku.php?id=ec1311-coordination

Einen hab ich noch:
ich finde diese Diskussion sehr konstruktiv und freue mich über eure Beiträge dazu. Im Zweifel spricht aber nix dagegen, einen Vorschlag einfach mal umzusetzen - ihr braucht keine Freigabe. Wer macht hat Recht ;-)

Haut rein!


Gruss, J.



More information about the volkszaehler-dev mailing list