Freetz-NG

Deine Meinung zu Freetz-NG?


  • Anzahl der Umfrageteilnehmer
    30
  • Umfrage geschlossen .
Persönlich würde ich eine Fortsetzung der Entwicklung im ursprünglichem freetz Repository bevorzugen. Dazu bedürfte es aber Schreibrechte für motivierte Entwickler durch die bisherigen Admins. SVN trauere ich kein bischen nach.
Ein Fork finde ich eher die zweite Wahl, wenn es eben nicht zu 1. kommt. Mehrere Forks sind Mist.
Ich kann mir auch gut vorstellen, den PUMA Port irgendwo zu pflegen.

Im freetz-ng Fork (oder nicht Fork) finde ich die Commit Kommentare schwierig zu überblicken. Damit meine ich z.B. was ist jetzt ein Bugfix, was ein neues Feature, was tut dieses Feature. Gerade bei der Vielzahl an Commits (was an sich positiv ist) muss man oft zweimal hinsehen, um nachvollziehen zu können, was eigentlich gemacht wird. Ist nicht schlimm, halt mein erster Eindruck.
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Das problem ist dass es im Freetz momentan den Domaininhaber, Serverbesitzer, Entwickler, früheren Entwickler und einen Arbeitskollegen gibt. Und von dieser Seilschaft ist seit langem keine Einmischung von anderen gewünscht. Mal schauen wie sich das entwickelt. Ich hätte gerne eine gemeinsame Basis in die jeder der sich beteiligen möchte Änderungen vornehmen kann. Hoffe dass auf diesem Weg sich mehr bewegt.
Schade ist auch dass alle Tickets nicht mehr verfügbar sind und auch kein Backup herausgegeben wird ("will eh keiner"). Im Quellcode sind viele Referenzen zu Tickets

fork oder nicht: Als freetz-ng auf github als fork von freetz gekennzeichnet war, war es leider nicht möglich beide in seinen Account zu forken, da nur 1 Fork pro "Wurzel" geht. Jetzt kann man beide gleichzeitig verwenden.
Falls du ausprobieren möchtest, zuerst beides in deinen Account forken. Dann:
Code:
git clone https://github.com/f666/freetz-ng.git
cd freetz-ng
git remote add freetz https://github.com/f666/freetz
git remote update
git cherry-pick HAAAAAAAAAAAAAAAAAAAAASH (aus f666/freetz)
git push
Danach solltest du über github einen normalen push-request via webseite machen können

Zukünftige Kommentar versuch ich zu verbessern, hättest du früher sagen können :)
Dass es viele sind, ja. Das wird sich aber wieder legen. Ob Patches zu jeder Box&Firwareversion passen muss sich zeigen
 
Zuletzt bearbeitet von einem Moderator:
Als freetz-ng auf github als fork von freetz gekennzeichnet war, war es leider nicht möglich beide in seinen Account zu forken, da nur 1 Fork pro "Wurzel" geht. Jetzt kann man beide gleichzeitig verwenden.
Warum sollte man das machen?

Wenn man "freetz-ng" geforkt hätte(!) und das stammt von "Freetz/freetz" ab, dann hat man "automatisch beide" in seinem Fork, wie ein Blick auf den Stammbaum auch sofort offenbart:
freetz-forks.PNG
Die Differenz so ziemlich jedes beliebigen Checkpoints (aka Commits) zwischen zwei Abkömmlingen desselben Repos kann man jederzeit im GitHub bilden/auswerten/verwenden.

Und zwar unabhängig davon, ob diese "Geschwister" sind - also beide von demselben Repo direkt geforkt wurden - oder ob es eine "Eltern-Kind"-Beziehung ist - also das eigene Repo von einem Fork des "Urvaters" abstammt ... man kann in diesem Falle immer - mit den Mitteln des Freetz GitHub-GUI, deshalb habe ich das in meiner Warnung, daß man damit Möglichkeiten beschneidet, auch so deutlich betont - die Differenz zwischen zwei Ständen abrufen.

Gerade dann, wenn man selbst vergleichen möchte, welche Commits eines anderen Forks der eigene Stand enthält und welche nicht, ist das ein sehr praktisches Werkzeug, das auch nur schwer zu ersetzen ist.

Hier:
Fork-compare.PNG
sieht man die Differenz zwischen einem Branch meines Forks (PeterPawn/freetz/YourFritz - der Name hat nichts mit dem YourFritz-Repo zu tun, das ist nur der Branch/Stand, der dort für die Binärdateien (im YourFritz-Repo) verwendet wird und anstelle des "master" als Default gesetzt ist) und einem anderen (fesc2000/freetz/6490_review), wobei letzterer gar nicht in direkter Linie von Freetz abstammt, sondern vom Fork von @f666 (der stünde dann also auf "derselben Stufe", wie jeder beliebige Fork von "freetz-ng", wenn das weiterhin ein (SCM-)Fork von "Freetz/freetz" wäre).

Trotzdem kann man beide von seinem GitHub-Account aus "ansprechen" ... sowohl die direkten "Eltern" als auch den Rest der "buckligen Verwandschaft" - hier:
two foreign forks compared.PNG
ein Beispiel eines Vergleichs zweier Repos, die nur noch "Cousins" sind nach der oben gezeigten Abstammungsliste und keines der beiden "gehört" irgendwie mir; es hat also auch nichts mit irgendwelchen Eigentumsverhältnissen oder Zugriffsrechten zu tun, ob man diese Vergleiche anstellen kann/darf.

Wer das dann - ohne Not - den "Mitstreitern" aus der Hand nehmen will als Werkzeug, der sollte dafür schon eine passende (und vor allem bitte auch eine korrekte) Begründung anbieten.
 
Coole Funktionen im Freetz-NG:

Skin:
Freetz-NG 1.jpeg
Partitionsauswahl:
Freetz-NG 2.jpeg
Autoreboot:
Freetz-NG 3.jpeg

Das sollte generell im Freetz so aktiviert werden. Top Idee und Umsetzung.
 
  • Like
Reaktionen: Coolzero82
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
Danke @gismotro fürs testen!

Image flashen: Mit "freetz" kann man aktuell nur von "freetz" erstellte images flashen, keine von AVM.
Irgendwann änderte AVM mal was am flashen und statt das kaputte Flashscript in freetz zu korrigieren, wurden die erstellten Images an das Scrip angepasst.
Dies hatte ich mit https://github.com/freetz-ng/freetz-ng/commit/8dd67af44d8b46fbed3d2cea470969029755590f rückgängig gemacht.
In https://github.com/freetz-ng/freetz-ng/commit/0866172de7cf64bb8988f220875e591ec5cfaf2d dann eine Änderung um über die Oberfläche alle images flashen zu können.
Problem: Wenn man "freetz" mir kaputten Script auf der Box hat kann man auch keine "freetz-ng" installieren.
Die Fehlermeldung die man in diesem Fall beim flashen bekommt ist INSTALL_OTHER_ERROR: "update abort - missing Flashtool 'dd'"
Deshalb hab ich vorerst wieder die Veränderung am Script mit https://github.com/freetz-ng/freetz-ng/commit/bb2c441200dfcbca08616a982aae9dc2339743f4 aufgenommen damit man freetz-ng mit freetz flashen kann

