Das muß Dich ja nicht davon abhalten, so etwas dann anderen auf GitHub zur Verfügung zu stellen (da kann Dir auch niemand die "Schreibrechte" verwehren) ... daß es mit SVN oder Patches hier im Forum nicht das Gelbe vom Ei ist (auch bei deren "Handling" durch die handelnden Personen - und nun ist auch der Trac noch tot, wo man das ansonsten noch hinterlegen konnte, damit es nicht direkt wieder unterging), ist unbestritten.
Aber schau Dir den Support für die Puma-Boxen an oder auch den Fork von
@DHU, in dem FHEM immer noch unterstützt ist ... niemand mußte die erst mit dem Freetz-Trunk mergen, um deren Angebot wahrnehmen zu können. Daß die Puma-Anpassungen es dann erst nach langer Zeit und heftigen Änderungen in den Trunk geschafft haben, steht ja auf einem anderen Blatt.
Ansonsten reicht es schon, wenn der jeweilige "Besitzer" des Forks seinerseits das Rebase auf den Trunk macht (und notfalls kann man ihn ja auch darauf ansprechen, daß man statt freetz/freetz lieber seinen Fork verwenden würde, der aber gerade nicht aktuell ist im Vergleich zum Trunk und ob er das nicht netterweise ändern könnte) ... bei wichtigen Änderungen zumindest, denn beim "klein-klein" ist mir das tatsächlich auch zu viel, zumal ich das noch alles in Branches sortiert habe, damit man daraus tatsächlich auch einen Pull-Request machen könnte und dann auch jeder dieser Branches wieder sein eigenes "rebase" braucht - am Ende würde jede Änderung im Trunk in meinen Fork mit der Anzahl der offenen Branches multipliziert, wenn ich das tatsächlich immer sofort machen wollte.
Aber dann checkt der Interessierte eben nicht "freetz/freetz" als Upstream aus, sondern den Fork und dafür muß man von "git" und/oder GitHub nicht wirklich etwas verstehen und auch keine Branches selbst mergen oder Konflikte beheben können. Und selbst wenn er das müßte (also "mischen können") ... solange sich ein fremder Branch mit einer Zeile mischen läßt, ist das durchaus "zumutbar" (man ist ja dann an den Änderungen interessiert und da ist es normal, wenn man dafür ein paar Anstrengungen unternehmen muß) - erst bei "merge conflicts" würde es dann "eklig".
Wobei das für "einzelne Patches" anstelle eines Forks oder verschiedener Branches ja auch nicht wirklich anders sein
kann (ich verstehe Deinen Text so, daß Du das so verwaltest) ... ändert sich im Upstream etwas (und die jüngsten Änderungen an allen möglichen Symbolen haben ja gerne auch Auswirkungen auf (private) Pakete, wenn solche Symbole dort verwendet werden), muß man dann eben die Patches anpassen. Das ist auch nichts anderes, als ein "rebase" für den eigenen Fork.
Und wenn Du tatsächlich ablehnst, die thematisch zusammengehörenden Änderungen in "feature branches" zu verpacken (ein Auslesen und Speichern von Meßwerten der FRITZ!DECT-Geräte für die spätere Visualisierung wäre ja sicherlich ein solcher), kann es bei der Sourcecode-Verwaltung bei Dir ja nicht viel anders aussehen als im Freetz-Trunk, wo auch jeder Furz direkt in der Version landet, die für die Benutzer gedacht ist ... die Feststellung, daß es sich beim Trunk um die "Entwicklerversion" handeln würde (und man da auch mit Problemen rechnen muß), ist ja am Ende nur ein recht bequemes Mäntelchen über der Tatsache, daß es eben schon lange kein sinnvoll verwendbares Release für aktuelle Boxen mehr gibt und die Leute zwangsweise den Trunk nehmen oder auf Freetz verzichten müssen. Es hat schon seine Gründe, warum Neulinge immer wieder mit Freetz 2.0 starten wollen ... weil ein Projekt, das nur noch aus der aktuellen Entwicklerversion besteht, eben schon recht ungewöhnlich ist und viele lieber eine echte "stable"-Version hätten, als das Risiko einzugehen, daß es am Ende dann doch nicht klappt und sie gar nicht so richtig wissen, ob das nun an ihnen oder an der "Qualität" der Entwicklerversion liegt. Gerade für Anfänger ist das natürlich ein ziemliches Brett ... da wäre eine "garantiert lauffähige Version" (wie man es von einer "stable" erwarten darf) dann schon der bessere "Einstieg".
-----------------------------------------------------------------------------------------------------------
Das mit dem "single branch" hat Vorteile (weil Changes zur Fehlerkorrektur unmittelbar verfügbar sind) und es hat auch Nachteile (weil alle Changes unmittelbar verfügbar sind und auch für alle wirken, selbst wenn sie "compile-tested only" sind) - solange es sich fast nur noch um die "Verwaltung" des bisherigen Zustands handelt, bei dem ältere Versionen von neueren abgelöst werden, ist das aber auch egal.
Spannend (und störend für Freetz-Benutzer) wird dieses Vorgehen erst dann, wenn man wirklich Neues einbauen will und das tiefgreifende Änderungen an Vorhandenem erfordert, ohne daß man das Ende schon absehen kann (das geht nun mal nur, wenn das kein wirklich großer Sprung ist, denn das hat mit der Fähigkeit zur "Voraussicht" auch nur bedingt zu tun) ... da muß dann auch mal der "Irrtum" möglich sein, der sich eben nicht gleich negativ auf alle anderen Benutzer auswirkt und wo sich ein solcher dann auch bewußt dafür oder dagegen entscheiden kann, ob er ein neues Feature nun einbauen (und damit dann auch testen) will oder nicht.
-----------------------------------------------------------------------------------------------------------
Ja, ich habe auch genug Konflikte an dieser Stelle ausgefochten ... das hindert mich aber nicht daran, meine Ergebnisse (oder auch die Ideen bzw. "Prinziplösungen", wobei ich da tatsächlich deutlich zurückhaltender geworden bin, weil ich die meisten schon gerne selbst umsetzen möchte) dann anderen auch zur Verfügung zu stellen.
Was bringt es, wenn ich die nur bei mir herumliegen habe und andere sie nicht nutzen können? Wir reden hier ja immer noch von kompletten und fertigen Lösungen (so habe ich Dich verstanden) und nicht von irgendwelchen "Beispielen", wie man etwas lösen könnte (oder auch nicht) und wo eine "Veröffentlichung" dann eher für Verwirrung sorgen könnte, als daß sie hilfreich wäre.
So, wie Du das im Moment machst, erinnert es mich etwas an die "Gründerszene", wo mit (durchaus guten) Ideen und Photoshop dann erst mal das passende "Bild" zur Lösung gebaut wird, weil sich die Leute (aka potentiellen Investoren) das dann viel besser vorstellen können. Da weiß kein Aas, ob das Versprochene überhaupt am Ende einzulösen ist und ob die Idee funktioniert ... aber "sehen" kann man trotzdem schon mal etwas, bevor man sein Kapital (das heißt ja nicht umsonst "Risikokapital") investiert. Nur wenn das dann mal "vorzuzeigen" wäre in Funktion, ist immer irgendetwas anderes, was das gerade verhindert ... aber das soll ja selbst richtig großen Firmen bei ihren Präsentationen auf offener Bühne schon mal passiert sein.
