Und jetzt kommt sicher ne meterlange Erklärung warum es besser ist das Projekt einem US-Konzern zu übertragen mit dessen zwangsweisen politischen Embargos statt es weiter self hosted in Deutschland zu betreiben dass die ganze Welt daran weiterhin teilnehmen darf wie ng es tut, und Freetz es tat.
Ne, das ist dann sogar mir zu blöd und da die bisherigen Erklärungsversuche offenbar bei Dir nicht ins Hirn vordringen konnten, erwarte ich im Ergebnis von Wiederholungen auch keinen Zuwachs an Erkenntnissen bei Dir. Der Rest hat es vermutlich ohnehin bereits verstanden und wenn nicht, kann er ja an den bereits vorhandenen Stellen:
Freetz und Freetz-NG sind nicht mehr einfach mergebar durch commits von f-666. Da es nie meine Absicht war, "konkurrierende" Forks zu haben, beende ich hiermit Freetz-NG. Mitstreiter fanden sich eh keine dafür, weshalb hab ich keine Problem damit habe und dadurch kein Verlust entsteht. Die...
www.ip-phone-forum.de
Ab sofort ist der Freetz-ng Fork auf BoxMatrix erreichbar und hat da seinen SVN Master. Weitere Dienste werden folgen (wie die Reimplementierung des Tracs usw), das dauert aber ein wenig. Diese Dienste gelten natürlich dann unparteiisch für alle Forks. Man kann das Repo auschecken und auch...
www.ip-phone-forum.de
nachlesen.
Früher fand ich es ja noch putzig, wenn Du mit solchen Theorien aufgelaufen bist und dachte bei mir: "Der weiß es halt nicht besser." ... aber die Feststellung:
Und man hätte beide in Einheit halten können...
unterschlägt eben immer wieder, daß ich (a) vor dem Auseinanderlaufen bereits bei den allerersten Anzeichen gewarnt habe und (b) diese "Einheit" ausschließlich zu Deinen Bedingungen hätte erhalten werden können.
Die "Abstimmung" (auch wenn es keine formale war, so gab es doch mehrere Stimmen und Du warst der einzige, der anderer Meinung war) auf der Freetz-Developer-Mailingliste, ob man mit Freetz komplett auf das - ohnehin schon seit Jahren parallel genutzte - GitHub wechselt oder was man ansonsten mit dem schon Jahre vor sich hingammelnden SVN-/Trac-Gespann macht, war eindeutig.
Irgendwie erinnert mich Deine - immer wieder aufs Neue vorgebrachte - Haltung an dieser Stelle an den alten Geisterfahrer-Witz ... für den gibt es eben nicht nur einen solchen, sondern viele. Aber vielleicht fährst Du ja irgendwann doch noch einmal rechts ran (oder besser links?) und denkst darüber nach, was der Unterschied zwischen "gemeinsame Entscheidung" und "Ralf S. kriegt seinen Willen" sein könnte.
Für den Github Github über alles Wahnsinn geht das Projekt zu Bruch. Sowohl global politisch als auch lokal mitwirkugstechnisch.
Da fällt mir eigentlich nur noch ein, daß mir gar nicht bewußt war, wie sehr die Nebenwirkungen von PCP im FRITZ!Box-Kontext (ich hielt das immer für das "Port Control Protocol") auch in Richtung Halluzinationen und Verfolgungswahn gehen können. Was haben denn die bei "freetz-ng" vorgenommenen Änderungen an den grundlegenden Konfigurationseinstellungen (in deren Ergebnis diese Inkompatibilitäten ja erst entstanden) mit der Frage zu tun, ob man Git/GitHub oder SVN/Trac als VCS verwendet? Riiichtiiisch ... genau gar nichts. Hier irgendeinen Zusammenhang mit der Frage des VCS herbeizuphantasieren, verkleistert nur aufs Neue den Blick für die Ursachen der Inkompatibilitäten und die Verantwortlichkeiten dabei.
---------------------------------------------------------------------------------------------------------
Der freetz-org Fork hat so wenig und so viel mit Freetz zu tun wie der freetz-ng Fork.
Einen wichtigen Unterschied zwischen "freetz" auf GitHub und dem "freetz-non-genuine"-Fork (eine bessere Erklärung für den Namen hat m.E. noch niemand abgegeben oder kann ich sie nur nicht finden?) vergißt Du immer wieder zu erwähnen - ist das Absicht, Leugnen oder schlichte Vergesslichkeit?
Ersteren gibt es ja deutlich länger als "freetz-ng" und wer sich damals beim Forken als Freetz-User noch dachte: "OK, gibt es eben zwei und ich kann mir künftig das Beste aus beiden Welten aussuchen.", der wurde nicht vom "originalen" Freetz-Fork daran gehindert ... denn "freetz-ng" beschränkt(e) sich eben nicht nur darauf, neuere Versionen irgendwelcher Pakete schneller an den Mann zu bringen oder irgendwelche "Zusatzfunktionen" (leider häufig ungetestet, wie ich jederzeit an der Commit-Historie zeigen kann, die deutlich mehr "Rücknahmen" enthält, als die des originalen Freetz) anzubieten, es wurde hier ganz gezielt auf eine inkompatible Konfiguration hingearbeitet. Und selbst wenn das nicht das "primäre Ziel" gewesen sein sollte, wurde es doch von Anfang an nicht nur sehenden Auges, sondern absichtlich in Kauf genommen, wie wiederum die Threads aus dem Februar/März 2019 hier im IPPF zeigen.
Bitte ändert das, das ist kindisch!
Dann lass Dir doch ein Unterforum für "freetz-ng" hier einrichten und mache tatsächlich den Support für "freetz-ng" ... daß es sich bei dem Fall hier um einen handelt, der gerade an diesem Unterschied scheitert, ist ja offensichtlich und damit wohl auch von Dir mit Deinen kruden Verschwörungstheorien kaum zu bestreiten.
Also ich finde es ja gut und natürlich dass es Konkurrenz gibt
Ich habe kein Problem mit Konkurrenz ... nur dann nehmt beim Fork (was der Unterschied zwischen einem organisatorischen Fork und einem technischen (wie beim Forken in Git) ist, habe ich auch schon versucht zu erklären ... offensichtlich ebenso vergeblich - aber es gibt eben nur einen "organisatorischen Fork" und ich kann ja verstehen, wenn "freetz-ng" krampfhaft versucht, das bis Feb. 2019 alleine existierende Freetz ebenfalls "zum Fork zu erklären"; nur geht es eben an der historischen Wirklichkeit vorbei, wenn man solches behauptet) doch einfach das IPPF aus der Liste der Orte, wo man als "freetz-ng"-User Hilfestellung erhalten kann oder sorgt dafür, daß hier jemand den Leuten bei inhaltlichen Problemen mit dem "freetz-ng"-Fork auch hilft und ladet das nicht einfach bei anderen ab ... wer einen inkompatiblen Fork aufsetzt, der sollte auch die Verantwortung für den Support desselben übernehmen und davon sehe ich hier (im IPPF) - ehrlich gesagt - nichts.
Wenn andere keine Lust haben, den Support für den Fork zu übernehmen und sich weigern, ist das auch ihre Sache (konkret hier meine) ... Du ersetzt ja sicherlich die aufzuwendende Zeit, die man für das "Studium" der neuesten Unterschiede benötigt, eher nicht, oder? Wer macht denn jetzt eigentlich den Support für "freetz-ng" hier im IPPF? Ich fühle mich (wenn überhaupt) jedenfalls nur für das Original zuständig, was ich auch in meinem "YourFreetz"-Fork als Grundlage benutze (Warum gibt es eigentlich nach Deiner Zählung dann nur drei (technische) Forks? Endet da Deine vielbeschworene "Fairness" vielleicht auch schon wieder?) - und ich beschränke i.d.R. meine Hilfen auch auf die Toolchain-Teile bzw. auf die Teile vom Rest, die mit irgendwelchen Sachen von mir arbeiten.
---------------------------------------------------------------------------------------------------------
[Piiieeeep, Novize - bitte sachlich bleiben]
