Das Paradoxe an einer "Begründung", man habe eigentlich gar keine Zeit für irgendetwas und auf der anderen Seite ständigen Änderungen am Code von anderen, hatte ich schon angesprochen ... vielleicht liegt das ja auch einfach an der falschen Herangehensweise (für gemeinsames Arbeiten).
Da beziehe ich jetzt mal die Vorschläge/Patches von
@f666 für Puma-Boxen mit ein, denn auch diese hätte man erst einmal - und sei es als Branch - integrieren und hinterher entsprechend anpassen können - komischerweise treten solche "Notwendigkeiten" ja auch immer erst dann ans Tageslicht, wenn jemand irgendwelche Patches / PRs vorschlägt. Dann könnten die Freetz-User das jedenfalls inzwischen auch benutzen - ein Beispiel für jemanden, der zwei verschiedene Forks (Puma6 + FHEM von
@DHU) nun selbst zusammenführen müßte, hatten wir hier erst kürzlich in einem anderen Thread.
------------------------------------------------------------------------------------------
Zur Frage, wo die Style-Guides für YourFritz sind ... es brauchte bisher schlicht noch keine, weil es sich - trotz meiner "Suche" nach Mitstreitern - immer noch um ein Ein-Mann-Projekt handelt - das war Freetz ursprünglich eben nicht, auch wenn Du es inzwischen fast zu einem solchen gemacht hast. Wie man auch ohne "contribution guidelines" einem Autoren entsprechende Patches zukommen lassen (und diese dabei auch noch begründen) kann, hat Dir erst diese Woche
@enrik gezeigt ... er hätte sicherlich auch hingehen und das über einen Patch im Freetz-Trunk "dokumentieren" können, denn vermutlich hat er dort sogar noch Schreibrechte.
Auch kann ich mich nicht erinnern, daß ich an irgendwelchen Vorschlägen von anderen wegen Tippfehlern in Kommentaren oder (trailing) Whitespaces am Zeilenende oder wegen des Unterschieds zwischen einer "for"- oder einer "while"-Schleife schon mal (ohne Begründung meinerseits, warum ich das so und nicht anders sehe) herumgeändert hätte ... das sind dann eben doch noch zwei unterschiedliche Paar Schuhe.
Wenn mich jemand, dessen Vorschläge ich aus Style-Gründen ablehne, nach solchen Richtlinien fragt, hat der einen Grund und eine Berechtigung dazu ... ich habe Dich auch nie ohne entsprechenden Anlaß nach solchen vereinbarten Konventionen gefragt und ich hatte bisher nur eine einzige Gelegenheit, einen "pull request" von Dir abzulehnen ... der aber auch deutlich mehr eine Zumutung war und es nicht einmal für nötig hielt, entsprechende Begründungen zu liefern oder (nachvollziehbare) Überlegungen zu irgendwelchen Änderungen mit anderen zu teilen.
Warum ich das so nicht akzeptieren konnte (und wollte), habe ich damals überdeutlich
erklärt (ff.) - wenn auch nicht im GitHub, sondern in Reaktion auf Deine (ebenfalls wieder nachgelieferten) "Begründungen". An Antworten von Dir an dieser Stelle kann ich mich nicht so richtig erinnern.
------------------------------------------------------------------------------------------
Außerdem ist es schon ziemlich schlechter Stil, auf eine Kritik nur noch mit der Frage: "Und ... bist Du denn besser?" zu reagieren - das zeigt irgendwie nicht einmal, ob man solcher Kritik nun eigentlich inhaltlich zustimmt oder nicht. Es ist also eigentlich nur ein weiterer Versuch, von eigentlichen Thema abzulenken.
Ähnliches gilt für den Hinweis hinsichtlich der Konventionen bei der Shell-Programmierung ... es ging - bei unseren Auseinandersetzungen und meinem wiederholten Ansprechen dieser fehlenden Konventionen -
nie um irgendwelchen Shell-Code (auch wenn Du da ebenfalls immer Deinen eigenen Kopf durchsetzen mußt, da habe ich dann halt auf die Zähne gebissen).
Zum Inhalt der Konventionen für Shell-Code schreibe ich jetzt mal nichts, denn dort ist weder etwas zum verwendbaren "Sprachumfang" (wie weit sind denn "bash"-ismen zulässig?) erwähnt, noch sind irgendwelche Konstrukte wie "if [ x"$FOO" = x"0" ]; then" dort thematisiert, wo das "x" eben noch eine zusätzliche "Schutzfunktion" hat, weil es selbst bei passend numerischen Variablen und versehentlich als Vergleich verwendetem "eq"-Operator (ein Fehler, der gerade Shell-Anfängern häufig unterläuft) zu einem Fehler anstelle des falschen Vergleichs führt. Das war sogar mal "anerkannter Coding-Stil" bei der Benutzung von "bash" und "ksh" (siehe z.B. im "ABS Guide") und solange man nicht POSIX-Kompatibilität als Prinzip festlegt (was dann auch wieder "-a" und "-o" in "test"-Kommandos ausschließt), sind das alles "peanuts" oder eben "Geschmackssache", die man ohne weiteres stehen lassen kann, solange man selbst auch in der Lage ist, das zu verstehen und zu interpretieren.
Es muß nicht immer so aussehen, wie es dem eigenen "Schönheitsempfinden" entspricht - ist es syntaktisch und logisch richtig, muß es auch nicht auf Teufel komm raus geändert werden - es sei denn, es gibt entsprechende Festlegungen/Konventionen und dann gehört zu einer "Aufforderung" an den Autoren, das entsprechend anzupassen (was immer noch der erste Schritt vor der eigenen Änderung wäre) lediglich noch der Hinweis auf die vereinbarten(!) Konventionen (samt Link für den Adressaten zum Nachlesen), wenn die eigene "Kritik" tatsächlich vom dortigen Inhalt gedeckt und nicht nur "heiße Luft" ist.
Und einiges in diesen "shell styles" ist auch schlicht fahrlässig oder falsch bzw. viel zu ungenau, wie z.B. diese Festlegung:
Variable Assignments
Variable assignments should not be quoted if unnecessary:
Genau das (nämlich der "unerwartete" Inhalt von nicht korrekt gequoteten Variablen) ist eines der größten Sicherheitsrisiken in der Shell-Programmierung (und immer wieder ein Einfallstor für Angreifer) und so eine Festlegung kann max. hinsichtlich der Variablen gelten, deren Inhalt man tatsächlich zu 100% voraussagen kann und dann sind das i.d.R. keine "echten" Variablen mehr, sondern lediglich "verkleidete" Konstanten oder tatsächlich Werte, bei denen man auf der Basis bereits erfolgter Behandlungen und/oder Tests das Vorhandensein von "whitespaces" innerhalb des Wertes absolut ausschließen kann. An dieser Stelle ist es sogar sinnvoller, die Konvention genau andersherum zu handhaben und immer zu quoten, solange es keinen plausiblen Grund dagegen gibt - das "schleift" sich dann nämlich auch ein und führt (fast automatisch) zu sichereren Variablenzuweisungen.
------------------------------------------------------------------------------------------
Zum Forken ... ja, das wird tatsächlich immer mehr "eine Überlegung wert". Aber selbst so ein Fork würde mich nicht davon abhalten, mich gegen solche "feindlichen Übernahmen" von fremdem Code durch Dich zu positionieren und daraus auch kein Geheimnis zu machen - das löst also das Problem Deines Umgangs mit fremdem Code nicht wirklich.
Danke für den Hinweis auf den Unterschied zwischen GPLv2 und GPLv3 ... nun kannst Du noch raten, warum ich das YourFritz-Repository unter GPLv2 gestellt habe und nicht (at your option) auch unter GPLv3 (die hat auch noch andere Punkte, die für mich nicht passen) und das nur in den entsprechenden (Unter-)Verzeichnissen "aufweiche" in irgendwelchen Header-Zeilen.
Außerdem finde ich es höchst großzügig, daß Du mir die Benutzung von Freetz (wo das Urheberrecht ja wohl auch
nicht nur bei Dir liegt - und mit dem "Einbau" von irgendeinem x-beliebigen Projekt unter GPLv2/GPLv3 in Freetz könntest Du eine solche Ergänzung für Freetz auch gar nicht vereinbaren) nicht verwehren wirst ... auch das zeigt ja irgendwo, als was Du Freetz tatsächlich ansiehst.
Anders als Du ändere ich an meinem (ja ohnehin bereits vorhandenen) Freetz-Fork auch nur das, was
funktionell notwendig ist (und dann auch noch im Stil des jeweiligen originalen Autors irgendeiner anzupassenden Software) ...
ich käme jedenfalls nie auf die Idee, einen Patch für einen Schreibfehler in einem Kommentar zu erstellen; dafür wäre mir meine eigene Zeit viel zu schade (und die "Besserwisserei" viel zu offensichtlich und vordergründig, die kann dem Gegenüber ja nur unangenehm aufstoßen).
------------------------------------------------------------------------------------------
EDIT:
Um auch noch auf den Zusatz unter #46 einzugehen, den ich erst später gesehen habe ... wenn Du den Unterschied zwischen einem Fork eines Projekts, dem anschließenden Branch und den darin vorgenommenen Änderungen, die dann als Änderungsvorschlag (oder "Pull-Request") wieder an den Upstream übermittelt werden, und Deinem Vorgehen mit dem direkten Einchecken von Patches
für alle Freetz-Benutzer tatsächlich nicht erkennen kannst, ist deutlich mehr im Argen, als ich eigentlich vermutet hätte - dann ist Dir nämlich die "normale Arbeitsweise" bei der Verwendung von "git" (bzw. GitHub als einem möglichen Git-Hoster) tatsächlich nicht bekannt.
Das muß(te) man zwar aufgrund der Tatsache, daß Du auch zusammenhängende Patches nie als Branch vorbereitest und dann erst eincheckst, wenn das wirklich komplett ist, bereits annehmen, aber diese (indirekte) Bestätigung kommt für mich dann doch schon ziemlich überraschend. Dich interessiert auch gar nicht, was das dann für Auswirkungen auf andere Nutzer hat ... bei Dir weiß man nie, wann ein "intermediate goal" erreicht ist und es sich lohnt, seinen Fork mit dem Trunk zu synchronisieren oder ob da nicht in 5 Minuten der nächste Patch kommt.
Das normale Vorgehen wäre es eben, daß man zusammenhängende Änderungen erst mal in einem gesonderten Branch vorbereitet und diesen dann - als Ganzes - mit dem Master mischt. Dann stellt sich auch die Frage "Kommt da in 5 Minuten die nächste Änderung?" nicht wirklich ... mit dem Merge ist der Branch dann erledigt.
Mal vollkommen davon abgesehen, daß Du eben gerade keine Pull-Requests daraus machst bzw. den Hauptkritikpunkt, daß Du auf jedwede plausible Begründung für (oft unmotiviert anmutende) Änderungen von Deiner Seite verzichtest und das deshalb den Anschein von Willkür hat, hier erneut einfach ausblendest ... ebenso den gravierendsten Unterschied, obwohl Du ihn doch selbst so schön formuliert hast:
hast es auch erst in deinem Fork committet und erst danach mich informiert bzw. den Pull-Request gestellt.
Der Freetz-Trunk ist eben nicht mit Deinem Fork von Freetz zu verwechseln - auch wenn Du Dich immer wieder so verhältst.
Das normale Vorgehen wäre es (bei einem gemeinsamen Projekt und wenn "subversion" das nicht leisten kann, ist das erst recht ein Grund für den Umstieg auf "git"), daß auch Du einen Fork des Repos hast, dort Deine Änderungen vornimmst (solange es nicht nur kleinere Korrekturen sind, sondern "new features" oder tiefgreifende Änderungen) und sie dann als Ganzes in das Projekt-Repository überführst.
Vor der Frage "Kommt da in 5 Minuten die nächste Änderung?" stehen nämlich auch nicht nur die Leute mit eigenen Forks des Freetz-Projektes, sondern genauso "normale User", die auch nie genau wissen, wann denn nun der nächste "version bump" für weitere Pakete erfolgt und ob sie lieber noch eine Stunde warten sollten, damit sie wenigstens den Stand auschecken können, der die nächsten 24 Stunden halbwegs aktuell ist.
Von dem Moment an, wo Du solche Sachen eincheckst, müssen eben alle Freetz-Benutzer, die den Trunk danach klonen (und sie haben gar keine andere Chance, weil der Trunk sowohl "Entwicklerzweig" als auch der einzige überhaupt funktionierende Branch in Freetz ist), mit Deinen Änderungen leben ... und daß diese teilweise nicht mal bis zum Ende von Dir durchdacht wurden, hast Du einige Beiträge weiter vorne selbst als "Entschuldigung" vorgebracht - auch da wieder mit zuwenig Zeit (für solche Überlegungen) begründet.
Wenn
ich einen Branch im
meinem Freetz-Fork mache, dort Änderungen vornehme und diese als PR in den Freetz-Master einfließen lassen will, geht das auch nie (aber definitiv nie) um irgendwelche Änderungen um der Änderung willen ... und ich schreibe immer dazu,
warum es diese Änderungen nach meiner Ansicht braucht (und diese meine Änderungen an meinem Fork gelten eben auch nicht automatisch für alle Freetz-User, die ab diesem Zeitpunkt das Repository klonen).
Das genau machst Du eben nicht (irgendwas zu begründen) ... wenn es tatsächlich funktionelle Änderungen braucht, würden sich auch die wenigsten Autoren dagegen wehren (es sei denn, sie haben gute Gründe dafür und selbst diese interessieren Dich aber in der Regel nicht im Geringsten) - mal ganz abgesehen davon, daß "feel free to provide a patch" ja auch eine gerne genommene Reaktion auf Änderungsvorschläge (von Freetz-Nutzern) ist und wie das funktionieren soll, ohne einen Branch und einen Patch aus dem Ergebnis so eines Branches, verstehen wohl auch die wenigsten.
).