@PeterPawn: Wie schon gesagt, ich habe keine Ahnung von GIT. Wenn ich irgendein Problem hat versuche ich eine Lösung zu finden. Wenn ich eine hab ist die in diesem Moment die beste. Kann man später noch ändern/verbessern.
Das Thema GIT ist aber so eine Sache. Jeder schreit "haben will" nur niemand hat davon Plan. Dazu gute Ergebnisse zu finden fällt schwer. Außerdem ist es für mich ein Werkzeug das ich für etwas anderes benutze.
Schreib am besten wie du es gerne hättet und wie man das hinbekommt, zb mit welchen Befehlen so wie etwa der Codeblock in #42

Btw, wie macht man Zeilenumbrücke in git commits? Das ging wohl nicht so ganz...
Und weshalb kann ich 2x das gleiche commiten, ist auch im log so drin aber hat verschieden Hashes (gelöscht, das war nur in meinem Account)?
 
Zuletzt bearbeitet von einem Moderator:
Wenn ich irgendein Problem hat versuche ich eine Lösung zu finden. Wenn ich eine hab ist die in diesem Moment die beste. Kann man später noch ändern/verbessern.
Ansichtssache. Außerdem sollte man das eben nicht "am offenen Herzen" üben (wenn man es selbst so einschätzt, daß man "keinen Plan" hat), besonders dann nicht, wenn man möchte, daß andere genau mit diesem, eigenen Repo arbeiten.

Ich wüßte jedenfalls nicht, wie man nachträglich die "Vererbung" wieder aktiviert (außer man forkt neu und rebased das alles noch einmal) - aber ich wollte auch nur die (aus meiner Sicht eben falsche) Darstellung geraderücken. Ich verstehe immer noch nicht, warum jemand "beide" Repos "forken" wollen sollte - das ergibt gar keinen (richtigen) Sinn.

Das Thema GIT ist aber so eine Sache. Jeder schreit "haben will" nur niemand hat davon Plan.
Das sehe ich - logischerweise - anders ... ich bin mir einigermaßen sicher, daß ich ziemlich genau weiß, was ich mit "git" so anstellen kann und auch bei GitHub finde ich i.d.R. das, was ich suche.

Daß dieses GUI auch ständig weiterentwickelt wird und dabei dann mal die Kenntnis irgendeiner speziellen Funktion, die man bisher noch nie brauchte, auf der Strecke bleibt, ist auch normal und absolut kein Beinbruch. So gab es z.B. die Funktion zum Signieren von Commits mit dem GPG-Key (bzw. die spezielle Darstellung solchermaßen signierter Commits, denn das Signieren gehört ja zu den "git"-Basisfunktionen) im GitHub noch nicht, als ich damit begann und auch die Verwaltung von GPG- und SSH-Keys ist nicht so fürchterlich alt.

Aber das ist nun mal so, wenn sich ein System weiterentwickelt - man muß dann auch wieder selbst dazulernen und das habe ich in diesem konkreten Fall auch getan. Mir war zwar bewußt, daß man "cross repository compares" machen kann mit dem GitHub-GUI, aber daß man daraus auch entsprechende Pull-Requests generieren kann, habe ich selbst auch erst in #13 "gelernt" - das habe ich vorher schlicht nie gebraucht und bei Subversion stellt sich die Frage nach so einer Funktion gar nicht erst.

Jetzt die vielfältigen Möglichkeiten von "git" (was es auch nicht erst seit gestern gibt - man hätte sich also auch schon "seit Jahren" entsprechend selbst weiterqualifizieren können) dafür verantwortlich zu machen, daß man "keinen Plan" hat, ist ja auch eher komisch. Ist aber vermutlich auch wieder eine Frage der eigenen Herangehensweise - man kann eben durchaus auch Dokumentationen lesen, Beispiele von anderen suchen und sogar selbst "üben" (wogegen absolut nichts zu sagen ist - nur macht man das dann eben nicht anhand eines Repos, was andere eigentlich benutzen sollen).

Ich habe auch ein oder zwei Mal im GitHub-GUI (das ist dann tatsächlich "schlechter" (aber immer noch lange nicht "schlecht", wenn man es mit anderen Geschichten vergleicht) dokumentiert) erst nach dem richtigen Weg suchen müssen - mein erster PR für Freetz ist so ein Beispiel. Da war ich schon arg überrascht, daß das GitHub-GUI die komplette Historie zwischen zwei Commit-Ständen in den PR aufnehmen wollte (159 Commits), obwohl sich die tatsächlichen Änderungen auf 3 Dateien beschränkten - aber das ist Lehrgeld, was man beim Benutzen des GUI zahlt und wo bei den eigenen "Übungen" dann trotzdem nicht die anderen (die man ja eigentlich zur Benutzung dieses Repos bewegen will) in Mitleidenschaft gezogen werden.

Und schlußendlich kann man sogar hingehen und diejenigen (vernünftig) fragen, die das bisher schon mal gemacht haben ... die Liste der Freetz-Forks habe ich oben schon gezeigt und einige davon enthalten auch Änderungen, die wiederum als PR an das originale Repo zurückgeflossen sind. Da kann man wohl kaum (bzw. sollte man wohl nicht) davon ausgehen, daß diese Leute auch alle "keinen Plan" hatten, wie man mit Git (oder auch GitHub, denn das sind schon zwei Paar Schuhe) richtig arbeitet.

==========================================================================

Nur weiterlesen, wenn Du (hoffentlich konstruktive) Kritik an Deinen Änderungen auch zur Kenntnis nehmen willst:
Ich sehe nicht, daß Du die Hinweise von @f666 tatsächlich berücksichtigen würdest ... die Kommentare der Commits am gestrigen Tag haben sich nicht wirklich verbessert, was Ausführlichkeit und - das ist der entscheidende Punkt - Nachvollziehbarkeit für andere (die sich vielleicht nicht schon seit Jahren mit den "Innereien" von Freetz beschäftigen) angeht. Wenn andere das nicht "nur schlucken", sondern auch noch verstehen sollen, was Du da warum ändern möchtest, dann mußt Du das schon irgendwo in den Commit-Text packen. Das, was im Trac vielleicht noch im Text des Tickets stand, an welches man den eigenen Patch angehangen hatte, existiert hier eben nur in Form dieser Nachricht, die man beim Commit angeben kann. Deren Titel soll zwar kurz sein (m.W. max. 71 Zeichen), aber in den "Body" kann man nach Herzenslust alles das schreiben, was anderen die eigenen Gedanken "vermitteln" könnte. Solange man keinen PR macht (bei dem man das dann auch ausführlich im GitHub darlegen kann), ist das aber die einzige Möglichkeit, den eigenen Änderungen einen Kommentar hinzuzufügen.

