Freetz-NG
- Ersteller cuma
- Erstellt am
...und bin gerne bereit, dies auch weiter zu testen... zudem hätte ich noch WebSpace frei 
gismotro
Mitglied
- Mitglied seit
- 5 Sep 2007
- Beiträge
- 525
- Punkte für Reaktionen
- 128
- Punkte
- 43
Was ist denn mit dieser Idee : https://www.ip-phone-forum.de/threads/boxmatrix-svn-server-und-freetz-svn-backup.302398/ ?
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
1. Ich glaube nicht daran, daß es sich tatsächlich um "Fehler" handelte und nicht um absichtliche Änderungen, die zum Unterbrechen der Vererbung geführt haben. Die inzwischen ja sogar deutlich niedergeschriebene Aufforderung, aus dem "freetz-ng"-Fork bloß ja keine Patches in das GitHub-Repo von Freetz zu übernehmen, dürfte auch bei der zwischenzeitlichen Änderung (denn das Repo unter "freetz-ng/freetz-ng" wurde ja erst 4 Tage NACH dem ersten Fork noch einmal neu eingerichtet und dabei dann erst die Vererbung unterbrochen, siehe #34 in diesem Thread) die eigentliche Triebfeder gewesen sein. Eine andere, plausible Begründung gab es dafür ja nicht (auch nicht auf Nachfrage), denn neben der Tatsache, daß es gar keine Notwendigkeit gibt, sowohl "freetz" als auch "freetz-ng" unter ein und demselben Account zu forken, steht ja auch noch die - sicherlich jedem auch ins Auge springende - Option, einfach auch mit zwei GitHub-Accounts zu arbeiten, wenn man unbedingt beide Projekte forken will (wo man den Sinn der Sache dann immer noch erläutern können sollte, wenn man danach gefragt wird).
2. Wer sich - trotz sehr vieler verfügbarer Quellen im Internet, wie man mit "git" arbeitet - nicht sicher ist, kann ja einfach fragen. Bei einem Repository, was eben keine "working copy" ist, an der man die eigenen Änderungen für die Übernahme in ein Projekt vorbereitet, sondern ganz deutlich das Repository sein soll, mit dem alle anderen Benutzer arbeiten (aus dem also bei Projekten mit "deployment" die Release-Version erzeugt würde), sollte man schon wissen, was man da eigentlich tut (oder es sich erarbeiten und ggf. an einer weniger gut sichtbaren Stelle probieren, wie mit einem Fleckentferner). Ich bin auch skeptisch, wenn mir jemand mit einem GitHub-Account aus 2010, wo der Inhaber gleichzeitig auch noch - bis vor kurzem zumindest - bei diesem Projekt zum Team gehören sollte und wo im GitHub-Account beriets 37 andere Projekte als Fork eingerichtet wurden in der Vergangenheit, dann erklärt, er hätte ja gar keine Ahnung von Git und/oder GitHub. Das mag - unter sehr, sehr ungewöhnlichen Umständen - sogar stimmen, aber eine gesunde Skepsis ist hier sicherlich auch nicht vollkommen unbegründet.
3. Was man tatsächlich machen kann ... man kann problemlos einen SVN-Stand aus einem existierenden Git-Stand erzeugen. Da stört es dann auch nicht, wenn Subversion für verteilte Entwicklung deutlich schlechter geeignet ist als Git, denn bei dieser Richtung der Synchronisation repräsentiert das SVN-Repo nur einen bestimmten Stand aus Git und verhindert damit nicht, daß man die Vorteile von Git auch ausreizen kann.
4. Vielleicht sollten die "Git-Hasser" sich erst mal mit den Möglichkeiten befassen, bevor sie etwas verteufeln, was sie gar nicht kennen oder noch nicht richtig verstanden haben. Ja, man muß das verstehen, was die Philosophie hinter dieser Software ist und man muß sich auch ein wenig einarbeiten. Ich finde es aber schon sehr merkwürdig, wenn hier in erster Linie die Leute, die eigentlich nichts anderes machen müssen, als ein Repository für die eigene Verwendung zu klonen (was bei beiden SCM-Systemen genau ein Kommando braucht, das gilt auch für das Aktualisieren), ständig auf Git herumhacken. Mit den "Besonderheiten" kommt man eigentlich erst dann in Berührung, wenn man tatsächlich selbst etwas beitragen möchte und das geht mit Git allemal leichter, als es bisher mit irgendwelchen Trac-Tickets und dort angehangenen Patch-Files der Fall war. Letztere mußten dann immer wieder mal auf potentielle Konflikte überprüft und ggf. angepaßt werden ... das geht mit einem "Pull Request" in GitHub fast alles automatisch, auch wenn sich andere Dateien ändern sollten.
5. Die Arbeit mit GitHub ist in vielen Tutorials im Internet bereits ausgezeichnet beschrieben, man muß sich halt (als "contributor" oder auch als "maintainer") nur mal die Zeit nehmen, sich da etwas einzuarbeiten. Da braucht es (meine Meinung) keine weitere Anleitung ... allerdings sollte ein Projekt tatsächlich (auch das ist wieder nicht nur auf meinem Mist gewachsen, das kann sich jeder selbst "draufschaffen", wenn er mal einigen der Links folgt, die ich weiter vorne schon angeführt habe in diesem Thread) so etwas wie eine Policy haben, wie man das "Stamm-Repository" organisiert. Dafür gibt es mehrere Möglichkeiten ... aber eines haben sie alle gemeinsam: Ohne Disziplin bei den handelnden Personen geht es tatsächlich nicht. Nur klingt das erst einmal alles viel komplizierter, als es am Ende tatsächlich ist und wer irgendwann mal im Git zwei unabhängig entwickelte Stände zusammenmischen mußte, der lernt spätestens da das Prinzip: "Alles ist ein Branch." zu schätzen, auch wenn das bei anderen SCM vielleicht weniger entwickelt ist. Bei Git liegt das praktisch in den Genen ... aber noch einmal: Dafür gibt es (wirklich sehr gute) Anleitungen und Erklärungen im Internet (wo denn sonst).
6. Diese muß/sollte man aber auch nur dann kennen, wenn man selbst Änderungen so bereitstellen will, daß ein Maintainer sie praktisch per Mausklick integrieren kann. Rein für die "Verwendung" von Freetz muß man gar nichts weiter über das verwendete SCM wissen (egal, ob das nun Subversion oder Git ist) - da reichen zwei Kommandos (eines für den ersten Checkout und ein weiteres für spätere Aktualisierungen) vollkommen aus und im besten Fall, gibt es sogar eine "stable version" als komprimierte Datei zum Download ... alles direkt aus GitHub und mit sehr wenig zusätzlichem Aufwand für die Verwalter.
Was hätte denn SVN dem entgegenzusetzen, außer dem berühmten "Beamten-Dreisatz"? Mit einem einzigen, eigenen GitHub-Account kann man das gesamte GitHub-Angebot (mit jeder Menge weiterer Projekte, die ja auch mit Git arbeiten und deren Verwalter und/oder Benutzer sind sicherlich auch nicht alle vollkommen blöd, weil sie sich für Git als SCM entschieden haben) nutzen ... ich bin schon schwer gespannt, wie das bei dem anderen SVN-Server "geregelt" wird mit dem Nutzer-Feedback, für das bisher ja ein Trac-Server verantwortlich war.
Alleine die DSGVO-konforme Verwaltung von Accounts bei einem solchen System (irgendwo wird man ja E-Mail-Adressen speichern müssen, wenn man mit Accounts arbeiten will und nicht einfach ein "open system" bereithält - und dann muß man da auch wieder löschen können und auch noch auf Auskunftsbegehren der (ehemaligen) Benutzer reagieren) dürfte einen Aufwand darstellen, den man sich nur antun will, wenn man das aus den Effeff beherrscht. Denn für einen solchen "Ticket-Server mit Benutzerkonten" gilt ziemlich sicher der Ausnahmetatbestand in Art. 2 Zf. 2 Bst. c der DSGVO nicht ... das ist ja keine persönliche oder familiäre Verwendung der Daten mehr. Auch das ist eben etwas, was einem GitHub dann abnimmt (also das gesamte "Handling" für die Benutzer, wobei man zur reinen Nutzung im Rahmen von Freetz nicht mal einen Git/GitHub-Account braucht) und das sollte man - so man es wirklich alles selbst machen will - ebenfalls nicht unterschätzen.
PS: Wer das jetzt wieder zu lang findet, darf mir gerne einen "Gegenvorschlag" unterbreiten, wie man dieselben Informationen in deutlich kürzerer Form (aber bitte weiterhin in korrekter deutscher Sprache und Schreibweise, samt vollständiger Satzbildung, denn die sollte man schon in der Kindheit erlernt haben) "zu Papier" bringen sollte. Auch ein alter Hund lernt ja vielleicht noch neue Tricks.
2. Wer sich - trotz sehr vieler verfügbarer Quellen im Internet, wie man mit "git" arbeitet - nicht sicher ist, kann ja einfach fragen. Bei einem Repository, was eben keine "working copy" ist, an der man die eigenen Änderungen für die Übernahme in ein Projekt vorbereitet, sondern ganz deutlich das Repository sein soll, mit dem alle anderen Benutzer arbeiten (aus dem also bei Projekten mit "deployment" die Release-Version erzeugt würde), sollte man schon wissen, was man da eigentlich tut (oder es sich erarbeiten und ggf. an einer weniger gut sichtbaren Stelle probieren, wie mit einem Fleckentferner). Ich bin auch skeptisch, wenn mir jemand mit einem GitHub-Account aus 2010, wo der Inhaber gleichzeitig auch noch - bis vor kurzem zumindest - bei diesem Projekt zum Team gehören sollte und wo im GitHub-Account beriets 37 andere Projekte als Fork eingerichtet wurden in der Vergangenheit, dann erklärt, er hätte ja gar keine Ahnung von Git und/oder GitHub. Das mag - unter sehr, sehr ungewöhnlichen Umständen - sogar stimmen, aber eine gesunde Skepsis ist hier sicherlich auch nicht vollkommen unbegründet.
3. Was man tatsächlich machen kann ... man kann problemlos einen SVN-Stand aus einem existierenden Git-Stand erzeugen. Da stört es dann auch nicht, wenn Subversion für verteilte Entwicklung deutlich schlechter geeignet ist als Git, denn bei dieser Richtung der Synchronisation repräsentiert das SVN-Repo nur einen bestimmten Stand aus Git und verhindert damit nicht, daß man die Vorteile von Git auch ausreizen kann.
4. Vielleicht sollten die "Git-Hasser" sich erst mal mit den Möglichkeiten befassen, bevor sie etwas verteufeln, was sie gar nicht kennen oder noch nicht richtig verstanden haben. Ja, man muß das verstehen, was die Philosophie hinter dieser Software ist und man muß sich auch ein wenig einarbeiten. Ich finde es aber schon sehr merkwürdig, wenn hier in erster Linie die Leute, die eigentlich nichts anderes machen müssen, als ein Repository für die eigene Verwendung zu klonen (was bei beiden SCM-Systemen genau ein Kommando braucht, das gilt auch für das Aktualisieren), ständig auf Git herumhacken. Mit den "Besonderheiten" kommt man eigentlich erst dann in Berührung, wenn man tatsächlich selbst etwas beitragen möchte und das geht mit Git allemal leichter, als es bisher mit irgendwelchen Trac-Tickets und dort angehangenen Patch-Files der Fall war. Letztere mußten dann immer wieder mal auf potentielle Konflikte überprüft und ggf. angepaßt werden ... das geht mit einem "Pull Request" in GitHub fast alles automatisch, auch wenn sich andere Dateien ändern sollten.
5. Die Arbeit mit GitHub ist in vielen Tutorials im Internet bereits ausgezeichnet beschrieben, man muß sich halt (als "contributor" oder auch als "maintainer") nur mal die Zeit nehmen, sich da etwas einzuarbeiten. Da braucht es (meine Meinung) keine weitere Anleitung ... allerdings sollte ein Projekt tatsächlich (auch das ist wieder nicht nur auf meinem Mist gewachsen, das kann sich jeder selbst "draufschaffen", wenn er mal einigen der Links folgt, die ich weiter vorne schon angeführt habe in diesem Thread) so etwas wie eine Policy haben, wie man das "Stamm-Repository" organisiert. Dafür gibt es mehrere Möglichkeiten ... aber eines haben sie alle gemeinsam: Ohne Disziplin bei den handelnden Personen geht es tatsächlich nicht. Nur klingt das erst einmal alles viel komplizierter, als es am Ende tatsächlich ist und wer irgendwann mal im Git zwei unabhängig entwickelte Stände zusammenmischen mußte, der lernt spätestens da das Prinzip: "Alles ist ein Branch." zu schätzen, auch wenn das bei anderen SCM vielleicht weniger entwickelt ist. Bei Git liegt das praktisch in den Genen ... aber noch einmal: Dafür gibt es (wirklich sehr gute) Anleitungen und Erklärungen im Internet (wo denn sonst).
6. Diese muß/sollte man aber auch nur dann kennen, wenn man selbst Änderungen so bereitstellen will, daß ein Maintainer sie praktisch per Mausklick integrieren kann. Rein für die "Verwendung" von Freetz muß man gar nichts weiter über das verwendete SCM wissen (egal, ob das nun Subversion oder Git ist) - da reichen zwei Kommandos (eines für den ersten Checkout und ein weiteres für spätere Aktualisierungen) vollkommen aus und im besten Fall, gibt es sogar eine "stable version" als komprimierte Datei zum Download ... alles direkt aus GitHub und mit sehr wenig zusätzlichem Aufwand für die Verwalter.
Was hätte denn SVN dem entgegenzusetzen, außer dem berühmten "Beamten-Dreisatz"? Mit einem einzigen, eigenen GitHub-Account kann man das gesamte GitHub-Angebot (mit jeder Menge weiterer Projekte, die ja auch mit Git arbeiten und deren Verwalter und/oder Benutzer sind sicherlich auch nicht alle vollkommen blöd, weil sie sich für Git als SCM entschieden haben) nutzen ... ich bin schon schwer gespannt, wie das bei dem anderen SVN-Server "geregelt" wird mit dem Nutzer-Feedback, für das bisher ja ein Trac-Server verantwortlich war.
Alleine die DSGVO-konforme Verwaltung von Accounts bei einem solchen System (irgendwo wird man ja E-Mail-Adressen speichern müssen, wenn man mit Accounts arbeiten will und nicht einfach ein "open system" bereithält - und dann muß man da auch wieder löschen können und auch noch auf Auskunftsbegehren der (ehemaligen) Benutzer reagieren) dürfte einen Aufwand darstellen, den man sich nur antun will, wenn man das aus den Effeff beherrscht. Denn für einen solchen "Ticket-Server mit Benutzerkonten" gilt ziemlich sicher der Ausnahmetatbestand in Art. 2 Zf. 2 Bst. c der DSGVO nicht ... das ist ja keine persönliche oder familiäre Verwendung der Daten mehr. Auch das ist eben etwas, was einem GitHub dann abnimmt (also das gesamte "Handling" für die Benutzer, wobei man zur reinen Nutzung im Rahmen von Freetz nicht mal einen Git/GitHub-Account braucht) und das sollte man - so man es wirklich alles selbst machen will - ebenfalls nicht unterschätzen.
PS: Wer das jetzt wieder zu lang findet, darf mir gerne einen "Gegenvorschlag" unterbreiten, wie man dieselben Informationen in deutlich kürzerer Form (aber bitte weiterhin in korrekter deutscher Sprache und Schreibweise, samt vollständiger Satzbildung, denn die sollte man schon in der Kindheit erlernt haben) "zu Papier" bringen sollte. Auch ein alter Hund lernt ja vielleicht noch neue Tricks.
hermann72pb
IPPF-Promi
- Mitglied seit
- 6 Nov 2005
- Beiträge
- 3,726
- Punkte für Reaktionen
- 16
- Punkte
- 38
@PeterPawn : Das Problem ist nicht GIT, sondern die Befürchtung der fehlenden Disziplin und als Folge eine geometrisch progressierende Anzahl der Forks. Und da kann auch ein rein passiver Nutzer den Überblick verlieren, was denn nun jetzt lauffähig ist. Zumindest geht es mir oft so, wenn ich in den Weiten des Internets solche "selbst organisierende" (man nennt es auch oft "historisch gewachsene") Projekte sehe und als Nutzer nicht mehr weiß, welchen Fork ich denn jetzt nehmen soll. Und ja, davon gibt es genug im Netz. SVN+TRAC mag ja unflexibel sein, durch diese "Unflexibilität" war aber eine gewisse Disziplin erzwungen und wenigstens eine geradelinige Verfolgung für einen passiven Benutzer nachvollziehbar.
Man kann es ja auch mit GIT machen und sollte nicht zu SVN und TRAC zurückkehren, wenn man alles unter dem GIT-Hut hinbekommt. Es bedarf aber mindestens 2-3 starke Personlichkeiten, die es nicht sturr, aber konsequent mit der Versionsverwaltung durchziehen.
Wer macht es?
Man kann es ja auch mit GIT machen und sollte nicht zu SVN und TRAC zurückkehren, wenn man alles unter dem GIT-Hut hinbekommt. Es bedarf aber mindestens 2-3 starke Personlichkeiten, die es nicht sturr, aber konsequent mit der Versionsverwaltung durchziehen.
Wer macht es?
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
Das weiß ich auch noch nicht ... zumal das für mindestens einen der Beteiligten (der die Absprachen - aka "Regeln" - für die Verwaltung des Repo dann aufschreibt) erst einmal in deutlich mehr "Verwaltungsarbeit" ausarten würde, als in die Chance, sich gleich in die Arbeit (der Entwicklung) stürzen zu können.
Die Gefahr, daß man am Ende nicht mehr weiß, was man nehmen soll, sehe ich absolut nicht ... wenn das Projekt-Repo einen "Release-Zweig" hat, in dem es stabile Stände gibt, zu denen dann wieder Fehlerkorrekturen vorhanden sind, dann sind schon mal die Benutzer, die wirklich "stable" wollen, "abgefrühstückt".
Gibt es parallel dazu einen "Developer-Branch", in dem die aktuellenPakete Änderungen zusammengefaßt sind, kommen auch die "Spielkinder" auf ihre Kosten ... die können diesen Stand nehmen und nach Herzenslust auf jedem Gerät testen, welches ihnen in die Finger gerät. Hält man dann nämlich die eigene Policy ein, daß nur tatsächlich getestete Änderungen auch in den Release-Branch gelangen, hat man - fast automatisch - auch weniger mit den oben erwähnten "Fehlerkorrekturen" zu tun in diesem Branch, weil solche Korrekturen dann (zumindest idealerweise) bereits erfolgt sind, bevor die Änderungen in den Release-Branch gelangt sind.
Ich weiß nicht, wie es andere OpenSource-Projekte machen ... aber für ein Projekt wie Freetz ist "agile Entwicklung" (zumindest beim "continuous delivery"-Aspekt) in meinen Augen einfach nicht geeignet. Das würde ja wieder bedeuten, daß man einfach für alle Benutzer genau das bereitstellt, was gerade da ist - ohne Rücksicht darauf, wie weit es fertig oder getestet ist (das hat dann Ähnlichkeit mit dem bisherigen Vorgehen, auch wenn @er13 es meist geschafft hat, Inkonsistenzen zu vermeiden).
Das kann man dann machen, wenn die Zielgruppe sehr homogen ist hinsichtlich der Kenntnisse und Fertigkeiten (die auch noch gut entwickelt sein sollten) und sich bei Problemen tatsächlich selbst helfen kann; notfalls durch Verwenden eines älteren Standes. Das würde ich beim durchschnittlichen Freetz-Benutzer jetzt erst einmal nicht so sehen ... rein auf der Basis der hier immer mal wieder nachzulesenden Probleme.
Auch dürfte es bei Freetz dann eher so sein, daß da nicht jeden Tag ein neuer Stand entstehen würde (und der Benutzer damit die berechtigte Hoffnung hegen könnte, daß die Version von morgen die Probleme schon nicht mehr hat) ... wenn's schlecht läuft, müßten dann alle Benutzer(!), die sich nicht selbst helfen können, erst mal bis zur nächsten Version warten. Solange CI/CD (continuous integration / continuous delivery) nicht mit anderen Prinzipien der agilen Programmierung (z.B. Sprints, wo es tatsächlich täglich sichtbare Änderungen und einen neuen "daily build" gibt) Hand in Hand geht, bringt es (gerade auch bei einem Projekt wie Freetz, wo es ja kein fertiges Produkt zum Installieren gibt EDIT: und auch keine formalen (Unit-)Tests, die der aktuelle Stand bestehen könnte oder müßte) auch nichts.
Das heißt dann in der Konsequenz wieder, daß auch der Developer-Branch eigentlich "kein Spielplatz" ist und die "erste Präsentation" einer Änderung - und zwar bis zum erfolgreichen ersten Test auf wenigstens einer Box - in einem gesonderten "feature branch" erfolgt. Das müßte dann auch für Änderungen gelten, die eigentlich nur "fixes" sind - wobei letztere nach gemeinsamem Review(!) auch ohne weiteren Test bereitgestellt werden könnten, wenn die Änderung logisch und eindeutig nachvollziehbar ist ... man muß die "Prinzipienreiterei" ja auch nicht übertreiben. Aber diese Arbeitsweise hat eben auch den (für mich unbestreitbaren) Vorteil, daß man so einen Branch mit einem Handgriff in seinen eigenen Klon zum Testen integrieren kann und ihn ebenso mit einem Handstreich wieder los wird, wenn man ihn doch nicht haben will oder er die Ursache eines Problems ist.
So sähe das zumindest nach meiner Ansicht in einer idealen Welt aus ... nur paßt halt Freetz im Moment auch von der Struktur her ganz schlecht zu diesem Vorgehen. Wenn jede neue Labor-Version von AVM (wo man ja im Moment wieder bei "weekly builds" angekommen ist, wie es scheint) auch eine neue Version von Freetz zur Folge hat, macht man sich schon bei diesem Aspekt der "Wartung" "einen Häßlichen" (so sagte man zumindest meinerzeit zu einer Sisyphos-Arbeit). Man kann so etwas also vermutlich auch nicht im Hauruck-Verfahren einführen, solange man das Projekt nicht so umgestellt hat, daß die Auswahl der gerade aktuellen Labor-Version für die jeweilige Box gleich direkt beim Freetz-Benutzer erfolgt. Das MUSS man ja nun nicht wirklich zentral machen, solange es keine tiefgreifenden Änderungen gibt, die mehr als nur den Austausch der als Vorlage dienenden AVM-Firmware erfordern.
===================================================
Das "Branchen" ist jedenfalls u.a. auch deshalb so wichtig "als Prinzip", weil man mit wenigen, ganz simplen Eingaben auf der Kommandozeile praktisch jeden beliebigen anderen Branch in den eigenen Klon mischen kann, solange es keine Konflikte (also widersprüchliche Änderungen) gibt. Wenn man z.B. meinen "yf_patchkernel"-Branch (mit dem LKM für das TUN-Device unter VR9 und GRX5) mit dem derzeitigen Freetz-Master zusammen haben wollte, sähe das in etwa so aus:
Erst einmal wird (eine Eingabe) das Freetz-Repo lokal als "mein_klon" geklont (oben), dann wechselt man in das Git-Verzeichnis (wichtig und die zweite Eingabe) und definiert eine weitere Quelle mit einem anderen Repository, hier mit meinem Freetz-Fork auf GitHub:
Die Option "-f" beim "git remote add" sorgt dafür, daß sofort noch ein "git fetch" erfolgt, mit dem die Verwaltungsinformationen des neuen Repos geladen werden. Ohne diese Option müßte man noch ein "git fetch yf" (das "yf" ist hier der Name für diese zusätzliche Quelle) ausführen nach dem "git remote add".
Jetzt hat man die freie Auswahl aus den Branches in meinem Repo, welche man nun zu seinem eigenen Klon mischen will - ich nehme jetzt einfach mal den "yf_patchkernel" dazu:
Nach dem Mischen erfolgt (wenn man es nicht "abbestellt") automatisch ein "commit" für die Änderungen, die Nachricht dafür steht hinter dem "-m", weil ich zu faul bin, die per Editor erst noch zu ändern. Am Ende hat man jetzt das originale Freetz, nur noch ergänzt um die Änderungen, die für "yf_patchkernel" erforderlich sind. Dafür braucht es vier Kommandos ... und zwar "from scratch", wenn man erst noch den Freetz-Master klonen muß oder will. Für jeden weiteren Branch aus einem anderen Repository braucht es noch genau zwei Kommandos.
Will man weitere Feature-Branches hinzunehmen für den eigenen Test, führt man einfach das "git merge" für jeden dieser Branches aus (man kann auch mehrere Branches mit einem Kommando hinzumischen) und wenn die in anderen Repositories liegen, muß man die nur zuvor mit "git remote add" auch noch hinzufügen. Hat man seinen Klon dann fertig, ruft man einfach wieder das "make menuconfig" auf, als würde man ausschließlich mit dem Freetz-Master arbeiten.
Die Arbeit mit mehr als einem Repository ist also "ganz normal", wenn man sich wirklich am Test neuer Feature-Branches beteiligen möchte. Zwar kann man auch direkt im Freetz-Repo weitere Branches aufmachen, in denen man mehrere (fremde) Feature-Branches zusammenfaßt und die interessierte Benutzer dann (anstelle des "master"-Branches) auschecken können nach dem Klonen (oder gleich dabei), aber das wird wohl eher selten der Fall sein, wenn es viele getrennte Repos und Branches sind.
Eingang in den "developer"-Branch (wo dann alle neuen Änderungen seit dem letzten Release zusammen getestet werden können) sollten solche Branches (bzw. die PRs dafür) aber auch erst dann finden, wenn sie wenigstens von einem weiteren Benutzer (und nicht nur dem Autoren selbst) erfolgreich getestet wurden.
Das klingt vielleicht alles etwas formalistisch und man muß es auch längst nicht so machen, wie ich es hier vorschlage ... nur würde eine solche Aufteilung (als Minimalvariante) auch sicherstellen, daß es für die Freetz-Benutzer mit dem "stable"-Wunsch immer eine Version gibt, während die Mutigen dann selbst entscheiden, ob sie zu den "early adopters" gehören wollen und die Branches aus den Repos anderer Developer testen oder ob sie nicht gleich die Ersten sein wollen und lieber etwas benutzen, was zwar deutlich "noch nicht fertig" ist, aber zumindest schon mal bei anderen die Tauglichkeit unter Beweis gestellt hat und daher im "developer"-Branch im Haupt-Repo zu finden ist.
Das sollte dann auch die Frage beantworten, wo man nun den "freigegebenen Stand" finden kann (der ja auch funktionieren sollte) ... nämlich wieder im Stamm-Repository des Projekts und wenn es dort keine Tags für Release-Versionen geben sollte, findet man die eben im "master" (so zumindest die empfohlene Arbeitsweise, wobei der "master" nicht automatisch so heißen muß - bei mir heißt der eben "YourFritz" im Fork).
Auch sollte jeder Inhaber eines Repos (zumindest wenn man dieses als Benutzer in Erwägung zieht als Quelle für eigene Software) in der Lage sein zu beschreiben, was seinen eigenen Fork nun eigentlich von der Stammversion unterscheidet (oder unterscheiden wird) ... und das auch entsprechend in einer README.md hinterlegt haben. Aber man kann ja auch als GitHub-"Kunde" bei einem geforkten Repository ganz einfach erkennen, ob das nun tatsächlich irgendwelche Änderungen enthält oder gar denselben Stand, wie das Quell-Repo. In der "Hauptseite" im GitHub-GUI steht bei einem Fork auch immer, ob und wenn ja, um wieviele Commits er sich von dem Repository unterscheidet, von dem er abstammt. Ist ein solcher Fork (bzw. Branch) also "even with Freetz:master", dann gibt es darin gar keine Änderungen ggü. der Quelle und man muß gar nicht weiter danach suchen, was den nun vom "originalen Freetz" unterscheidet. Idealerweise hat so ein Fork dann auch noch einen "sprechenden Namen" ... zumindest wenn sich die Beitragenden das jetzt angewöhnen, nachdem die Chance besteht, daß solche Branches tatsächlich direkt Eingang in das Stamm-Repo finden und nicht erst noch "umgearbeitet" werden bei der Übernahme im SVN (wo dann auch niemand mehr sehen konnte, wie der Branch für den PR im GitHub mal hieß).
Solange die Repos alle demselben Stammbaum angehören, kann man sich auch bereits mit dem GitHub-GUI davon überzeugen, ob es mit einem bestimmten Branch irgendwelche potentiellen Konflikte gibt und man (sofern man diese nicht selbst beheben will) von diesem Branch besser erst mal noch die Finger läßt.
Das mag dann - so als Hauruck-Aktion - auch erst mal etwas viel an Neuem sein, was dem bisherigen SVN-Benutzer hier "zugemutet" wird ... aber man muß sich eben überlegen, ob man nun dem SVN hinterhertrauern will oder ob man sich nicht doch einfach mal mit den wenigen Kommandos vertraut macht, die man als "Freetz-Benutzer" eigentlich nur braucht, um sich sein ureigenstes System aus dem "Freetz-Master" und irgendeinem anderen Branch (oder auch mehreren) zusammenzubauen.
Vergleicht man das mit dem Aufwand, den man auch als Freetz-Benutzer früher hatte, wenn man den Trunk verwenden wollte (oder mußte) und da noch weitere Patches aus irgendwelchen Trac-Tickets zuvor anzuwenden waren, ist das im GitHub nun mal deutlich einfacher ... da wird einem sofort angezeigt, wenn ein Branch nicht zum Rest passen würde und man kriegt das nicht erst dann mit, wenn das "patch"-Kommando irgendwelche Hunks verwirft und dabei am besten noch ein inkonsistenter Stand entsteht, weil ein Teil der Patches erfolgreich ist und ein anderer nicht.
Die Gefahr, daß man am Ende nicht mehr weiß, was man nehmen soll, sehe ich absolut nicht ... wenn das Projekt-Repo einen "Release-Zweig" hat, in dem es stabile Stände gibt, zu denen dann wieder Fehlerkorrekturen vorhanden sind, dann sind schon mal die Benutzer, die wirklich "stable" wollen, "abgefrühstückt".
Gibt es parallel dazu einen "Developer-Branch", in dem die aktuellen
Ich weiß nicht, wie es andere OpenSource-Projekte machen ... aber für ein Projekt wie Freetz ist "agile Entwicklung" (zumindest beim "continuous delivery"-Aspekt) in meinen Augen einfach nicht geeignet. Das würde ja wieder bedeuten, daß man einfach für alle Benutzer genau das bereitstellt, was gerade da ist - ohne Rücksicht darauf, wie weit es fertig oder getestet ist (das hat dann Ähnlichkeit mit dem bisherigen Vorgehen, auch wenn @er13 es meist geschafft hat, Inkonsistenzen zu vermeiden).
Das kann man dann machen, wenn die Zielgruppe sehr homogen ist hinsichtlich der Kenntnisse und Fertigkeiten (die auch noch gut entwickelt sein sollten) und sich bei Problemen tatsächlich selbst helfen kann; notfalls durch Verwenden eines älteren Standes. Das würde ich beim durchschnittlichen Freetz-Benutzer jetzt erst einmal nicht so sehen ... rein auf der Basis der hier immer mal wieder nachzulesenden Probleme.
Auch dürfte es bei Freetz dann eher so sein, daß da nicht jeden Tag ein neuer Stand entstehen würde (und der Benutzer damit die berechtigte Hoffnung hegen könnte, daß die Version von morgen die Probleme schon nicht mehr hat) ... wenn's schlecht läuft, müßten dann alle Benutzer(!), die sich nicht selbst helfen können, erst mal bis zur nächsten Version warten. Solange CI/CD (continuous integration / continuous delivery) nicht mit anderen Prinzipien der agilen Programmierung (z.B. Sprints, wo es tatsächlich täglich sichtbare Änderungen und einen neuen "daily build" gibt) Hand in Hand geht, bringt es (gerade auch bei einem Projekt wie Freetz, wo es ja kein fertiges Produkt zum Installieren gibt EDIT: und auch keine formalen (Unit-)Tests, die der aktuelle Stand bestehen könnte oder müßte) auch nichts.
Das heißt dann in der Konsequenz wieder, daß auch der Developer-Branch eigentlich "kein Spielplatz" ist und die "erste Präsentation" einer Änderung - und zwar bis zum erfolgreichen ersten Test auf wenigstens einer Box - in einem gesonderten "feature branch" erfolgt. Das müßte dann auch für Änderungen gelten, die eigentlich nur "fixes" sind - wobei letztere nach gemeinsamem Review(!) auch ohne weiteren Test bereitgestellt werden könnten, wenn die Änderung logisch und eindeutig nachvollziehbar ist ... man muß die "Prinzipienreiterei" ja auch nicht übertreiben. Aber diese Arbeitsweise hat eben auch den (für mich unbestreitbaren) Vorteil, daß man so einen Branch mit einem Handgriff in seinen eigenen Klon zum Testen integrieren kann und ihn ebenso mit einem Handstreich wieder los wird, wenn man ihn doch nicht haben will oder er die Ursache eines Problems ist.
So sähe das zumindest nach meiner Ansicht in einer idealen Welt aus ... nur paßt halt Freetz im Moment auch von der Struktur her ganz schlecht zu diesem Vorgehen. Wenn jede neue Labor-Version von AVM (wo man ja im Moment wieder bei "weekly builds" angekommen ist, wie es scheint) auch eine neue Version von Freetz zur Folge hat, macht man sich schon bei diesem Aspekt der "Wartung" "einen Häßlichen" (so sagte man zumindest meinerzeit zu einer Sisyphos-Arbeit). Man kann so etwas also vermutlich auch nicht im Hauruck-Verfahren einführen, solange man das Projekt nicht so umgestellt hat, daß die Auswahl der gerade aktuellen Labor-Version für die jeweilige Box gleich direkt beim Freetz-Benutzer erfolgt. Das MUSS man ja nun nicht wirklich zentral machen, solange es keine tiefgreifenden Änderungen gibt, die mehr als nur den Austausch der als Vorlage dienenden AVM-Firmware erfordern.
===================================================
Das "Branchen" ist jedenfalls u.a. auch deshalb so wichtig "als Prinzip", weil man mit wenigen, ganz simplen Eingaben auf der Kommandozeile praktisch jeden beliebigen anderen Branch in den eigenen Klon mischen kann, solange es keine Konflikte (also widersprüchliche Änderungen) gibt. Wenn man z.B. meinen "yf_patchkernel"-Branch (mit dem LKM für das TUN-Device unter VR9 und GRX5) mit dem derzeitigen Freetz-Master zusammen haben wollte, sähe das in etwa so aus:
Code:
vidar:/tmp $ git clone https://github.com/freetz/freetz.git mein_klon
Cloning into 'mein_klon'...
remote: Enumerating objects: 34, done.
remote: Counting objects: 100% (34/34), done.
remote: Compressing objects: 100% (28/28), done.
remote: Total 141050 (delta 12), reused 14 (delta 6), pack-reused 141016
Receiving objects: 100% (141050/141050), 32.14 MiB | 10.41 MiB/s, done.
Resolving deltas: 100% (94408/94408), done.
vidar:/tmp $ cd mein_klon
vidar:/tmp $
Code:
vidar:/tmp/mein_klon $ git remote add -f yf https://github.com/PeterPawn/freetz.git
Updating yf
remote: Enumerating objects: 659, done.
remote: Counting objects: 100% (659/659), done.
remote: Total 1043 (delta 658), reused 659 (delta 658), pack-reused 384
Receiving objects: 100% (1043/1043), 3.44 MiB | 4.99 MiB/s, done.
Resolving deltas: 100% (756/756), completed with 204 local objects.
From https://github.com/PeterPawn/freetz
* [new branch] YourFritz -> yf/YourFritz
* [new branch] YourFritz_History -> yf/YourFritz_History
* [new branch] bb_mount -> yf/bb_mount
* [new branch] clearconfig -> yf/clearconfig
* [new branch] dropbear -> yf/dropbear
* [new branch] fix_patch_for_remove_mediasrv -> yf/fix_patch_for_remove_mediasrv
* [new branch] ltrace -> yf/ltrace
* [new branch] master -> yf/master
* [new branch] mc -> yf/mc
* [new branch] ncurses -> yf/ncurses
* [new branch] sqlite3 -> yf/sqlite3
* [new branch] submodules -> yf/submodules
* [new branch] uclibc_target -> yf/uclibc_target
* [new branch] wiki -> yf/wiki
* [new branch] yf_patchkernel -> yf/yf_patchkernel
* [new tag] v0.1 -> v0.1
vidar:/tmp/mein_klon $Jetzt hat man die freie Auswahl aus den Branches in meinem Repo, welche man nun zu seinem eigenen Klon mischen will - ich nehme jetzt einfach mal den "yf_patchkernel" dazu:
Code:
vidar:/tmp/mein_klon $ git merge -m "merge yf_patchkernel" yf/yf_patchkernel
Merge made by the 'recursive' strategy.
config/ui/modules.in | 5 ++++
make/linux/configs/freetz/config-grx5-7590_07.01 | 1 +
make/linux/configs/freetz/config-vr9-7490_07.01 | 1 +
make/linux/patches/3.10.104/7590_07.01/900-patchkernel_source.patch | 1 +
make/linux/patches/3.10.104/7590_07.01/901-patchkernel_7590.patch | 1 +
make/linux/patches/3.10.107/7490_07.01/900-patchkernel_source.patch | 1 +
make/linux/patches/3.10.107/7490_07.01/901-patchkernel_7490.patch | 1 +
make/linux/patches/3.10.10x/900-patchkernel_source | 220 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
make/linux/patches/3.10.10x/901-patchkernel_7490 | 30 ++++++++++++++++++++++
make/linux/patches/3.10.10x/901-patchkernel_7590 | 31 +++++++++++++++++++++++
make/openvpn-v2-cgi/files/root/etc/init.d/rc.openvpn | 9 +++++++
make/openvpn/Config.in | 5 ++--
12 files changed, 304 insertions(+), 2 deletions(-)
create mode 120000 make/linux/patches/3.10.104/7590_07.01/900-patchkernel_source.patch
create mode 120000 make/linux/patches/3.10.104/7590_07.01/901-patchkernel_7590.patch
create mode 120000 make/linux/patches/3.10.107/7490_07.01/900-patchkernel_source.patch
create mode 120000 make/linux/patches/3.10.107/7490_07.01/901-patchkernel_7490.patch
create mode 100644 make/linux/patches/3.10.10x/900-patchkernel_source
create mode 100644 make/linux/patches/3.10.10x/901-patchkernel_7490
create mode 100644 make/linux/patches/3.10.10x/901-patchkernel_7590
vidar:/tmp/mein_klon $ git show
commit 18ce6b856e744efbea4cf02fb32c5ef80d5a739f
Merge: 7a8fb9c74 c39fa484f
Author: YourFritz <[email protected]>
Date: Tue Feb 19 23:30:23 2019 +0100
merge yf_patchkernel
vidar:/tmp/mein_klon $Will man weitere Feature-Branches hinzunehmen für den eigenen Test, führt man einfach das "git merge" für jeden dieser Branches aus (man kann auch mehrere Branches mit einem Kommando hinzumischen) und wenn die in anderen Repositories liegen, muß man die nur zuvor mit "git remote add" auch noch hinzufügen. Hat man seinen Klon dann fertig, ruft man einfach wieder das "make menuconfig" auf, als würde man ausschließlich mit dem Freetz-Master arbeiten.
Die Arbeit mit mehr als einem Repository ist also "ganz normal", wenn man sich wirklich am Test neuer Feature-Branches beteiligen möchte. Zwar kann man auch direkt im Freetz-Repo weitere Branches aufmachen, in denen man mehrere (fremde) Feature-Branches zusammenfaßt und die interessierte Benutzer dann (anstelle des "master"-Branches) auschecken können nach dem Klonen (oder gleich dabei), aber das wird wohl eher selten der Fall sein, wenn es viele getrennte Repos und Branches sind.
Eingang in den "developer"-Branch (wo dann alle neuen Änderungen seit dem letzten Release zusammen getestet werden können) sollten solche Branches (bzw. die PRs dafür) aber auch erst dann finden, wenn sie wenigstens von einem weiteren Benutzer (und nicht nur dem Autoren selbst) erfolgreich getestet wurden.
Das klingt vielleicht alles etwas formalistisch und man muß es auch längst nicht so machen, wie ich es hier vorschlage ... nur würde eine solche Aufteilung (als Minimalvariante) auch sicherstellen, daß es für die Freetz-Benutzer mit dem "stable"-Wunsch immer eine Version gibt, während die Mutigen dann selbst entscheiden, ob sie zu den "early adopters" gehören wollen und die Branches aus den Repos anderer Developer testen oder ob sie nicht gleich die Ersten sein wollen und lieber etwas benutzen, was zwar deutlich "noch nicht fertig" ist, aber zumindest schon mal bei anderen die Tauglichkeit unter Beweis gestellt hat und daher im "developer"-Branch im Haupt-Repo zu finden ist.
Das sollte dann auch die Frage beantworten, wo man nun den "freigegebenen Stand" finden kann (der ja auch funktionieren sollte) ... nämlich wieder im Stamm-Repository des Projekts und wenn es dort keine Tags für Release-Versionen geben sollte, findet man die eben im "master" (so zumindest die empfohlene Arbeitsweise, wobei der "master" nicht automatisch so heißen muß - bei mir heißt der eben "YourFritz" im Fork).
Auch sollte jeder Inhaber eines Repos (zumindest wenn man dieses als Benutzer in Erwägung zieht als Quelle für eigene Software) in der Lage sein zu beschreiben, was seinen eigenen Fork nun eigentlich von der Stammversion unterscheidet (oder unterscheiden wird) ... und das auch entsprechend in einer README.md hinterlegt haben. Aber man kann ja auch als GitHub-"Kunde" bei einem geforkten Repository ganz einfach erkennen, ob das nun tatsächlich irgendwelche Änderungen enthält oder gar denselben Stand, wie das Quell-Repo. In der "Hauptseite" im GitHub-GUI steht bei einem Fork auch immer, ob und wenn ja, um wieviele Commits er sich von dem Repository unterscheidet, von dem er abstammt. Ist ein solcher Fork (bzw. Branch) also "even with Freetz:master", dann gibt es darin gar keine Änderungen ggü. der Quelle und man muß gar nicht weiter danach suchen, was den nun vom "originalen Freetz" unterscheidet. Idealerweise hat so ein Fork dann auch noch einen "sprechenden Namen" ... zumindest wenn sich die Beitragenden das jetzt angewöhnen, nachdem die Chance besteht, daß solche Branches tatsächlich direkt Eingang in das Stamm-Repo finden und nicht erst noch "umgearbeitet" werden bei der Übernahme im SVN (wo dann auch niemand mehr sehen konnte, wie der Branch für den PR im GitHub mal hieß).
Solange die Repos alle demselben Stammbaum angehören, kann man sich auch bereits mit dem GitHub-GUI davon überzeugen, ob es mit einem bestimmten Branch irgendwelche potentiellen Konflikte gibt und man (sofern man diese nicht selbst beheben will) von diesem Branch besser erst mal noch die Finger läßt.
Das mag dann - so als Hauruck-Aktion - auch erst mal etwas viel an Neuem sein, was dem bisherigen SVN-Benutzer hier "zugemutet" wird ... aber man muß sich eben überlegen, ob man nun dem SVN hinterhertrauern will oder ob man sich nicht doch einfach mal mit den wenigen Kommandos vertraut macht, die man als "Freetz-Benutzer" eigentlich nur braucht, um sich sein ureigenstes System aus dem "Freetz-Master" und irgendeinem anderen Branch (oder auch mehreren) zusammenzubauen.
Vergleicht man das mit dem Aufwand, den man auch als Freetz-Benutzer früher hatte, wenn man den Trunk verwenden wollte (oder mußte) und da noch weitere Patches aus irgendwelchen Trac-Tickets zuvor anzuwenden waren, ist das im GitHub nun mal deutlich einfacher ... da wird einem sofort angezeigt, wenn ein Branch nicht zum Rest passen würde und man kriegt das nicht erst dann mit, wenn das "patch"-Kommando irgendwelche Hunks verwirft und dabei am besten noch ein inkonsistenter Stand entsteht, weil ein Teil der Patches erfolgreich ist und ein anderer nicht.
Zuletzt bearbeitet:
fesc
Mitglied
- Mitglied seit
- 14 Mai 2016
- Beiträge
- 350
- Punkte für Reaktionen
- 92
- Punkte
- 28
PeterPawn
IPPF-Urgestein
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,298
- Punkte für Reaktionen
- 1,760
- Punkte
- 113
OT:
Beim "Lesefluß" stimme ich Kritikern sogar zu - auch wenn "Romane"(was ich nicht mal als Beschimpfung sehe) schon vom "Stil" des Autoren leben. Wobei ich an dieser Stelle das Wort "Roman" auch nicht als Beschimpfung verstehe - die Romane, welche ich ansonsten so lese, sind häufig durchaus auch spannend bzw. sind sie das nicht, kaufe ich nichts mehr von diesem Autoren.
Wie man sieht, geht es auch ohne Klammern ... aber die "drei Punkte" als "Sprechpause" und den Bindestrich als "schwaches Komma", werde ich mir nur schwer abgewöhnen können - ich bin auch nicht sicher, ob ich das wirklich wollte. Das "Vereinfachen" von Klammerausdrücken werde ich aber mal für ein paar Tage versuchen.
Das "Auflösen" von Klammern ist natürlich machbar, wenn ich mich darauf konzentriere - dann schreibt man das einfach hintereinander in weiteren Sätzen. Nur hatte ich das so verstanden, daß sich die meisten an der Gesamtlänge reiben und die würde sich ja nur verringern, wenn es inhaltlich tatsächlich sehr viele unnütze Informationen oder ständige Wiederholungen gäbe und man auf diese verzichten könnte, ohne daß der Inhalt oder die Gesamtaussage darunter leidet.
Beim "Lesefluß" stimme ich Kritikern sogar zu - auch wenn "Romane"
Wie man sieht, geht es auch ohne Klammern ... aber die "drei Punkte" als "Sprechpause" und den Bindestrich als "schwaches Komma", werde ich mir nur schwer abgewöhnen können - ich bin auch nicht sicher, ob ich das wirklich wollte. Das "Vereinfachen" von Klammerausdrücken werde ich aber mal für ein paar Tage versuchen.
Neueste Beiträge
-
Jfritz kann Anrufliste seit FritzBox Labor nicht holen
- Letzte: houyhnhnm
-
[Problem] WiFi7 Fritz Box 5690pro- Letzte: Jstessi
-
1und1 online.de Emailadresse "befreien"
- Letzte: Master1
-
zusätzliche 1GB AF, aber kein Kontingent bei DSL Vertrag mehr- Letzte: Tippfehler
