Ich bin zwar auch für ein Zusammenführen von diversen Repos, aber mit dem, was hier wieder als "flache Hierarchie" bei den Änderungen zu sehen ist (alles in einen einzelnen Branch, den man entweder "haben" will oder nicht - ansonsten muß man selbst das "cherry-picking" machen und man kann dabei nicht mal anhand der Commits (und deren Messages) ohne weiteres erkennen, wofür so ein Patch nun gut sein soll und ob man den braucht oder nicht), kann ich persönlich einfach nichts anfangen - daher hänge ich mich hier auch nicht dran.
Nach meiner Ansicht (da war aber schon mit
@er13 keine Einigkeit zu erzielen) gehören die Änderungen für ein (bzw. jedes) Paket in einen separaten Branch (also das Prinzip der "
feature branches" auf die Pakete in Freetz angewendet) und der kann dann mit dem Master gemischt werden oder eben auch nicht. Wer will, kann sich dann auch seinen eigenen Stand aus der "Basis" und den angebotenen Paketen zusammenmischen und den anstelle eines "masters" verwenden.
Sich hier jede einzelne Datei anzusehen (36 Commits mit 73 geänderten Dateien sind es im Moment, die da auf einen Schlag und in einem Branch vorgenommen wurden), um deren Änderungen nachzuvollziehen, bringt mir persönlich nichts (kostet nur Zeit), weil die Mehrzahl meiner Änderungen eben auf Abwandlungen von bereits vorhandenen Freetz-Paketen beruht (z.B. der Einbau der Unterstützung des RSA-Keys der Box in "dropbear") und ich daher bei jeder Änderung erst mal abchecken muß, ob sich diese mit meinen eigenen "beißt" oder nicht. Zumal ja
@cuma oft genug bei neuen Sachen von mir festgestellt hat, daß das bei ihm schon lange so laufen würde ... also ist die Wahrscheinlichkeit von Inkompatibilitäten und damit das "Konfliktpotenzial" da ja besonders hoch und ich müßte sehr genau hinschauen.
======================================================================
Ich verstehe im Moment auch noch nicht so richtig, was ein "freetz-ng" jetzt bringen sollte (außer man WILL den gewaltsamen Fork, was auch ein legitimes Ziel ist, aber das kann man dann ja auch deutlich ansagen) oder warum es erforderlich sein sollte ... wenn mein (persönlicher) Eindruck nicht täuscht (ich hatte Oliver und Eugene parallel per E-Mail angeschrieben, nur Oliver hat geantwortet), daß
@er13 auch keinen Bock mehr hat (von
@Whoopie wurde das ja "offiziell" angesagt), dann müssen/können/sollten eben andere die entsprechenden Schreibrechte für das "originale Projekt" erhalten. Zu dem kann man dann auch wieder mit PRs entsprechend beitragen ... im Moment fehlt halt jemand, der das in das "offizielle Repo" integriert.
Ich selbst habe zugegebenermaßen jetzt auch keinen Bock, meinen Fork auf die Basis irgendeines anderen (Forks) umzustellen - zumal eben die automatischen Vorgänge bei PRs am besten dann funktionieren, wenn sie gegen das originale Repo arbeiten können (also das, von dem der Fork auch stammt) und irgendwelche Wege (z.B. per E-Mail) für den "Austausch" von PRs zwischen zwei Repos eher nervig (und für mich auch unnötiger Aufwand) sind. Daher wäre so ein "Umschalten" auf einen neuen Fork in meinen Augen ein "point of no-return" ... und das ist mir persönlich noch zu früh, hier unmittelbar die Flinte ins Korn zu werfen.
Sollte ich selbst jemals den Übergang zu einem anderen "Basis-Projekt" vollziehen mit meinem Fork, dann wäre das auch eines, was die "Grenzen" zwischen den vier Teilen, die das Freetz-Projekt in meinen Augen viel zu sehr miteinander verquickt (das wären für mich
- Toolchain (Cross-Compiler, C-Library und Kernel)
- Paketverwaltung
- Firmware-Generator (fwmod)
- Freetz-Mod (GUI + einige "framework files" für die Infrastruktur beim Starten/Stoppen von Diensten)
), einhält und das auch entsprechend aufteilt. Das Ergebnis wäre es dann, daß ein "version bump" für eine AVM-Firmware eben nur den "Firmware-Generator" tangiert (solange sich dabei nichts ändert, was Auswirkungen auf die Toolchain hätte) und eine neue Version für irgendein Zusatzpaket nur eine Änderung in der Paketverwaltung nach sich zieht.
Findet man dann noch einen Mechanismus, der bei der Paketverwaltung eine "selektive Auswahl" ermöglicht und nicht mehr - wie bisher - alle Pakete auf einmal enthält (im Moment gibt es 276 Pakete, dazu kommen noch "linux", "libs" und "mod", die weitere Abhängigkeiten haben), kann man auch die eigenen Aktivitäten beim Neuerstellen eines Images auf das Wesentliche beschränken ... wenn ich das Paket "lightppd" gar nicht im Image habe, interessiert es mich auch nicht, wenn sich dessen Version ändert und wenn ich mich nur (per E-Mail) über Änderungen an den von mir verwendeten Paketen informieren lassen kann (dafür gibt es ja Mechanismen in GitHub), dann ist es auch deutlich leichter für mich als "Freetz-Benutzer", den Überblick über die Änderungen zu wahren.
Eine solche "Umorganisation" wäre dann etwas, was in meinen Augen eher den Zusatz "-ng" (gemeinhin ja als "next generation" (oder "new gen") verstanden) verdient hat ... ein "weiter so", nur eben in einer anderen "Organisation", schreibt auch nur den Status Quo weiter fort - mit allen derzeit auch schon vorhandenen Unzulänglichkeiten.
======================================================================
Bislang hab ich bereits eingeladen aus den Bereichen: cable, fhem, toolchain, 2x bump und mich
Das ist z.B. ein Satz, den ich nicht mal im Ansatz verstehe bzw. wo es so viele "Interpretationsmöglichkeiten" für mich gibt, daß ich damit nichts anfangen kann. Was ist denn "2x bump" und warum hast Du den (oder die) eingeladen? Wer ist denn "mich" und warum mußte der (wenn das "Du" sein solltest, also
@cuma) eingeladen werden und vor allem, wofür galt denn diese Einladung?
Gesetzt den Fall,
@er13 macht nicht mehr weiter im "originalen Projekt" ... wärst Du denn daran interessiert, dort wieder Schreibrechte zu erhalten und dann - in Abstimmung mit anderen Mitstreitern - an Freetz weiterzuarbeiten und zwar in einer Richtung, die "abgestimmt" ist und im (unterstellten) Interesse der meisten (verbliebenen) Freetz-Benutzer wäre? Angesichts einiger Diskussionen in jüngster Zeit (u.a. zum Boot-Manager) gäbe es ja offenbar auch zwischen uns erhebliche Meinungsverschiedenheiten und wenn man diese nicht zuvor in einer (sachlichen) Diskussion ausräumt, endet das vielleicht doch wieder in einem "commit war".
So etwas bringt aber niemandem etwas und daher ist dann vielleicht eine strikte Trennung von Verantwortlichkeiten (z:B. wie bei der Kernel-Entwicklung, wo auch nicht einfach das Storage-Subsystem in den Netzwerk-Code eingreifen darf) notwendig, bei der sich jeder "um seins" kümmert, aber trotzdem die "große Linie" der anderen mit unterstützt - heißt konkret, auf die "Angebote" von anderen zurückgreift, wo es machbar ist, anstatt sein eigenes Süppchen zu kochen bzw. unbedingt seine eigene Implementierung hinlegen zu müssen, ohne genau darlegen zu können, warum das so sein muß bzw. welche Vorteile diese nun gegenüber etwas anderem hätte.
Wenn
@er13 nicht weitermachen sollte, wäre ich jedenfalls auch an Schreibrechten interessiert (allerdings im originalen Projekt und nicht in "-ng"), wobei ich mein Hauptaugenmerk eben auf die Toolchain legen würde, denn die kann ich für YourFritz ganz gut brauchen. Das wäre dann auch der Teil, für den ich mich bereiterklären würde, die "Wartung" zu übernehmen. Ansonsten brauche ich noch ein paar (wenige) Pakete und da läge mein Fokus (wie bei einigen Änderungen, die dann keinen Einzug in das "offzielle" Freetz-Repo gefunden haben und von mir in getrennten Branches in meinem Fork verwaltet werden) auch darauf, daß diese Pakete "dual use" sind und sich sowohl in einem Freetz-Image als auch in anderen Umgebungen verwenden lassen.
Der "Rest" (viele, viele Pakete, die kein Mensch wirklich braucht - so zumindest mein Eindruck - und "fwmod" zum Erstellen eigener Images) tangiert mich nicht so sehr ... daher würde ich meine Aktivitäten an dieser Stelle auch deutlich auf die Korrektur gefundener Probleme beschränken - und wenn sich tatsächlich wieder mehrere Leute zusammenfinden und die Verantwortung für Freetz übernehmen wollen, dann würde ich mich am liebsten aus diesem "Rest" auch komplett heraushalten. Höchstens für das "Drumherum" hätte ich noch ein paar Vorschläge (über einen haben ich mit
@er13 vor nicht allzu langer Zeit ziemlich erbittert gestritten:
https://github.com/Freetz/freetz/pull/55), die einige Aktivitäten beim Erscheinen neuer (Labor-)Versionen eher in die Hände der Freetz-Benutzer legen und damit auch den Arbeitsaufwand für das "Einarbeiten" solcher neuer Versionen in den Freetz-Master verringern. Das wären dann wieder Vorschläge, die sich auf den Teil "Firmware-Generator" beziehen - denn der ist dann ja auch für das Laden, Entpacken und Packen der jeweiligen Labor-Versionen verantwortlich.