Ferner bin ich der Ansicht, daß Du einige (in meinen Augen) merkwürdige Design-Entscheidungen triffst und diese nicht etwa optional umsetzt, sondern "zwangsweise" für jeden, der Deinen Fork benutzen will. Die einzigen sichtbaren Änderungen in der "patches.in" betreffen den neuen Remove-Patch für den "ddnsd" - der Rest ist offensichtlich nicht konfigurierbar (ich habe auch mal das Repo geklont und ein "make menuconfig" gemacht).

Als Beispiel nenne ich da mal die abweichende Behandlung der Menüpunkte für die Registerkarten im AVM-GUI beim Update bzw. bei den TR-069-Einstellungen und auch Deine Entscheidung, die Warnung von AVM "Einstellungen modifiziert", wenn jemand an den DSL-Parametern "gedreht" hat, einfach komplett herauszupatchen oder generell(!) die DSL-Einstellmöglichkeiten zu erweitern (ob der Freetz-Benutzer das nun will oder nicht), ist in meinen Augen immer noch davon beeinflußt, was Du in so einem Image für richtig erachtest und was da nach Deiner Ansicht enthalten sein muß.

Das ist dann eben doch wieder eine Parallele zu einem "fertigen Image", wo der Benutzer auch nur noch entscheiden kann, ob er es (im Ganzen) will oder nicht - ist nicht wie bei Burger-Brater, wo man eben auch mal das eigene Mahl selbst zusammenstellen kann aus den angebotenen Speisen, wenn einem das "Menü" nicht so richtig behagt. So, wie Du das im Moment anbietest, ist das immer noch ein "cuma-Image", selbst wenn der Benutzer es sich selbst erstellen muß. Bei den allermeisten Änderungen, die Du ggü. dem Stand des "originalen" Projekts vorgenommen hast, muß der Freetz-Benutzer zwangsweise Deine Meinung teilen ... was bei weitem nicht bei allen zusätzlichen Änderungen, die Dir gefallen und nach Deiner Ansicht sinnvoll sind, der Fall sein muß.

Solange es sich bei so einer Änderung dann tatsächlich nur um "Kleinigkeiten" oder ein "Angebot" handelt (von Korrekturen ganz zu schweigen, auf diese trifft das natürlich auch nicht zu), mag das auch angehen und einige/viele/die meisten (ich weiß nicht, was zutrifft) Benutzer nicht weiter stören ... aber da, wo entweder die Arbeitsweise des originalen Systems "beeinträchtigt" oder auch stark geändert wird, sollte man das - sofern man der Freetz-Philosophie folgt und die sollte ja wohl mal sein, daß sich der Benutzer sein eigenes Image so zusammenstellt, wie er (und nicht AVM oder Du) das möchte - dann doch wieder in die Hände des Freetz-Benutzers legen, was er an Änderungen "haben will" und was nicht. Das geht von Remove-Patches für Dateien wie die "S42-ptest" (die zum Herauspatchen - nur nebenbei - doch eigentlich sogar viel zu schade ist, wenn man sich ihren Inhalt (gerade auch in älterer Firmware) mal genauer ansieht) bis zu den bereits erwähnten DSL-Einstellungen - wobei es mir hier auch mehr um die "Philosophie" dahinter geht (ist das nun die Quelle für das "cuma-Image" oder ist das ein "anderes Freetz") und nicht mal konkret um die einzelnen Patches ... die "Aufzählung" ist also beileibe nicht vollständig, weil ich gar nicht alle neuen Commits angesehen habe bzw. bei einigen auch einigermaßen ratlos bin, was Du Dir davon versprichst bzw. warum Du der Ansicht bist, daß das jetzt alle Freetz-Benutzer so haben wollen bzw. hinnehmen müssen.

Das ist eben bei Freetz (und auch bei meinem "modfs") anders ... da entscheidet (bis auf wenige, gut begründete und begründbare Ausnahmen, weil eine "Basisausstattung" nun mal unumgänglich ist) der Benutzer, was passieren soll und was nicht. Es gibt zwar "Vorschläge" (in Form einer Standardkonfiguration), aber der Benutzer hat auch die Möglichkeit, sich die einzelnen Punkte tatsächlich nach eigenem Bedarf zusammenzustellen - ein wenig so, wie beim Neuwagen-Konfigurator eines Autoherstellers (weil die Abhängigkeiten "im Hintergrund" behandelt werden sollten); der "Kunde" ist König und entscheidet (soweit möglich) und nicht der Hersteller.
 
Zuletzt bearbeitet:
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
> Nur weiterlesen, wenn Du (hoffentlich konstruktive) Kritik an Deinen Änderungen auch zur Kenntnis nehmen willst:
Du bist dir zumindest bewusst dass es wieder etwas lang ist...

Ich denkt schon dass ich die Kommentare besser gemacht. Hat vielleicht nicht immer geklappt, aber du weisst ja wie das ist mit den Gewohnheiten ;-)

github.com Überfläche verwende ich nach Möglichkeit nicht, wie festgestellt ändert sich da öfter mal was. Ich nutze Trac lokal, gefällt mir besser.

Wenn jemand was nicht gefällt, was per default gemacht wird oder nicht, ist der schnellste Weg dies zu Ändern: selbst machen :D
Hatte ja dich und andere in die Organisation eingeladen, dem stünde also nichts im Wege. Aber auch ohne kann man "push request" machen
Ich hab da kein Problem damit (sagte ich schon) mehr Optionen reinzubauen. Momentan sind die Sachen halt so wie ich sie benutze und gut finde. Um genau zu sein, hatte ursprünglich sogar der ddnsd auch keine option - und dann hab ich bool/depends verdreht..
Und die dsl-warnung gibt es nur wenn man in den dsl-settings was änderte (gibt beides nur zusammen).
Wobei, sich darüber aufzuregen .. wie ist das denn mit der warnung auf der hauptseite von avm, wenn man "telnet mal an hatte". die ist auch immer unterdrücke

Wie auch schon gesagt, meine Idee für freetz-ng ist NICHT dass ich das alles alleine mache, sondern sich wieder mehr einbringen (können)
( Aber diese Woche am besten diese Woche noch nichts an dern remove-patches, dafür hab ich noch einige patches )

EDIT: Nochmal zu "keine Option". In "freetz" wurde in busybox das build-datum und in dropbear motd fest deaktiviert. ich habe diese so gäandert dass im menuconfig dafür optionen sind, da ich beides lieber sehen würde. Kann somit nun jeder selbst entscheiden.
Patches: ptest-remove hat kein option, da die datei überflüssig ist (hippie). 2xplugin remove: Ich habe keine Option eingebaut, da es diese schon gibt (falsch Tatsachenhauptung). Wenn man ein Image mit Plugins hat, dann auswählt diese fest einzubauen, und man keine oder nur manche einbaut, wird damit auch unterbunden dass nicht ausgewählte *nie* ins Image geladen werden. Diese Bedingungen werden in den Patches abgefragt ;-)
n8
 
Zuletzt bearbeitet von einem Moderator:
Momentan sind die Sachen halt so wie ich sie benutze und gut finde.
Genau das habe ich ja "vermitteln" wollen ... so sieht das eben auch aus (nicht falsch verstehen, ist zwar auch "kritikwürdig", aber zunächst mal nur eine Feststellung). Das ist eben nicht "ein neues Freetz" (oder auch nur ein anderes), sondern das, was @cuma "gut findet".

