Momentan sind die Sachen halt so wie ich sie benutze und gut finde.
Genau das habe ich ja "vermitteln" wollen ... so sieht das eben auch aus (nicht falsch verstehen, ist zwar auch "kritikwürdig", aber zunächst mal nur eine Feststellung). Das ist eben nicht "ein neues Freetz" (oder auch nur ein anderes), sondern das, was
@cuma "gut findet".
Ich hatte Deine Absichten in #1 aber so verstanden, daß Du mit anderen
gemeinsam etwas auf die Beine stellen willst - da ist das dann kein wirklich guter Start. Wenn Du selbst der Ansicht bist, irgendetwas wäre "noch nicht fertig" (so kann man das oben Zitierte ja auch verstehen, wenn das nur "momentan" ist), dann schreibe das doch einfach
nicht in das Projekt-Repository.
Wenn das jemand auch in diesem "unfertigen" Zustand verwenden möchte, kann er sich entweder die Patches aus Deinem PR für diese Änderungen (den kann man auch nachträglich korrigieren und "verfeinern") zusammenstellen oder - wenn Du keinen PR für eine Änderung gemacht hast - auch direkt den passenden Branch aus Deinem Repo in den eigenen Checkout mischen (zusätzliches "remote" definieren, fetchen (wenn man erst "mal gucken" will) und Branch pullen).
Das geht aber natürlich nur dann, wenn Du selbst in Deinem Repo entsprechende "Ordnung" hältst und es für die Änderungen auch separate Branches gibt, die der Interessent mischen könnte - dafür darf das dann eben nicht alles nur "ein Brei von Änderungen" sein, die teilweise gar nichts miteinander zu tun haben. Selbst wenn man davon ausgeht, daß der Interessent an den Änderungen ja auch "cherry-picking" betreiben könnte, braucht der dazu eben auch wieder sinnvolle und verständliche Kommentare - schon in der "Betreff"-Zeile eines Commits - oder er muß sich (parallel zum Prozess des "git cherry-pick") erst noch gesondert durch die einzelnen Commits wühlen.
Dafür ist das "cherry-pick" aber eigentlich auch nicht gedacht ... dessen Sinn ist es eher, aus einem anderen Branch nur die Änderungen herauszuziehen, die man weiterhin braucht (sagt ja schon der Name) - normalerweise wirft man den Rest danach dann weg (wenn man selbst das "cherry-picking" in eigenen Commits betreibt) oder ein Projekt-Maintainer verwendet solches "cherry-picking", wenn er von einem Vorschlag nur einzelne Commits übernehmen will und nicht alles (aber auch der macht das dann eben nur einmal).
Als Strategie "Hier ist der große Topf mit allen Änderungen und da kann/soll sich jeder (Benutzer) per 'cherry-pick' das heraussuchen, was er will." ist das eher gewöhnungsbedürftig und verlagert irgendwie die "eigentliche Arbeit" des Autoren (der das auch nur einmal machen müßte, wenn er gleich von Beginn an "die Ordnung hält") auf den Interessenten (aka Freetz-Benutzer), der auch gleich noch mehrfach existiert (so das Projekt angenommen und genutzt wird) und wo das dann am Ende auch mehrfache Arbeit (zwar bei jedem nur einmal, aber eben auch bei jedem einmal und nicht nur beim "Autoren") bedeutet. Auch deshalb sollte man sich vorher die Arbeitsweise gut überlegen.
Deshalb macht es auch keinen Sinn, wenn wir uns jetzt über einzelne Patches "streiten" ... ich verstehe aber auch nicht so ganz, was Du mir mit "selber machen" genau sagen willst. Das klingt ja fast so, als wärst Du der Meinung, daß ich "nur rede" (und kritisiere) und ansonsten eher nichts zu Freetz beitrage - wenn ich hier "schlau rede" (oder schreibe), versuche ich das auch immer mit einer Begründung zu machen, warum man das besser so machen sollte (oder eben nicht so, wie ich es "kritisiere"). Ich hoffe zumindest, daß meine "Begründungen" so weit verständlich sind, daß sie die angesprochenen Probleme (auch wenn diese "nur potentiell" sein könnten bei manchen Punkten) erklären und deutlich machen, warum ich dieser Ansicht bin und nicht nur festhalten, daß ich etwas anders sehe.
Wenn Du unter diesem "selber machen" aber verstehen solltest, daß andere "das Aufräumen" übernehmen sollten bzw. daß irgendein anderer danach noch an Deinen Änderungen "herumdoktern" sollte, bis diese zur (für "freetz-ng" bisher für mich auch eher unklaren) Philosophie passen (denn Du hast ja in #1 nicht nur "Developer", die sich Deine Änderungen dann wieder selbst so zurechtbiegen können, daß sie "zu ihnen passen", zur Nutzung von "freetz-ng" eingeladen (nicht mit "Mitarbeit" zu verwechseln), sondern auch "alle anderen", die das benutzen wollen), dann sind wir wieder bei meiner Feststellung aus #2 ... das, was Du hier anbietest (was ich prinzipiell sogar gut finde, denn ich habe Dich dazu ja auch zuvor schon mehrfach aufgefordert, z.B. hier:
https://www.ip-phone-forum.de/threads/rrdstats-und-smart-home.301623/#post-2308002), ist im Moment ein "Gemischtwarenladen", bei dem dann auch wieder nur Du selbst den Durchblick hast bzw. hoffentlich bewahren kannst.
Wenn man davon ausgeht, daß dieses "freetz-ng"-Repo eine neue Basis
für andere sein soll, die ihrerseits dieses Repo forken und daran Änderungen vornehmen sollen, dann sollte das eben tatsächlich auch "das neue Freetz" sein (was Du unter "ng" nun genau verstehen willst, ist ja auch noch als "Frage" offen aus einem vorhergehenden Beitrag), was sich in seinem Inhalt, dem Umfang und den Konfigurationsmöglichkeiten
an die potentiellen Benutzer richtet und nicht das "cuma"-Repo (oder auch "fda77" oder wie auch immer man sich/das Repo nennt).
Wenn Du schon selbst der Ansicht bist, daß da irgendwo noch eine Einstellmöglichkeit fehlen könnte, damit sich der Freetz-Benutzer selbst aussuchen kann, ob er eine Änderung haben will oder nicht, dann darf man das eben nicht direkt in das Projekt-Repo schreiben ... da gehört es erst dann hin, wenn "Einigkeit" darüber besteht (gesetzt den Fall, es gibt mehrere handelnde Personen und die stimmen sich auch tatsächlich ab bzw. sehen sich solche Änderungen erst einmal (gemeinsam) an, bevor diese direkt in das Projekt-Repo einfließen), daß es jetzt "fertig" wäre. Ein Projekt-Repository ist nun mal kein "privater Spielplatz" und definitiv nicht der richtige Platz, um "unfertige" Änderungen bereitzuhalten (selbst wenn das beim Freetz-Trunk in Subversion bisher so war) - dafür ist das eigene Repository zuständig.
Das kann man zusätzlich haben (ja, das sollte bzw. muß man sogar zusätzlich haben) ... aber wenn man Daten aus dem eigenen Repository in so ein Repository für ein
ganzes Projekt übernimmt, dann sollte man eben auch die thematisch zusammengehörenden Commits aus dem eigenen Repository in einen (thematischen) Pull-Request packen, diesen vernünftig dokumentieren und dann kann man den (ggf. sogar "squashed", wenn es Sinn macht, mehrere Commits (am eigenen Repo, die sich bei der Arbeit an einem Problem eigentlich immer ergeben, wenn man nicht zu den Genies gehört, die immer alles auf Anhieb richtig kodieren) zu einem gemeinsamen für das Projekt zusammenzufassen) in das Projekt übernehmen.
[ BTW: Was ein "Push-Request" ist, weiß ich gar nicht bzw. beim "Pushen" der Änderungen eines anderen Repos in das eigene, sehe ich nirgendwo einen "Request", der diesen Namen irgendwie verdient.
"push" ist aktives Ändern eines "entfernten" Repos (z.B. das Veröffentlichen eines lokalen Standes im "origin"-Repo, was i.d.R. das private Repository mit dem Fork des Projekts sein wird), "pull" ist das Laden von Änderungen eines anderen Repos in das lokale - beides sind Aktionen, die jeder für das eigene Repository ausführen kann. Ein "pull request" ist dann die Aufforderung des Autoren einer Änderung an den Maintainer eines (i.d.R. fremden) Projekt-Repos, einen "Satz von Änderungen" aus einem Branch des eigenen zu übernehmen bzw. das zumindest in Erwägung zu ziehen - also ein "Angebot", eine vorhandene (und bestenfalls auch getestete) Änderung eines anderen "in das Projekt" zu übernehmen. Das mal als "Begriffsbestimmung" für diejenigen (Mit-)Leser, die mit den hier herumschwirrenden Begriffen nichts anfangen können. ]
Anschließend kann dann jeder in der Historie der geänderten Dateien jederzeit "nachschlagen", was da wann, von wem und mit welcher Absicht bzw. in welchem Zusammenhang geändert wurde - macht man den "code review" mit den GitHub-Mitteln, kann man auch das (im dann bereits geschlossenen Pull-Request) noch jederzeit nachlesen, was es da an (am besten gemeinsamen) Überlegungen gab und im besten Falle, warum das genau so gelöst wurde, wie es am Ende in das Projekt übernommen wurde und welche Alternativen diskutiert, aber verworfen wurden.
Das Problem mit so einem eigenen Repository und der "verteilten Arbeit" ist es aber auch, daß man das eben "gleich richtig" machen muß - mit Ausnahme von "rebase"-Aktionen schreiben nämlich alle künftigen Änderungen den aktuellen Stand fort (das Prinzip sei hier jetzt nicht erläutert, es hat mit dem "Hash-Baum" zu tun, der von "git" verwendet wird - das hat entfernte Ähnlichkeit mit einer Blockchain) und spätestens, wenn es bei "nachträglichen Korrekturen" dann zwei unabhängige Änderungen an derselben Datei gibt, hat man den schönsten "merge conflict", den man dann wieder (mit hohem Aufwand) von Hand auflösen muß ... und ich weiß, wovon ich da rede. (Nebenbei bemerkt: Auch für das nachträgliche Ändern von Kommentaren kann man ein Rebase verwenden (
https://help.github.com/articles/about-git-rebase/), ein "nun ist's zu spät für sinnvolle Kommentare" gibt es also eigentlich nicht wirklich.)
Der endlose Aufwand, den ich mit meinem Freetz-Fork bei einem Rebase auf das originale Freetz-Repo jedesmal zu betreiben habe, ist auch nur deshalb halbwegs zu bewerkstelligen, weil ich eben die einzelnen Änderungen (ggü. dem Stand, an dem der Fork nach dem letzten Rebase ansetzt) in separaten Branches verwalte (damit kann man die eben auch einzeln als PR vorschlagen und muß das nicht alles in einen Karton schmeißen, den man an die Straße stellt und wo sich jeder das rausnehmen soll, was er will) und damit diese Branches jedesmal separat mittels "rebase" auf den Stand des Ursprungs bringen kann, ohne mir zuviele Konflikte einzufangen. Diese treten aber natürlich trotzdem auf, wenn mal wieder im Basis-Repo eine Datei angefaßt wird, die auch in einem meiner Branches erhebliche Änderungen erfährt.
=========================================================
Wenn Dein Trac-Server über das git-Repo diese Arbeitsweise (mit den bereits einmal erwähnten "feature branches") nicht unterstützt (ob das so ist, weiß ich nicht), dann solltest Du vielleicht doch überlegen, zu einem anderen GUI zu wechseln ... dann würde das nämlich schlicht nicht für die Verwaltung eines git-Repos (und die dabei als "best practice" etablierten Arbeitsweisen - auch das muß man ja nur nachlesen, denn schon "Generationen von Entwicklern" befassen sich ja auch mit "git" seit 2005) passen - was angesichts der "Abstammung" (Trac ist eben nicht speziell für "git" und die dort vorhandenen Möglichkeiten der verteilten SCM-Verwaltung entwickelt und bindet "git" nur als ein Backend von mehreren möglichen ein) auch nicht allzu überraschend wäre.
Und zu einer
gemeinsamen Arbeit an einem Projekt gehört eben auch ein "review system", in dem man an vorgeschlagenen Änderungen
gemeinsam(!) "herumdoktern" kann,
bevor man sie in das Projekt übernimmt ... das wird wohl nur schwer etwas werden, wenn die einen die GitHub-Oberfläche dafür verwenden (und die kann das problemlos und gut), die nächsten einen (privaten) Trac-Server und der Rest meinetwegen "gerrit" (
https://www.gerritcodereview.com/).
Ich weiß zwar nicht, wieweit die am Ende tatsächlich "zusammenarbeiten" können, aber m.W. sind die Anmerkungen bei GitHub-Reviews zwar per API abzurufen, aber das muß vermutlich auch erst mal mit entsprechenden Zusatzpaketen eingerichtet und konfiguriert werden. Da ist es dann (in meinen Augen) wieder schlauer, man nimmt einfach etwas, was ohnehin bereits existiert und mit dem sich die Benutzer (zumindest einige) bereits auskennen - und beißt notfalls auch mal die Zähne zusammen und läßt eigene "Gewohnheiten" zugunsten der reibungsloseren Zusammenarbeit fallen.
Betrachtet man die Anzahl der Leute, die zum Subversion-Repository etwas beigetragen haben in der jüngeren Vergangenheit (meinetwegen auch als "diff"-File in einem Trac-Ticket) und vergleicht diese Zahl mit der Anzahl der Forks (des originalen Freetz-Projekts) und den daraus abgeleiteten Pull-Requests für das Projekt-Repo, kann man zumindest mal festhalten, daß die Mehrzahl der "neuen Entwicklungen" ohnehin von Leuten kamen, die eben "git" benutzen.
Wenn man also
für diese ein neues Projekt auf die Beine stellen will (und die wären ja vermutlich die ersten, die man "gewinnen" müßte für eine Zusammenarbeit), dann sollte man vielleicht auch bei den Arbeitsabläufen auf etwas setzen, was diese Personen (offensichtlich) schon kennen und nicht - weil es einige "Alte" so wollen und nicht anders kennen - wieder in den alten Trott verfallen und all diese potentiellen Mitstreiter jetzt "dazu zwingen", ihre (etablierte) Arbeitsweise an alte und ihnen i.d.R. eher fremde Riten anzupassen. Das würde vielleicht noch einen Sinn ergeben, wenn die überwiegende Mehrheit der "Mitstreiter" so etwas begrüßt oder wenn diese Mehrheit aus "Alten" besteht, die das ohnehin nicht anders kennen. Ist das aber eine (deutliche) Minderheit, wäre das irgendwie das Wedeln des Schwanzes mit dem Hund.
Wer nun aber etwas Neues aufsetzen will und dafür bei anderen (die erkennbar ja in letzter Zeit ohnehin schon GitHub (bzw. "git") benutzt haben, u.a. ja auch, weil das andere Zeug gar nicht (verläßlich) lief) um Mitarbeit buhlen will (oder muß), der sollte sich eben auch mal die "numerischen Verhältnisse" ansehen und dann ggf. eher seine eigenen Vorlieben "überarbeiten", so daß sie zu denjenigen passen, die man zur Mitarbeit "gewinnen" will.
Geht man hier jetzt hin und richtet das so ein, daß auch dieses eher den eigenen Vorlieben als den (erkennbaren) Gewohnheiten anderer entspricht, baut man natürlich auch für diese potentiellen Mitstreiter zusätzliche Hürden auf und muß sich erst recht nicht wundern, wenn die Resonanz eher gering ausfällt. Daher sollte man so einen "strategischen Fehler" vielleicht gar nicht erst machen ... auch wenn das ggf. heißt, daß man sich selbst "auf den Hosenboden setzt" und sich neues Wissen (und neue Arbeitsabläufe) aneignet.
Und noch mal ... auch das nicht mißverstehen. Ich teile zwar Deine Ziele (und Vorbehalte) nicht, aber das sind trotzdem Aspekte, die Du vielleicht berücksichtigen solltest. Denn wenn ich mir die Liste der Leute ansehe, die Du nach der Aussage in #1 eingeladen hast, sind das ja eher alles Personen (sogar inkl.
@er13), die einen GitHub-Account haben und auch ihre Beiträge zu Freetz über genau diese Plattform "eingereicht" haben (hier zählt dann
@er13 nicht dazu).
Da jetzt festzustellen, daß Dir persönlich GitHub eher nicht zusagt (hoffentlich nur, weil Du es noch nicht gut genug kennst) und daraus andere "Arbeitsabläufe" abzuleiten, könnte als Idee ganz schnell nach hinten losgehen, weil sich die Leute ggf. fragen könnten, warum sie (ab zweien dann schon wieder die Mehrheit) sich nach Dir und Deinen Vorlieben richten sollten und vielleicht sogar ihrerseits erst noch etwas lernen müssen, was sie ansonsten eher nicht verwenden können (zumindest nicht mehr heutzutage, denn wer den "Kampf" zwischen Subversion und "git" gewonnen hat, dürfte einigermaßen unstrittig sein).
Zum "Leader sein" (und Du willst hier ja offensichtlich vorangehen) gehört es eben nicht nur, die Richtung (nach den eigenen Vorlieben) vorzugeben, sondern auch die Leute mitzunehmen und einen Interessenausgleich zu schaffen bzw. Kompromisse zu vermitteln.
