@f666:
Wenn Du die Zeit dafür aufbringen kannst, solltest Du (meine Meinung) weitermachen.
Findet sich noch ein weiterer aktiver(!) Mitstreiter, biete ich mich (in 14 Tagen oder so) erneut als Dritter im Bunde (quasi als Dyonis - frei nach Schiller) an. Ich habe schon zuvor, hier und auch beim Abschied aus der Freetz-ML, betont, daß ich mir die Sache noch einmal überlegen würde, wenn sich etwas tun sollte, was in meinen Augen auch eine Perspektive hat und nicht nur sinnloses Verschwenden von Zeit ist, die man anderweitig besser investieren könnte.
Aus meiner Sicht sollten die Entscheidungen im Projekt, was wie zu übernehmen wäre, im Team fallen (auch wenn das durchaus öffentlich im Review-Prozess in GitHub erfolgen soll und nicht irgendwo im Geheimen) und das erfordert schon mal mindestens zwei handelnde Personen (oder eine mit einem bestimmten Krankheitsbild
). Besser wären m.E. drei (oder jede größere Zahl, solange sie ungerade ist), weil es dann - zumindest bei "entweder-oder"-Fragen - kein Patt geben kann und niemand (so sollte man zumindest hoffen können) gegen eine mehrheitlich getroffene Entscheidung handelt, was einen "commit war" schon mal per se verhindern sollte.
Sollte es tatsächlich so etwas wie einen "Sumpf der Freetz-Entwicklung" geben und das Beharrungsvermögen bei den Verwaltern der bisher genutzten Ressourcen so hoch sein (und auch bleiben), daß mit diesen für die Zukunft (nach gemeinsamer Einschätzung der aktiven "contributors") kein Blumentopf zu gewinnen ist, würde ich die erforderlichen Ressourcen für einen Neustart als Fork des bisherigen "alten Freetz" bereitstellen (aber natürlich mit einem Fork, der die Vererbung unter den GitHub-Repos respektiert). Die Domain "yourfreetz.de" habe ich (schon mal vorsichtshalber, die kann ich auch anderweitig verwenden) soeben registriert und den Speicherplatz für das Spiegeln von Dateien finde ich auch noch irgendwo ... notfalls miete ich eine AWS-Instanz für deren Speicherung.
Das Einzige, was ich nicht machen will und werde, ist eine Konkurrenzveranstaltung zu einem Freetz-Projekt (das kann ein Fork oder auch das bisherige Projekt sein), in dem tatsächlich eine
Gruppe von Maintainern aktiv (und im Interesse der Community) an der Fortführung und Weiterentwicklung von Freetz arbeitet. Allerdings sehe ich (im Lichte jüngerer Reaktionen und Erkenntnisse) auch ein paar Probleme, wenn die Verwaltung der Freetz-Ressourcen weiterhin hierarchisch erfolgt und Einzelpersonen dort "das Sagen" haben, anstelle eines "Gremiums" aus denjenigen, die tatsächlich die Arbeit übernehmen. Wenn das die Konsequenz daraus sein sollte, daß die Ressourcen alle "gespendet" sind, dann muß man eben mit anderen Ressourcen weiterarbeiten.
===========================================================
Also bitte nicht gleich wieder die Flinte ins Korn werfen ... ich habe zwar auch immer wieder (und hoffentlich deutlich) das Vorgehen von
@cuma kritisiert, weil ich diese Entwicklung wohl irgendwie erahnt habe (es ist ja auch nicht das erste Mal, daß dieser Vandalismus in den IPPF-Threads erfolgt), seitdem der "zweite Versuch" mit der Abgrenzung "von der Familie" aufgefallen ist, aber es besteht sicherlich auch ein weitgehender Konsens bei den Freetz-
Benutzern (und denen soll das ja am Ende irgendetwas bringen, solange es nicht als Selbstbeweihräucherung von Maintainern gedacht ist), daß irgendetwas geschehen muß.
Ich weiß zwar nicht, wie man die 16 "Finde ich prima"-Votes am Ende tatsächlich bewerten sollte (sprich: ob die nun die Idee der Fortführung begrüßen oder doch ausdrücklich die Art und Weise, wie
@cuma das angegangen ist), aber das IPPF ist - zumindest in meinen Augen - inzwischen auch eine eher ungünstige Wahl, wenn es um ein Feedback von den Freetz-Benutzern geht.
Vollkommen unabhängig davon, wie sich das Freetz-Projekt weiter entwickelt ... solange es auf GitHub gehostet wird, sollte man auch die Möglichkeiten des GitHub-UI nutzen und dazu gehört eine sehr gut nutzbare "Review-Funktion", die auch allen Benutzern offen steht (solange ein Projekt auch "contributions" möchte). Man kann dort z.B. einer Idee, was man in Freetz implementieren könnte oder sollte, mit einem einzigen Mausklick die eigene Meinung (in Form eines "thumbs up" oder "thumbs down") hinzufügen und muß dazu gar nichts weiter schreiben.
Allerdings geht das eben nur, wenn es auch die passende "Issue" (vergleichbar mit einem früher verwendeten Trac-Ticket, nur viel besser in den gesamten GitHub-Prozess integriert) oder einen "Pull Request" (ein "Angebot" für ein fertiges Feature oder Paket, was nur noch mit dem "master"-Stand zusammengemischt werden muß, wenn es ideal läuft und keine Änderungen notwendig sind) gibt, wo man die eigene Meinung kundtun kann. Existieren diese "items" aber im GitHub, ist in meinen Augen auch die Freetz-Community gefordert, sich an der Entscheidungsfindung, in welche Richtung sich Freetz entwickeln soll, zu beteiligen. Wenn die berühmte Fee mit dem Zauberstab auftaucht und einem nur drei Wünsche offeriert, es aber zehn "would be nice"-Tickets gibt, die man damit abarbeiten lassen könnte, braucht es irgendeine Priorisierung und da es nun mal - wie zuvor schon mal bemerkt - ein Projekt
für die Freetz-Benutzer sein sollte, sollten diese auch das letzte Wort haben, was sie als wichtig und "dringend" erachten. Zwar kann man das irgendwie auch durch intensives Lesen und "Nachfragen" aus den IPPF-Threads ableiten, aber ein einfachen "Abzählen" der "pro"- bzw. "contra"-Votes im GitHub-UI sollte um einiges leichter (und nachvollziehbarer) sein.
Das IPPF ist dann wieder für die Diskussion von Problemen gut geeignet ... und hier wohl auch weiterhin dem direkten Erstellen einer neuen Issue, die am Ende auch nur das Ergebnis bringt, daß man selbst den Fehler bei der Anwendung von Freetz gemacht hat, vorzuziehen. Wenn man hier im IPPF erst einmal geklärt hat, daß es sich tatsächlich um ein Freetz-Problem handelt (das war früher ja Usus, daß man nicht direkt ein Trac-Ticket eröffnete, weil man mit dem "svn up" nicht klarkam), kann man das mit Fug und Recht (und am besten dem Link auf den Thread im IPPF) immer noch als Issue in GitHub eintragen. Es wäre jedenfalls für die Übersichtlichkeit von Vorteil, wenn dort nur tatsächliche Fehler von Freetz abgehandelt würden und nicht die Fehler, die aus falscher Anwendung (die jedem passieren kann) resultieren. Ich fände es auch begrüßenswert, wenn die Issues für "abgehakte" Probleme dann auch tatsächlich geschlossen werden (auch von deren Erstellern), denn eine zu lange "working queue" ist auch immer eine Abschreckung für weitere (ggf. wichtigere) Einträge. Wenn ich ein (kleines) Projekt mit 20 unbearbeiteten Issues sehe und den Eindruck gewinne, die arbeitet ohnehin niemand ab, weil die schon sehr lange dort stehen, dann überlege ich es mir noch einmal mehr, ob ich meine Zeit investiere und dort den 21. Eintrag hinzufüge.
Aber auch so eine Möglichkeit der "Abstimmung" stellt natürlich noch lange nicht sicher, daß etwas überhaupt zu realisieren ist oder daß sich ein Entwickler dieser Sache mit Herzblut annimmt ... aber im Gegensatz zur derzeitigen Situation, wo ein Developer eher davon ausgeht (und ausgehen muß), was er selbst als sinnvoll und hilfreich ansieht, gibt es mit solchen Tickets zumindest eine Chance, daß sich jemand der Sache annimmt. Idealerweise benutzt man dann die GitHub-Funktionen (wie "assignments" für Probleme) sogar zur Koordination der "contributors" und verhindert damit doppelte Arbeit, weil sich zwei parallel auf ein (kleines) Problem gestürzt haben.
===========================================================
Ich will aber auch nicht verhehlen (das kann man aber auch nachlesen, insofern wäre das ohnehin aussichtslos), daß ich strikt dagegen bin, irgendwelche alten Trac-Tickets in einem automatischen Prozess nun doch noch in ein (aktives) GitHub-Repo zu überführen. Das kann man zum Zweck der Archivierung ja gerne machen ... aber alleine die Arbeit der Bewertung, welche Tickets weiterhin relevant sind und welche sich einfach im Laufe der Jahre auch überlebt haben, wäre in meinen Augen verschenkt. Wenn es weiterhin ein aktuelles Problem gibt oder einen Wunsch für ein neues Feature oder was auch immer, dann kann man das auch problemlos noch einmal in einer Issue im GitHub aufschreiben ... und dabei am besten gleich noch den aktuellen Stand von Freetz (und auch der AVM-Firmware) berücksichtigen. Das Argument "Dafür hatte ich aber vor x Tagen/Wochen/Monaten/Jahren schon mal ein Ticket angelegt." ist für mich jedenfalls keines, mit dem man begründen sollte, warum man dafür keine neue Issue anlegen möchte.
Ich würde den (hoffentlich endgültigen) Übergang zu Git und GitHub auch gerne als einen Schnitt sehen, der eine Neuordnung der anstehenden Arbeiten nach ihrer Dringlichkeit ermöglicht und vielleicht sogar als einen, der alte Zöpfe abschneidet. Ich weiß zwar, daß es da draußen noch viele ältere Boxen geben mag und deren Besitzer sich nur ungerne von den Geräten trennen wollen ... aber im Gegensatz zu anderen Projekten wie OpenWRT ist Freetz eben auf die Vorlage der AVM-Firmware angewiesen und wenn diese mehrere Jahre alt und voller Sicherheitslöcher ist, kann Freetz dagegen auch nur wenig unternehmen. Wer weiterhin mit solchen alten Schätzchen arbeiten möchte, kann das ja mit dem derzeitigen Stand auch problemlos machen ... wenn es tatsächlich mal ein Update für ein Freetz-Package geben sollte, das auch für die alten Boxen relevant ist, dann kann man das ja auch (aber eher als Ausnahme und nicht als den Regelfall) auf einen älteren Stand (als Branch) portieren.
Aber das Hauptaugenmerk bei der Fortführung von Freetz sollte man meines Erachtens auf neuere Boxen legen und vor der 7390 endlich auch mal einen Schnitt machen. Es gibt nicht sooo viele neue Modelle mit sehr knappem Flash-Speicher, bei denen man unbedingt noch "externals" und viele Remove-Patches verwenden muß, damit man das Freetz-Image samt Erweiterungen überhaupt in die Box bekommt ... daher macht es (für mich) auch nicht so viel Sinn, die Unterstützung dafür wiederaufleben zu lassen. Die Remove-Patches haben ja ohnehin seit dem "responsive design" und vielen nachfolgenden Änderungen (u.a. Mesh) noch einige Ecken und Kanten, wie man gerade erst beim Media-Server wieder sehen konnte:
https://www.ip-phone-forum.de/threads/7390-06-85-14948-mediaserver.302469/#post-2317143 - das Problem dort entsteht u.a. auch deshalb, weil hier die Unterstützung sehr, sehr alter Boxen noch enthalten ist (auch wenn das natürlich reparabel wäre mit dem korrekten Test in der zweiten Zeile). Abseits der 7390 und 7360, wo in erster Linie das WLAN (7390) und die Sprachdatenbanken für die internationalen Versionen ausgelagert wurden (hier kam dann die 4020 noch hinzu), gibt es den Plugin-Mechanismus für die ganzen anderen Komponenten schon seit FRITZ!OS 5 nicht mehr und trotzdem werden die betreffenden Patches nach wie vor mit durchgeschleppt und führen dann - wie in der
https://github.com/Freetz/freetz/blob/master/patches/scripts/500-remove_mediasrv.sh - zu unangenehmen Effekten, auch wenn die Änderung (Einbeziehen des Symbols "FREETZ_AVM_HAS_PLUGIN_MEDIASRV" in der zweiten Zeile des Patches) hier simpel ist. Aber am Ende leidet eben auch die Übersichtlichkeit ... gerade auch im Lichte der Entwicklung, daß Freetz inzwischen mehrere Prozessor-Plattformen unterstützt, weil auch bei AVM eine breitere Ausrichtung bei der Hardware zu verzeichnen ist.
===========================================================
Ein Fehler, der sich nur deshalb "einschleichen" konnte, weil man alte Zöpfe nicht abschneiden wollte, ist aber doppelt ärgerlich ... nicht ganz umsonst gibt es in der professionellen Softwareentwicklung auch das Mittel des "
software rewrites". So etwas muß man nicht immer zwingend als Hauruck-Aktion umsetzen ... aber wenn man erst einmal eine Entscheidung in dieser Richtung getroffen hat, kann man schon bei der nächsten anstehenden Änderung diesen Aspekt der "Rückwärtskompatibilität" entsprechend schwächer bewerten oder gar komplett vernachlässigen. Es mag zwar der Wunschtraum sein, soviele Boxen wie möglich zu unterstützten und in einer idealen Welt mit unbegrenzten Ressourcen (in Form der Arbeitszeit der "contributors") mag das sogar denkbar sein ... aber wenn die wenigen älteren FRITZ!Boxen (hier kommt irgendwann dann auch mal die natürliche Selektion zu tragen, wo die Anzahl der älteren Boxen stetig abnimmt) überproportional viel von der investierten Zeit binden, weil man immer diese Rückwärtskompatibilität im Auge haben will, dann geht das (für mich) in die falsche Richtung und ich bin da eher für eine pragmatische Lösung, selbst wenn diese älteren Boxen (wo der Abschied aber auch eher Erlösung sein sollte als Schmerz) dabei "hinten runterfallen". Die Zahl der neuen FRITZ!Boxen mit Freetz-Image dürfte die der alten Modelle (vor der 7390) deutlich übertreffen, wenn ich mich nicht absolut verrenne ...