Ich hatte Deine Absichten in #1 aber so verstanden, daß Du mit anderen gemeinsam etwas auf die Beine stellen willst - da ist das dann kein wirklich guter Start. Wenn Du selbst der Ansicht bist, irgendetwas wäre "noch nicht fertig" (so kann man das oben Zitierte ja auch verstehen, wenn das nur "momentan" ist), dann schreibe das doch einfach nicht in das Projekt-Repository.

Wenn das jemand auch in diesem "unfertigen" Zustand verwenden möchte, kann er sich entweder die Patches aus Deinem PR für diese Änderungen (den kann man auch nachträglich korrigieren und "verfeinern") zusammenstellen oder - wenn Du keinen PR für eine Änderung gemacht hast - auch direkt den passenden Branch aus Deinem Repo in den eigenen Checkout mischen (zusätzliches "remote" definieren, fetchen (wenn man erst "mal gucken" will) und Branch pullen).

Das geht aber natürlich nur dann, wenn Du selbst in Deinem Repo entsprechende "Ordnung" hältst und es für die Änderungen auch separate Branches gibt, die der Interessent mischen könnte - dafür darf das dann eben nicht alles nur "ein Brei von Änderungen" sein, die teilweise gar nichts miteinander zu tun haben. Selbst wenn man davon ausgeht, daß der Interessent an den Änderungen ja auch "cherry-picking" betreiben könnte, braucht der dazu eben auch wieder sinnvolle und verständliche Kommentare - schon in der "Betreff"-Zeile eines Commits - oder er muß sich (parallel zum Prozess des "git cherry-pick") erst noch gesondert durch die einzelnen Commits wühlen.

Dafür ist das "cherry-pick" aber eigentlich auch nicht gedacht ... dessen Sinn ist es eher, aus einem anderen Branch nur die Änderungen herauszuziehen, die man weiterhin braucht (sagt ja schon der Name) - normalerweise wirft man den Rest danach dann weg (wenn man selbst das "cherry-picking" in eigenen Commits betreibt) oder ein Projekt-Maintainer verwendet solches "cherry-picking", wenn er von einem Vorschlag nur einzelne Commits übernehmen will und nicht alles (aber auch der macht das dann eben nur einmal).

Als Strategie "Hier ist der große Topf mit allen Änderungen und da kann/soll sich jeder (Benutzer) per 'cherry-pick' das heraussuchen, was er will." ist das eher gewöhnungsbedürftig und verlagert irgendwie die "eigentliche Arbeit" des Autoren (der das auch nur einmal machen müßte, wenn er gleich von Beginn an "die Ordnung hält") auf den Interessenten (aka Freetz-Benutzer), der auch gleich noch mehrfach existiert (so das Projekt angenommen und genutzt wird) und wo das dann am Ende auch mehrfache Arbeit (zwar bei jedem nur einmal, aber eben auch bei jedem einmal und nicht nur beim "Autoren") bedeutet. Auch deshalb sollte man sich vorher die Arbeitsweise gut überlegen.

Deshalb macht es auch keinen Sinn, wenn wir uns jetzt über einzelne Patches "streiten" ... ich verstehe aber auch nicht so ganz, was Du mir mit "selber machen" genau sagen willst. Das klingt ja fast so, als wärst Du der Meinung, daß ich "nur rede" (und kritisiere) und ansonsten eher nichts zu Freetz beitrage - wenn ich hier "schlau rede" (oder schreibe), versuche ich das auch immer mit einer Begründung zu machen, warum man das besser so machen sollte (oder eben nicht so, wie ich es "kritisiere"). Ich hoffe zumindest, daß meine "Begründungen" so weit verständlich sind, daß sie die angesprochenen Probleme (auch wenn diese "nur potentiell" sein könnten bei manchen Punkten) erklären und deutlich machen, warum ich dieser Ansicht bin und nicht nur festhalten, daß ich etwas anders sehe.

Wenn Du unter diesem "selber machen" aber verstehen solltest, daß andere "das Aufräumen" übernehmen sollten bzw. daß irgendein anderer danach noch an Deinen Änderungen "herumdoktern" sollte, bis diese zur (für "freetz-ng" bisher für mich auch eher unklaren) Philosophie passen (denn Du hast ja in #1 nicht nur "Developer", die sich Deine Änderungen dann wieder selbst so zurechtbiegen können, daß sie "zu ihnen passen", zur Nutzung von "freetz-ng" eingeladen (nicht mit "Mitarbeit" zu verwechseln), sondern auch "alle anderen", die das benutzen wollen), dann sind wir wieder bei meiner Feststellung aus #2 ... das, was Du hier anbietest (was ich prinzipiell sogar gut finde, denn ich habe Dich dazu ja auch zuvor schon mehrfach aufgefordert, z.B. hier: https://www.ip-phone-forum.de/threads/rrdstats-und-smart-home.301623/#post-2308002), ist im Moment ein "Gemischtwarenladen", bei dem dann auch wieder nur Du selbst den Durchblick hast bzw. hoffentlich bewahren kannst.

Wenn man davon ausgeht, daß dieses "freetz-ng"-Repo eine neue Basis für andere sein soll, die ihrerseits dieses Repo forken und daran Änderungen vornehmen sollen, dann sollte das eben tatsächlich auch "das neue Freetz" sein (was Du unter "ng" nun genau verstehen willst, ist ja auch noch als "Frage" offen aus einem vorhergehenden Beitrag), was sich in seinem Inhalt, dem Umfang und den Konfigurationsmöglichkeiten an die potentiellen Benutzer richtet und nicht das "cuma"-Repo (oder auch "fda77" oder wie auch immer man sich/das Repo nennt).

Wenn Du schon selbst der Ansicht bist, daß da irgendwo noch eine Einstellmöglichkeit fehlen könnte, damit sich der Freetz-Benutzer selbst aussuchen kann, ob er eine Änderung haben will oder nicht, dann darf man das eben nicht direkt in das Projekt-Repo schreiben ... da gehört es erst dann hin, wenn "Einigkeit" darüber besteht (gesetzt den Fall, es gibt mehrere handelnde Personen und die stimmen sich auch tatsächlich ab bzw. sehen sich solche Änderungen erst einmal (gemeinsam) an, bevor diese direkt in das Projekt-Repo einfließen), daß es jetzt "fertig" wäre. Ein Projekt-Repository ist nun mal kein "privater Spielplatz" und definitiv nicht der richtige Platz, um "unfertige" Änderungen bereitzuhalten (selbst wenn das beim Freetz-Trunk in Subversion bisher so war) - dafür ist das eigene Repository zuständig.

Das kann man zusätzlich haben (ja, das sollte bzw. muß man sogar zusätzlich haben) ... aber wenn man Daten aus dem eigenen Repository in so ein Repository für ein ganzes Projekt übernimmt, dann sollte man eben auch die thematisch zusammengehörenden Commits aus dem eigenen Repository in einen (thematischen) Pull-Request packen, diesen vernünftig dokumentieren und dann kann man den (ggf. sogar "squashed", wenn es Sinn macht, mehrere Commits (am eigenen Repo, die sich bei der Arbeit an einem Problem eigentlich immer ergeben, wenn man nicht zu den Genies gehört, die immer alles auf Anhieb richtig kodieren) zu einem gemeinsamen für das Projekt zusammenzufassen) in das Projekt übernehmen.

[ BTW: Was ein "Push-Request" ist, weiß ich gar nicht bzw. beim "Pushen" der Änderungen eines anderen Repos in das eigene, sehe ich nirgendwo einen "Request", der diesen Namen irgendwie verdient.

"push" ist aktives Ändern eines "entfernten" Repos (z.B. das Veröffentlichen eines lokalen Standes im "origin"-Repo, was i.d.R. das private Repository mit dem Fork des Projekts sein wird), "pull" ist das Laden von Änderungen eines anderen Repos in das lokale - beides sind Aktionen, die jeder für das eigene Repository ausführen kann. Ein "pull request" ist dann die Aufforderung des Autoren einer Änderung an den Maintainer eines (i.d.R. fremden) Projekt-Repos, einen "Satz von Änderungen" aus einem Branch des eigenen zu übernehmen bzw. das zumindest in Erwägung zu ziehen - also ein "Angebot", eine vorhandene (und bestenfalls auch getestete) Änderung eines anderen "in das Projekt" zu übernehmen. Das mal als "Begriffsbestimmung" für diejenigen (Mit-)Leser, die mit den hier herumschwirrenden Begriffen nichts anfangen können. ]


Anschließend kann dann jeder in der Historie der geänderten Dateien jederzeit "nachschlagen", was da wann, von wem und mit welcher Absicht bzw. in welchem Zusammenhang geändert wurde - macht man den "code review" mit den GitHub-Mitteln, kann man auch das (im dann bereits geschlossenen Pull-Request) noch jederzeit nachlesen, was es da an (am besten gemeinsamen) Überlegungen gab und im besten Falle, warum das genau so gelöst wurde, wie es am Ende in das Projekt übernommen wurde und welche Alternativen diskutiert, aber verworfen wurden.

Das Problem mit so einem eigenen Repository und der "verteilten Arbeit" ist es aber auch, daß man das eben "gleich richtig" machen muß - mit Ausnahme von "rebase"-Aktionen schreiben nämlich alle künftigen Änderungen den aktuellen Stand fort (das Prinzip sei hier jetzt nicht erläutert, es hat mit dem "Hash-Baum" zu tun, der von "git" verwendet wird - das hat entfernte Ähnlichkeit mit einer Blockchain) und spätestens, wenn es bei "nachträglichen Korrekturen" dann zwei unabhängige Änderungen an derselben Datei gibt, hat man den schönsten "merge conflict", den man dann wieder (mit hohem Aufwand) von Hand auflösen muß ... und ich weiß, wovon ich da rede. (Nebenbei bemerkt: Auch für das nachträgliche Ändern von Kommentaren kann man ein Rebase verwenden (https://help.github.com/articles/about-git-rebase/), ein "nun ist's zu spät für sinnvolle Kommentare" gibt es also eigentlich nicht wirklich.)

Der endlose Aufwand, den ich mit meinem Freetz-Fork bei einem Rebase auf das originale Freetz-Repo jedesmal zu betreiben habe, ist auch nur deshalb halbwegs zu bewerkstelligen, weil ich eben die einzelnen Änderungen (ggü. dem Stand, an dem der Fork nach dem letzten Rebase ansetzt) in separaten Branches verwalte (damit kann man die eben auch einzeln als PR vorschlagen und muß das nicht alles in einen Karton schmeißen, den man an die Straße stellt und wo sich jeder das rausnehmen soll, was er will) und damit diese Branches jedesmal separat mittels "rebase" auf den Stand des Ursprungs bringen kann, ohne mir zuviele Konflikte einzufangen. Diese treten aber natürlich trotzdem auf, wenn mal wieder im Basis-Repo eine Datei angefaßt wird, die auch in einem meiner Branches erhebliche Änderungen erfährt.

=========================================================

Wenn Dein Trac-Server über das git-Repo diese Arbeitsweise (mit den bereits einmal erwähnten "feature branches") nicht unterstützt (ob das so ist, weiß ich nicht), dann solltest Du vielleicht doch überlegen, zu einem anderen GUI zu wechseln ... dann würde das nämlich schlicht nicht für die Verwaltung eines git-Repos (und die dabei als "best practice" etablierten Arbeitsweisen - auch das muß man ja nur nachlesen, denn schon "Generationen von Entwicklern" befassen sich ja auch mit "git" seit 2005) passen - was angesichts der "Abstammung" (Trac ist eben nicht speziell für "git" und die dort vorhandenen Möglichkeiten der verteilten SCM-Verwaltung entwickelt und bindet "git" nur als ein Backend von mehreren möglichen ein) auch nicht allzu überraschend wäre.

Und zu einer gemeinsamen Arbeit an einem Projekt gehört eben auch ein "review system", in dem man an vorgeschlagenen Änderungen gemeinsam(!) "herumdoktern" kann, bevor man sie in das Projekt übernimmt ... das wird wohl nur schwer etwas werden, wenn die einen die GitHub-Oberfläche dafür verwenden (und die kann das problemlos und gut), die nächsten einen (privaten) Trac-Server und der Rest meinetwegen "gerrit" (https://www.gerritcodereview.com/).

Ich weiß zwar nicht, wieweit die am Ende tatsächlich "zusammenarbeiten" können, aber m.W. sind die Anmerkungen bei GitHub-Reviews zwar per API abzurufen, aber das muß vermutlich auch erst mal mit entsprechenden Zusatzpaketen eingerichtet und konfiguriert werden. Da ist es dann (in meinen Augen) wieder schlauer, man nimmt einfach etwas, was ohnehin bereits existiert und mit dem sich die Benutzer (zumindest einige) bereits auskennen - und beißt notfalls auch mal die Zähne zusammen und läßt eigene "Gewohnheiten" zugunsten der reibungsloseren Zusammenarbeit fallen.

Betrachtet man die Anzahl der Leute, die zum Subversion-Repository etwas beigetragen haben in der jüngeren Vergangenheit (meinetwegen auch als "diff"-File in einem Trac-Ticket) und vergleicht diese Zahl mit der Anzahl der Forks (des originalen Freetz-Projekts) und den daraus abgeleiteten Pull-Requests für das Projekt-Repo, kann man zumindest mal festhalten, daß die Mehrzahl der "neuen Entwicklungen" ohnehin von Leuten kamen, die eben "git" benutzen.

Wenn man also für diese ein neues Projekt auf die Beine stellen will (und die wären ja vermutlich die ersten, die man "gewinnen" müßte für eine Zusammenarbeit), dann sollte man vielleicht auch bei den Arbeitsabläufen auf etwas setzen, was diese Personen (offensichtlich) schon kennen und nicht - weil es einige "Alte" so wollen und nicht anders kennen - wieder in den alten Trott verfallen und all diese potentiellen Mitstreiter jetzt "dazu zwingen", ihre (etablierte) Arbeitsweise an alte und ihnen i.d.R. eher fremde Riten anzupassen. Das würde vielleicht noch einen Sinn ergeben, wenn die überwiegende Mehrheit der "Mitstreiter" so etwas begrüßt oder wenn diese Mehrheit aus "Alten" besteht, die das ohnehin nicht anders kennen. Ist das aber eine (deutliche) Minderheit, wäre das irgendwie das Wedeln des Schwanzes mit dem Hund.

Wer nun aber etwas Neues aufsetzen will und dafür bei anderen (die erkennbar ja in letzter Zeit ohnehin schon GitHub (bzw. "git") benutzt haben, u.a. ja auch, weil das andere Zeug gar nicht (verläßlich) lief) um Mitarbeit buhlen will (oder muß), der sollte sich eben auch mal die "numerischen Verhältnisse" ansehen und dann ggf. eher seine eigenen Vorlieben "überarbeiten", so daß sie zu denjenigen passen, die man zur Mitarbeit "gewinnen" will.

Geht man hier jetzt hin und richtet das so ein, daß auch dieses eher den eigenen Vorlieben als den (erkennbaren) Gewohnheiten anderer entspricht, baut man natürlich auch für diese potentiellen Mitstreiter zusätzliche Hürden auf und muß sich erst recht nicht wundern, wenn die Resonanz eher gering ausfällt. Daher sollte man so einen "strategischen Fehler" vielleicht gar nicht erst machen ... auch wenn das ggf. heißt, daß man sich selbst "auf den Hosenboden setzt" und sich neues Wissen (und neue Arbeitsabläufe) aneignet.

Und noch mal ... auch das nicht mißverstehen. Ich teile zwar Deine Ziele (und Vorbehalte) nicht, aber das sind trotzdem Aspekte, die Du vielleicht berücksichtigen solltest. Denn wenn ich mir die Liste der Leute ansehe, die Du nach der Aussage in #1 eingeladen hast, sind das ja eher alles Personen (sogar inkl. @er13), die einen GitHub-Account haben und auch ihre Beiträge zu Freetz über genau diese Plattform "eingereicht" haben (hier zählt dann @er13 nicht dazu).

Da jetzt festzustellen, daß Dir persönlich GitHub eher nicht zusagt (hoffentlich nur, weil Du es noch nicht gut genug kennst) und daraus andere "Arbeitsabläufe" abzuleiten, könnte als Idee ganz schnell nach hinten losgehen, weil sich die Leute ggf. fragen könnten, warum sie (ab zweien dann schon wieder die Mehrheit) sich nach Dir und Deinen Vorlieben richten sollten und vielleicht sogar ihrerseits erst noch etwas lernen müssen, was sie ansonsten eher nicht verwenden können (zumindest nicht mehr heutzutage, denn wer den "Kampf" zwischen Subversion und "git" gewonnen hat, dürfte einigermaßen unstrittig sein).

Zum "Leader sein" (und Du willst hier ja offensichtlich vorangehen) gehört es eben nicht nur, die Richtung (nach den eigenen Vorlieben) vorzugeben, sondern auch die Leute mitzunehmen und einen Interessenausgleich zu schaffen bzw. Kompromisse zu vermitteln.
 
Von denn nicht anwählbar DSL-Einstellungen Patch halte ich mal gar nichts, besser gesagt er sollte nicht drin sein. Grade im VVDSL bereich habe ich da noch nie große Verbesserung gesehen aber ganz viele negative Erfahrungen gesammelt. Es wer daher vieleicht besser das man denn selber einschalten kann wenn man es will.

Und in der aktuellen Inhouse Version lauft der Patch so oder so nicht. Daher habe ich denn 831 Patch raus gelöscht (die drei Datein)

Aber im großen und ganzen bin ich froh das mal ein wenig mehr passiert an freetz, habe schon gedacht das es nun langsam ganz stirbt.

Daher vielen dank für die Arbeit.
 
Ich habe zwar nie viel zur Entwicklung von freetz beigetragen, sondern lediglich zur Dokumentation, als jahrelanger Nutzer von freetz stelle ich aber folgendes fest:

Es gibt diverse Kompetenzen, die sich im weitesten Sinne mit dem Thema "Modifikation von Fritz!Boxen" beschäftigen. Leider sind diese Kompetenzen in den vergangenen Jahren nicht gebündelt in eine Richtung gelaufen, sondern in viele Richtungen. Ich würde es begrüßen, wenn dieses Auseinanderlaufen wieder kanonisiert werden könnte. Zu bevorzugen wäre da natürlich (falls möglich) der bisherige, bekannte Name, so wie es @f666 geschrieben hat. Wenn jemand mit git Administrationskenntnissen z.B. wie @PeterPawn es vorgeschlagen hat, die seit langem gewachsene Struktur umbauen kann, damit jeder Experte einfacher an seinem Kernbereich weiterarbeiten kann, führt das letztendlich zum Wohler aller. Ich habe in den vergangenen Wochen mit Wehmut beobachtet, wie das IMHO Glanzprojekt freetz gestorben ist. Umso erfreuter war ich, also ich heute festgestellt habe, dass @hippie2000 seine Bemühungen zur Dokumentation in einem neuen Wiki fortgesetzt hat und meine zahlreichen Hardware-Fotos wieder online für die Nachwelt sind! Das @cuma auf dem aktuellen Stand von freetz einen Fork angelegt hat, um zumindest die Diskussion über die Zukunft anzustoßen, finde ich ebenfalls bewundernswert. Bisher wurde (zumindest nicht öffentlich sichtbar) nichts für eine Weiterentwicklung getan.
Die Idee von @PeterPawn mit kleinen schlanken Paketen eine Firmware modifizieren zu können, fand ich schon zu modfs / YourFritz Zeiten gut, leider reichte meine Zeit nicht aus, um ein OpenVPN damit ans Laufen zu bekommen, dabei wird OpenVPN explizit bei der Projektbeschreibung genannt. Folglich bin ich bei einer freetz-vm geblieben, nur um damit OpenVPN in ein neues Firmware Release zu bekommen.

Fazit: Ich würde es begrüßen, wenn unter dem alten Projekt einmal etwas aufgeräumt würde, so dass es für alle interessierten Entwickler einfacher wird. Ich bin zwar kein Experte in git, aber gearbeitet habe ich damit auch schon. Wenn es sich lohnt, für ein Paket (z.B. bei einen Versionsupdate) einen Pullrequest einzureichen, dann würden sich vermutlich auch andere Kräfte aus der Community wieder bereit erklären, aktiv an der Weiterentwicklung des Projektes mitzuwirken. Auf dem alten SVN als Einmanshow lohnte sich die Mühe nicht, wenngleich ich @er13 dankbar bin, dass ich mit nicht ganz aktueller Hardware von AVM immer ein freetz nach meinen Wünschen nutzen konnte.

Es gibt mit github eine moderne Entwicklungsplattform, es gibt eine gute aktuelle Dokumentation von @hippie2000 es gibt mit @PeterPawen, @er13, etc. Kompetenzen bis die Tief in die Kernelsourcen (sogar Livepatchen des Kernels fürs tun-modul) und in mögliche Strukturierungswege, fehlt nur noch die Bündelung der Kräfte in eine kooperative, einheitliche Richtung mit dem Ziel: "AVM Firmware möglichst einfach nach den eigenen Wünschen anzupassen"

PS: @cuma Die Umfrage bildet diesen Standpunkt leider nicht passend ab, daher habe ich auf ein Voting verzichtet.
 
  • Like
Reaktionen: emil70 und gnieder
Hi,

wollte das ganze mal probieren und es scheitert am Download von 'kconfig-v4.12.2.tar.xz'.
Kann das mal bitte jemand fixen.

Danke
 
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
PS: @cuma Die Umfrage bildet diesen Standpunkt leider nicht passend ab, daher habe ich auf ein Voting verzichtet.
Damit hast du herausgestellt was dir nicht gefällt. Konstruktiv wäre wenn du gesagt hättest wie es besser wäre
@HarryBoo: Das wurde weiter oben schonmal gemeldet und vor 6 Tagen mit 5a7e4550850afb7ba04f4b92fc14343aeeb9565d behoben
@Master SaMMy Wie geschrieben, dagegen hat niemand was. Kennst du dich aus, kannst du das machen?

Das klingt ja fast so, als wärst Du der Meinung, daß ich "nur rede" (und kritisiere) und ansonsten eher nichts zu Freetz beitrage
Dein Standpunkt ist doch:
-Du nutzt kein Freetz, ob fork oder nicht
-Du magst nichts beitragen, hattest du weiter oben ausführlich begründet
Backseatcoaching lehne ich ab ;-)

Wenn du möchtest dass ich GIT irgendwie anders benutze, schreib halt genau
- was blöd ist(kurz)
- wie es besser geht (kurz)
- warum es so besser ist, den Vorteil den ich davon hab (kurz)
- wie man das erreicht! (inklusive Befehle!)
- um die Änderung zu erreichen kannst du das selbst machen? Mach es
Umschreibungen "wie das geht, das geht, das natürlich auch" helfen mir gar nicht. Dazu dann evlt noch Buzzword "xyz". D

Behauptungen über mich die du aufgestellt hast lasse ich unkommentiert, was nicht bedeutet dass sie korrekt sind
 
Zuletzt bearbeitet von einem Moderator:
@HarryBoo: Das wurde weiter oben schonmal gemeldet und vor 6 Tagen mit 5a7e4550850afb7ba04f4b92fc14343aeeb9565d behoben

Hab ich gesehen, nur leider ist dieser Server nicht erreichbar bzw. eine Verbindung wird abgelehnt:
 

Anhänge

  • FNG.png
    FNG.png
    114.8 KB · Aufrufe: 22
Könnte man diesen Link benutzen ?
Code:
https://mirrors.edge.kernel.org/pub/linux/kernel/v4.x/linux-4.14.tar.xz
 
Dein Standpunkt ist doch:
-Du nutzt kein Freetz, ob fork oder nicht
-Du magst nichts beitragen, hattest du weiter oben ausführlich begründet
Falsche "Zusammenfassung" ... steht aber erst seit kurzem (nämlich seit #2) hier in diesem Thread. Den hast Du zwar "Freetz-NG" genannt, aber das kann oder soll ja wohl nicht heißen, daß hier ausschließlich diejenigen schreiben dürfen, die Deine Idee ohne jede Einschränkung "begrüßen" - zumindest habe ich diese Haltung weder bei @f666 noch bei @KingTutt in dieser Form lesen können.

Um das noch einmal deutlich zu sagen ... wenn @er13 nicht weiter macht, sollte man (genauer: will ich) das alte Freetz-Repo trotzdem weiterführen (wobei auch "weiterführen" eher eine falsche Umschreibung ist, denn bisher gab es ja (bis auf die Doku) gar keine Commits, die direkt im Git-Repository erfolgten) und ich habe Dich schon in #2 sehr deutlich gefragt, ob Du Dich daran dann beteiligen willst:
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?
Alleine bis ich auf diese Frage eine definitive Antwort (nämlich eine Absage) erhalten habe, gab es von Dir jede Menge "Rumgeeier".

Für meine Absicht, das alte Freetz-Projekt (zusammen mit anderen, auch das betone ich seit der allerersten Frage in dieser Richtung an Dich) irgendwie weiterzuführen, brauche ich auch kein Freetz benutzen ... aber auch das ist eigentlich komplett falsch in Deiner oben zitierten Behauptung, denn in #2 habe ich auch schon (wieder gleich von Beginn an und nicht erst "tröpfchenweise", wie Du das machst) deutlich ausgeführt, an welchen Teilen von Freetz ich besonderes Interesse habe (und welche Teile ich überhaupt sehe) und daß bzw. sogar wo ich meinerseits eine Aufteilung von Verantwortlichkeiten bei der Fortführung des alten Projektes für möglich und notwendig ansehe.

Das Einzige, womit Du dann tatsächlich recht hast, ist die Feststellung, daß ich zu einem Fork namens "freetz-ng" (der seine "Abstammung" verleugnet und es damit anderen "Forkern" ohne jede Not und plausible Begründung unnötig schwer macht, mit dem "alten Freetz" ebenfalls zusammenzuarbeiten, wenn das tatsächlich fortgeführt wird - denn das war und ist offenbar Deine Entscheidung, daß man "nur noch mit dem neuen Projekt" weitermachen darf, wenn man "mit Dir arbeiten" will) meinerseits nichts beitragen will, weil ich so eine Entscheidung für "nicht sachgerecht" halte bzw. bisher den "Fork" (im Sinne von "andere machen das in einer neuen Organisation weiter" - denn ansonsten ist ein "fork" im Git/GitHub ein vollkommen normales Mittel der Arbeit) zu einem "freetz-ng" für unnötig und das Ergebnis gekränkter Eitelkeiten bei Dir halte.

Da das vor Deiner "Abtrennung" des Projekts von "Freetz/freetz" in genau dieser Organisation und in diesem Repository (https://github.com/freetz-ng/freetz-ng) auch schon mal anders war, ist es nun einmal die einzige mögliche Erklärung, daß Du es - nachträglich und nachdem Du um die Möglichkeiten des direkten Austauschs wußtest, was man in #14 auch nachlesen kann:
Sieht doch gut aus.
Die Fork-Abstammung sieht man bei "Insights" zB hier https://github.com/freetz-ng/freetz-ng/network/members
- geändert hast.

Die danach angegebene Begründung "weil man sonst nicht beide forken kann" ist - wie ich weiter oben gezeigt habe - Unsinn (ich schreibe es mal so hart), weil das gar keinen Sinn ergeben würde, beide gleichzeitig zu forken bzw. weil man "alle sinnvollen Aktionen" (vergleichen, mischen) mit einem GitHub-Repo auch dann machen kann, wenn man irgendeines aus dem gemeinsamen Stammbaum verwendet.

Die einzige Verwendung für einen GitHub-Fork eines Projektes (nicht zu verwechseln mit einem lokalen Klon, den man zum Erstellen eines Freetz-Images verwendet) ist es ja, daß man selbst etwas zum geforkten Projekt hinzufügen will.

Wer etwas zu "freetz" hinzufügen will und das gleichzeitig auch "freetz-ng" zur Verfügung stellen will (oder umgekehrt), kann das aus jedem anderen GitHub-Fork von "Freetz/freetz" heraus machen und das wußtest Du ebenfalls, wie man wieder in #12 nachlesen kann:
Auf GitHub kann man wenn man "new pull request" anklickt, oben links das Ziel auswählen. Ich hab da ne ganze Latte an repos. Vielleicht geht das?
Da muß es Dich auch nicht weiter verwundern, wenn man - erst recht, wenn man Deine "Animositäten" aus früheren Zeiten im Hinblick auf Freetz und das IPPF berücksichtigt, die Du hier im Thread ja noch einmal "bestätigt" hast - nach solchen Aktionen davon ausgeht, daß Du das absichtlich so machst. Und selbst wenn das tatsächlich anders sein sollte und man Deine wiederholten Beteuerungen, daß Du eigentlich gar keinen Schimmer hast, was Du da machst, für bare Münze nehmen wollte, ist es wohl eher kein wirklich gutes Zeichen, wenn Dich dieses - von Dir selbst konstatierte - Unvermögen nicht etwa dazu animiert, Dir erst mal die notwendigen Kenntnisse zu verschaffen, sondern Du lieber unbekümmert probierst.

Insofern kannst Du Deinen Wunsch:
Wenn du möchtest dass ich GIT irgendwie anders benutze, schreib halt genau [...]
auch vergessen ... ich bin zwar "die mahnende Stimme aus dem Off" (oder meinetwegen auch vom "backseat"), aber nicht Deine Amme und wenn Du selbst so gar keinen "Ansatzpunkt" für Deine eigene Fortbildung in Sachen GitHub finden solltest, gibt es von mir tatsächlich mal die passende URL als "Einstieg": https://help.github.com/

Von da gelangt man dann zu vielen (durchaus wissenswerten) Informationen, die ich - in Auszügen - hier tatsächlich auch schon niedergeschrieben habe - aber selbstverständlich in einer "langen Form", die Dich und Deine Fähigkeiten zum verstehenden Lesen offenbar überfordert(e). Dazu gehören dann auch solche Aussagen wie diese (aus https://help.github.com/articles/github-flow/):
GitHub flow
At GitHub, we use our products every day and have developed a workflow to collaborate on projects. To make it work for teams regardless of their size or technical expertise, we made sure each step in our workflow can be completed within a web-based interface.

Following the GitHub flow
  1. Create a branch from the repository.
  2. Create, edit, rename, move, or delete files.
  3. Send a pull request from your branch with your proposed changes to kick off a discussion.
  4. Make changes on your branch as needed. Your pull request will update automatically.
  5. Merge the pull request once the branch is ready to be merged.
  6. Tidy up your branches using the delete button in the pull request or on the branches page.
Die roten Hervorhebungen sind von mir und vielleicht fällt Dir ja auch auf, daß es bei Dir die Schritte 3 und 4 irgendwie gar nicht gibt ... eigentlich nicht mal den ersten Schritt und zu dem (und dessen Gründen) kann man dann auch noch weiter "nachlesen" ... zum Beispiel hier: https://guides.github.com/introduction/flow/
ProTip
Branching is a core concept in Git, and the entire GitHub flow is based upon it. There's only one rule: anything in the master branch is always deployable.

Because of this, it's extremely important that your new branch is created off of master when working on a feature or a fix. Your branch name should be descriptive (e.g., refactor-authentication, user-content-cache-key, make-retina-avatars), so that others can see what is being worked on.
Das waren jetzt mal zwei "Zitate" aus Anleitungen zur Benutzung von Git/GitHub (ich hoffe mal nicht, daß Du zu den Leuten gehörst, die generell keine Dokumentationen lesen (wollen) oder verstehen) und selbst wenn man kein "sequentieller Leser" ist, findet man bei GitHub noch Hilfe in Form des "GitHub Learning Lab": https://lab.github.com/

Das Einzige, was garantiert nicht funktioniert (jedenfalls nicht mit meiner Wenigkeit als Part), ist das Ansinnen, alles von irgendjemandem noch einmal "vorgekaut" zu bekommen (EDIT: aber selbstverständlich "kurz") und so gar keine eigenen Anstrengungen in die eigene Qualifikation investieren zu wollen.
 
Zuletzt bearbeitet:
[Edit Novize: Beitrag wieder hergestellt - Thread-Vandalismus wird nicht geduldet!]
@gismotro: Danke, das ist aber etwas gross, es wird nur ein Teil von 134kb benötigt
@HarryBoo: Ich habs gerad bei mir versucht, geht. Bei dir geht der Verbindungsaufbau zu repo.or.cz nicht lz Screenshot. Andere downloads funktionieren? IP+Route+DNS in der VM ist okay usw?
Ich hänge die Datei mal an, sie gehört ins dl/ Verzeichnis und nach "kconfig-v4.12.2.tar.xz" *umbenennen*
@PeterPawn: machs doch mal kürzer, das kann doch nicht so schwer sein. Du kannst doch nicht ernsthaft erwarten dass man von dir täglich mehrere Seiten durchliest, mir fehlt dazu die Zeit
 

Anhänge

  • kconfig-v4.12.2.tar.xz.....zip
    134.3 KB · Aufrufe: 9
Zuletzt bearbeitet von einem Moderator:
@cuma : Danke fürs dranhängen, Nur dieser Download funktioniert nicht. Keine Ahnung warum....
 
PS: @cuma Die Umfrage bildet diesen Standpunkt leider nicht passend ab, daher habe ich auf ein Voting verzichtet.
Damit hast du herausgestellt was dir nicht gefällt. Konstruktiv wäre wenn du gesagt hättest wie es besser wäre
Das ist nicht ganz korrekt, in meinem Fazit habe ich versucht sehr deutlich zu schreiben, was ich möchte. Ich bevorzuge eine Weiterführung des originalen Freetz-Repo (aber nicht als Onemanshow) -> das entspräche in Deinem Voting "Lösch es wieder :(". Wenn das Weiterführen allerdings keine Option ist (aus welchen Gründen auch immer) dann wäre ich für Freetz-NG, was in Deinem Voting "Finde ich prima :)" entspricht. Ein "Abwarten, dann sehen wir weiter" klingt für mich nach nichts tun, was keine Option darstellt.

@PeterPawn Du hast doch irgendwas von einer Mail an die Inhaber geschrieben. Dort gibt es demnach Kontakte, die eine Entscheidung hinsichtlich Schreibzugriff auf das Repo fällen können. Da es (von außen betrachtet) bei einigen Entwicklern historisch bedingte Differenzen gibt (was völlig normal ist wenn man professionell damit umgeht) muss es doch möglich sein, einmal von @er13 einen klärenden Standpunkt zu bekommen oder? Notfalls von olistudent oder mhei...
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.