VDR 2.4.7 für Arch, vdr-projects.github.io, TravisCI und ein paar andere Gedanken

  • Was die Bitte betrifft ein Projekt zu übernehmen; ja. Wie viele Projekte kann jemand übernehmen? Eines, zwei, drei..?

    Das war mal der Gedanke für die GitHub-Organisation "vdr-projects". So liegen Projekte eben nicht in einem Benutzer-Kontext, es wird aber einfacher wichtige Patches auch ins Projekt zu bekommen ohne direkt einen festen "Verantwortlichen" zu benennen. Und wenn sich das dann später jemand als "zukünftiger Maintainer" ins eigene Profil forkt und dort pflegen will, dann wird halt in https://vdr-projects.github.io/ aktualisiert.


    Ich hab jetzt schon einige Plugins ohne große Rücksprachen da angelegt. Wenn sich der Entwickler wieder melden sollte kann er gerne die dort angelaufenen Commits in sein Repo pullen und ab dem Stand weitermachen. Ich zähle dann nur noch die letzte Stelle der Version ("Revision") hoch um es dem ursprünglichen Entwickler ggf. einfacher zu machen wieder mit seinem Versionierungs-Schema anzuknüpfen. Mache ich aber nur wenn ein Plugin mehrere Jahre ungepflegt liegt, was bei den von dir genannten Plugins wohl nicht so ist. Mein Gefühl sagt mir man sollte ggf. mal nachfragen ob das OK ist.

  • Noch ein Problem mit git ist - man verschwendet zusätzlich neben den angesprochenen Problemen allein 50% der Zeit nur für git.


    Googeln, wie, man sein remote repo wieder hinbiegt, nachdem der letzte push schief gegangen ist. Ein tag wird nicht per push übertragen, wie sonst alles.

    Die Suchmaschine findet alles - auf hunderten Seiten jedesmal mit unterschiedlichen Befehlen. Und auf github kann man ein repo nicht einfach löschen und neu anlegen - es ist in dem Account dann mehrere Monate gesperrt.


    Ok, das ist alles nur eine Meinung bzw. praktische Erfahrungen.

  • Noch ein Problem mit git ist - man verschwendet zusätzlich neben den angesprochenen Problemen allein 50% der Zeit nur für git.

    Da stimme ich zu. Git ist teilweise schon etwas komisch. Wenn ich z.B. mein lokal letztes Commit "ungeschehen" machen will google ich auch heute noch jedes mal nach "git undo last commit". Wenn jemand ein gutes "Git-Cheatsheet" kennt, dann immer her damit :P


    Googeln, wie, man sein remote repo wieder hinbiegt, nachdem der letzte push schief gegangen ist.

    Wenn du der einzige Beitragende bist könnte eventuell ein git push -f bereits die Lösung des Problems sein.

    Ein tag wird nicht per push übertragen, wie sonst alles.

    Tags, die Versionsmarker sind, als "annotated tags" anlegen:


    Code
    git tag -a '1.0.0' -m 'Version 1.0.0'


    Und ab dann hast du die Wahl. Entweder immer dann wenn Tags "mit hoch" sollen folgendermaßen pushen:


    Code
    git push --follow-tags


    oder einmal


    Code
    git config --global push.followTags true


    und ab dann werden "annotated tags" immer direkt mit gepusht.

    Und auf github kann man ein repo nicht einfach löschen und neu anlegen

    Auch hier: git push -f regelt. Was auch immer in dem Repo aktuell drin ist: Mit einem "Force-Push" bekommst du einen beliebigen lokalen Stand "drübergebügelt".


    GIT hat definitiv seine Schwächen, aber eben auch viele Stärken. Und die "alltäglichen Aktionen" sind eigentlich doch relativ intuitiv gemacht.

  • >>Wenn jemand ein gutes "Git-Cheatsheet" kennt, dann immer her damit


    Ich bastle mir mein eigenes als 'git gist'. Dann hat man alles dort wo man es braucht.


    @git push -f:


    git push -f origin HEAD^:master


    entfernt den letzten pull, macht man das mehrmals und checkt, kommt man ganz sauber zurück ohne die History zu verbeulen.

  • Wenn ich z.B. mein lokal letztes Commit "ungeschehen" machen will google ich auch heute noch jedes mal nach "git undo last commit".

    Es gibt hervorragende Frontends für Git wie Magit (für Emacs), die einem vieles abnehmen können, sobald man git gut genug kennt, um zu wissen, was man tun will - eine Möglichkeit wäre ein Rebase, der Commits entfernt - hier mal ein Beispiel-Workflow (das geht natürlich noch schneller, wenn man die Tastenkürzel kennt und nicht die Texte des Menüs für dritte zeigen will):

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne Ihre Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklären Sie sich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Ich nutze git täglich - ich google auch regelmäßig nach Sachen, die ich nicht häufig mache.

    Wie bei jedem neuen Tool. das man erlernt, verbraucht man anfangs mehr Zeit dafür. Aber das gibt sich irgendwann. Wenn das Ziel aber eine "saubere Historie" ist, dann sollte man mit Branches arbeiten und beim Merge die Commits dann squashen, damit man einen "sauberen" Commit hat.

    Oder man committed halt erst dann, wenn man soweit ist - das ist Geschmackssache.


    Ich persönlich sehe auch kein Problem darin, wenn man mal was falsches eingecheckt hat, dass man das mit einem späteren Commit wieder bereinigt.

    Aber da darf jeder so arbeiten, wie er will. Man muss sich nur einig sein, wenn man zusammen an einem Repository arbeitet. Wenn da jemand einfach wieder Commits verschwinden lässt, die andere evtl. schon gepullt haben, dann handelt man sich mehr Ärger als nötig ein.

  • Erstmal zu git...

    Wenn man mal das Wichtigste verinnerlicht hat, funktioniert git super.

    Mit "git add ." "git add -p" "git commit" "git rebase -i" "git reset" "git push" "git pull" kommt man schon recht weit.

    Und die ausgefalleren Sachen, und wenns bloß darum geht, einzelne Änderungen wieder in die Staging Area zu setzen, muss ich auch immer wieder googlen, da würde in der Tat ein kleines privates cheatsheet helfen ...

    Ich möchte git nicht mehr missen und wenn man sich bei der Zusammenarbeit mit anderen an ein paar Regeln hält, funktioniert auch das. Was mal in einen Hauptbranch/master gepusht wurde, bleibt da. Ein Rebase erzeugt da nur Chaos und Ärger bei denen, die schon gepullt haben. Das wäre aber auch schon die wichtigste Regel...


    Und jetzt meine Meinung zur Gesamtsituation ... :)

    Ich sehe das Grundproblem nicht bei Git oder nicht-Git. VDR bzw. eigentlich seine Plugins haben einfach das grundlegende Problem, dass die Hierarchie fehlt, die es bei größeren Projekten (libreelec, mesa, kernel etc.) gibt. Maintainer und Reviewer. Und es fehlen klare Regeln, an die sich jeder halten MUSS. Ohne die funktioniert es nicht und es bleibt beim Chaos, dass man den richtigen fork und die patches nicht mehr findet. Jetzt bin ich wirklich auch lange dabei. Überwiegend als Nutzer, aber auch hier und da mal mit etwas Code und wage zu behaupten, dass ich Linux, VDR und C einigermaßen gut verstanden habe. Aber auch ich tat mich vor einigen Monaten beim Wiedereinstieg schwer, mir erstmal einen Überblick zu verschaffen, was gerade so Sache ist. Da liest man einige Threads hier durch und kann sich auch nicht sicher sein, ob das, was im Wiki steht, noch aktuell ist.


    Die angesprochenen Regeln würde ich folgendermaßen definieren:

    /* Wunschvorstellung an */

    1) Es MUSS eine zentrale Stelle geben, an der sämtlicher VDR Code zu finden ist, z.B. https://github.com/vdr-projects

    2) Es gibt keine Mirrors dort, sondern ALLE Plugins, zu denen wer-auch-immer noch beisteuert, liegen dort im Original und die Leute, die sich drum kümmern haben commit Rechte. Das Plugin MUSS dort sein Hauptrepository haben. Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen, oder er findet jemanden, dem er seinen Patch schickt, der halt dann den PR stellt. Patches hier ins Forum zu stellen ist ja schön, bringt aber m.E. gar nichts, wenn man sich nicht gerade mit dem Thema beschäftigt. Ein Issue auf Github mit dem Patch wäre schon besser, als hier im Forum versteckt. Dann wäre er zumindest schon mal in der richtigen Gegend. Der Riesenvorteil von git, den ich sehr schätze, ist, dass man einen PR reviewen, testen und kommentieren kann. Man kann ihn verändern lassen und wenn man dann zufrieden ist und er auch wirklich läuft, wird er eingecheckt. Die Diskussion könnte zwar hier im Forum auch stattfinden, aber das ist nicht wirklich komfortabel. Klar, damit das alles klappt, brauchts erstmal Leute, die sich kümmern. Das Hauptproblem an sich.

    3) Plugins, die nicht mehr gepflegt werden, offensichtlich nicht genutzt werden, oder evtl. gar nicht mehr laufen, MÜSSEN entfernt werden. Ich wäre da rigoros. Wenn jemand etwas vermisst, meldet er sich schon. Oder er legt selbst Hand an und reaktiviert das Plugin. Ich weiß auch, dass die Hemmschwelle dafür ziemlich hoch ist und vielen das Know-How fehlt oder sie nicht bereit sind oder die Zeit haben, sich das nötige Wissen anzueignen. Jammern lasse ich aber nicht gelten. Jeder hat mal angefangen. Ein Plugin, das nur einer nutzt, kann so wichtig nicht sein. Und wenn es mehrere am laufen haben wollen, steigt ja theoretisch die Chance, dass einer dabei ist, der gewillt ist. Ansonsten kann er ja auch betteln gehen. Dafür braucht er eine Anlaufstelle, wobei wir indirekt beim nächsten Punkt wären.

    4) Das Wiki ist schön und gut aber man kann sich nicht sicher sein, ob da alles stimmt. Also ist es defacto unbrauchbar. Als Beispiel, ich war dabei, als linux-sunxi.org erstellt wurde. Da gab es zwar harte Regeln für alle, die sich einbringen wollten oder Hilfe benötigten, aber am Anfang hat das richtig gut geklappt und das wiki war in Top Zustand. Mittlerweile verwässert alles, viele Seiten sind outdated. Liegt daran, dass das Wiki gewachsen ist, die Disziplin nachlässt und schlichtweg die Motivation und Zeit der "Maintainer" fehlt, da mal wieder aufzuräumen. Die sunxis laufen mittlerweile einfach, ohne dass man notwendigerweise dem Wiki beisteuert. Aber ich behaupte mal, dass es die mainline kernel Unterstützung ohne dieses Wiki und dessen Disziplin nie gegeben hätte. Aber das nur so am Rande. Was bleibt als Anlaufstelle?

    5) Das Forum. Ich persönlich schätze es sehr. Alleine schon wegen des Umgangstons miteinander. Das war zu Zeiten von linvdr teilweise noch anders :) Jeder bekommt hier Hilfe, sofern man auch etwas Eigeninitiative erkennen kann. Und sei es nur, dass ein Log gepostet wird.

    Im Forum MUSS aber klar ersichtlich bzw. schnell zu finden sein, wo man aktuelle Plugins findet bzw. wo es eine aktuelle Liste (z.B. https://vdr-projects.github.io/) gibt und wie eigentlich die Regeln so sind...

    6) Jeder hält sich an diese Regeln. Wäre schön, aber wird schwierig. Alle? verbliebenen Entwicklern kümmern sich um VDR in der Freizeit, der Code steht unter der AGPL, warum soll sich also jemand in ein "Korsett" zwingen lassen? Ich stelle aber mal die Behauptung auf, dass es für die Zukunft von VDR besser wäre, sich selbst ein Korsett zu verpassen. Und nein, ich sehe das Ende von VDR noch nicht am Horizont. Ich bin einer, der VDR nachwievor für lineares Fernsehen und als Videorekorder nutzt.

    /* Wunschvorstellung aus */


    Ein Beispiel zum Schluß: softhd*

    Hier wurde damals leider eine klare Übergabe/Übernahme der Originalversion versäumt, so dass es mittlerweile 3,5? Forks gibt. Es gibt auch mindestens 4 Personen, die sich aktiv damit beschäftigen. Sicher ist jeder Fork für sich eine Bereicherung, aber schöner wäre es natürlich gewesen, alles in einem einzigen Plugin zu haben, was sicher möglich gewesen wäre, da sich einiges überschneidet und wofür git bzw. github o.ä. die richtige Wahl gewesen wäre. Aber leider ist es dafür zu spät, der Aufwand ist wohl zu groß. Wie alles andere, was ich geschrieben habe, soll das natürlich keine Kritik sein.


    Fazit:

    Für ein Fazit reicht es nicht mehr :) Ich hab auch keines. Auch keine Lösung. Ich möchte mich aber auch nicht beschweren. Bei mir funktioniert alles was ich nutze (softhddevice, streamdev, epgsearch, live, markad, tvguideng, skindesigner). Und diese 7 Plugins kann ich mir auch zusammensuchen oder patche selbst...


    Gruß

    Andreas


    PS: Nachdem ich nochmal durchgelesen habe, was ich geschrieben habe, muss ich gestehen, dass ich mich bis jetzt selbst auch nicht immer an diese "Regeln" gehalten habe :)

    Einmal editiert, zuletzt von rell ()

  • @ 1) Es MUSS eine zentrale Stelle geben, an der sämtlicher VDR Code zu finden ist,

    Die gab es einmal, vdr-wiki, alles mit Links und Details zu den aktuellen Versionen. Niemand wollte sich darum kümmern.


    @ 2) Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen,

    Das wäre wohl der Ende der Mitarbeit so mancher hier. git eine echte Hürde.


    @ 6) der Code steht unter der AGPL

    Wohl der absolut wenigste code hier.


    GPL: If you publish the software, you have to do the same for the source code of it and any library that it borrows functions from.AGPL: If your software gives service online, you have to publish the source code of it and any library that it borrows functions from.

  • @ 2) Wenn jemand beisteuern will, MUSS er sich einen fork ziehen und einen PR stellen,

    Das wäre wohl der Ende der Mitarbeit so mancher hier. git eine echte Hürde.

    Möglich. Es kann aber auch eine Chance sein. Möchte sich jemand outen, für den git ein absolutes No-Go wäre? git funktioniert nur, solange jemand damit arbeiten möchte.... und git löst nicht das Problem, dass überhaupt jemand daran arbeiten möchte.


    @ 6) der Code steht unter der AGPL

    Wohl der absolut wenigste code hier.


    GPL: If you publish the software, you have to do the same for the source code of it and any library that it borrows functions from.AGPL: If your software gives service online, you have to publish the source code of it and any library that it borrows functions from.

    Richtig, Fehler von mir.

  • Nein, kein absolutes No-Go.


    Aber ich z.B. mache Pull-Requests nur noch, wenn ich selbst von diesem riesen Aufwand profitiere.

    Ein paar Zeilen als diff in einem Thread als Tipp sind einfach, sich durch den ganzen Aufwand mit git zu quälen eine andre Hausnummer.

  • Klar, der Pull-Request macht auch nur Sinn, wenn es was zu diskutieren gibt und auch mindestens einen zweiten gibt, der das auch anschaut. Für ein diff, bei dem entweder alles klar ist oder eh niemand drüberschaut, ist ein pull request auch übertrieben. Ich mache bei meinen eigenen Commits auch keinen PR vorher, wenn niemand sonst beteiligt ist. Wichtig ist nur, dass das diff es halt irgendwie in den Code schafft und nicht im Forum auf die Rente hofft.

  • Einen diff wird es nach deiner Vorstellung nicht geben.

  • Solange es jemanden gibt, der ihn aufgreift, wäre das schon auch ok. Und dass meine "Wunschvorstellung" schwierig bis gar nicht umzusetzen ist oder Optimierungsbedarf besteht, wie man es am besten macht, ist mir auch klar. Am Ende wird es eh an der Manpower scheitern. So oder so. Und nicht, dass mich jemand falsch versteht - ich persönlich kann damit leben, wie es jetzt ist. Die "Wunschvorstellung" in die Praxis umzusetzen ist mit sehr hohem Aufwand verbunden, der es wahrscheinlich nicht wert ist - es geht ja auch anders. Irgendwie ;)

  • Aber ich z.B. mache Pull-Requests nur noch, wenn ich selbst von diesem riesen Aufwand profitiere.

    Ein paar Zeilen als diff in einem Thread als Tipp sind einfach, sich durch den ganzen Aufwand mit git zu quälen eine andre Hausnummer.

    So unterscheiden sich die Erfahrungen mit GIT. Bei mir genau andersrum. Ich finde "einfach diff" viel aufwändiger. Nehmen wir an ich habe einen Quellcode als ".tar.gz" und will da mit "klassischen" Methoden ein "schönes" diff draus machen. Das bedeutet ich packe das einmal aus in ein Verzeichnis "a" (Ursprungsstand) und kopiere dann dieses rekursiv nach "b" (da ändere ich) um später mit "diff -U 8 -pr" ein Diff zwischen beiden Verzeichnissen zu fahren.


    Zumindest ich mache da mittlerweile echt lieber direkt im ausgepackten Quellcode ein "git init" gefolgt von "git add *" und "git commit -a -m 'blah'". Jetzt nach belieben ändern und mit "git diff" ein sauberes Diff rausfahren. Wenn der Ursprung schon GIT war spare ich mir ja sogar das ganze "init" und muss nur clonen...

  • 1) Es MUSS eine zentrale Stelle geben, an der sämtlicher VDR Code zu finden ist

    Wird so nie passieren und ist wahrscheinlich auch besser so. Ein VDR-Plugin ist ein Open-Source-Projekt wie jedes andere auch. Und zumindest ich muss ganz ehrlich sagen: Ich hab meine Projekte schon gerne alle im Kontext meines GitHub-Users. Viel wichtiger ist die "zentrale Liste" wo eingetragen ist was wo liegt. Und auf das Wiki vertraue ich da nicht mehr. Mein letzter Stand ist, dass es da aktuell keinen Admin gibt und bedingt durch diverse Bugs gar nicht mehr alles funktioniert. Eben deshalb https://vdr-projects.github.io/. Liegt bei einem "großen Hoster" und im Prinzip kann sich jeder über Pull-Request oder Issue ein Plugin "zuweisen" lassen.


    Ich sehe in der "vdr-projects"-Organisation eher eine "neutrale Instanz" um Plugins da zu parken für die sich keiner den "Projektleiter" auf die Fahne schreiben will. Dort hätte man das Repo unter Kontrolle und auch heute ist es schon so das nicht alles auf eine Person gestützt ist, sondern mehrere im VDR-Portal bekannte Personen sind "Organisationseigentümer". Das bedeutet natürlich nicht das das Projekt "umziehen" muss wenn sich jemand aktiv drum kümmern will. Es laufen jetzt schon ein paar Plugins in der Organisation die für mich den Status "aktiv gepflegt" haben (so auch in der Liste vermerkt). Bei solchen Projekten trage ich für mich dann auch die Benachrichtigungen komplett aus und überlasse das Thema komplett dem eingetragenen "Maintainer".

    3) Plugins, die nicht mehr gepflegt werden, offensichtlich nicht genutzt werden, oder evtl. gar nicht mehr laufen, MÜSSEN entfernt werden. Ich wäre da rigoros.

    Eher Aufgabe der Distributoren. Statt ohne bekannten Mehrwert weiterhin auch die exotischsten Dinger zu pflegen vielleicht einfach mal mit etwas "Mut" das eine oder andere "temporär rauswerfen" und abwarten ob jemand nachfragt. Ich kann da aber auch bisschen nachvollziehen das es nicht gemacht wird. Wenn ich mal bisschen Langeweile habe hab ich auch schon Plugins "gefixt" und das obwohl ich die nun wirklich nicht mehr nutze. Ich hab auch Plugins nach "vdr-projects" übertragen ohne die selber jemals genutzt zu haben.

  • Schritt git diff
    Git account erstellen
    email addr anlegen, github account o.ä. erstellen
    --
    Quellen holen
    git clone <foo> wget <addr>
    Auspacken -- tar xf <foo>
    Kopieren für diff -- cp -r <foo> <foo2>
    ---work--- 1:1 1:1
    Diff erstellen
    -- diff -Nru <foo> <foo2> > patch.diff
    commit git commit -m <MESSAGE>
    (wir sind hier schon fertig..)
    push git push
    (wir sind hier schon fertig..)
    pull request
    siehe github.. Und vor allem WAAARTEN
    (wir sind hier schon fertig..)
    Wünsche des Autors durchkauen
    siehe github. evtl rebase, erneuter pull request, patch ändern,... (wir sind hier schon fertig..)
  • Hinkt der Vergleich nicht ein wenig?


    Bei der git-Variante kannst du den Feedback-Loop genauso weglassen wie beim diff. Und wenn man dann noch bedenkt, dass man einen Account nur einmal erstellen muss, gibt es eigentlich keinen relevanten Unterschied mehr.


    Und wo ist das Hochladen des Patches? Oder soll der nur für den Eigengebrauch sein? Wenn ja, dann kann das git commit/push natürlich genauso entfallen.

  • Na klar. Jeder Vergleich hinkt, und auf der git seite fehlt vorher noch je ein git status und git config -l, wenn man mehrere repos hat. Sonst dreht man extra Runden.

  • Wenn man sich das Git-Repo holt, ist das Erstellen eines Patches wesentlich kürzer als wenn man sich den Tarball holt:

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Das aber hat doch nichts mit

    Zitat

    So unterscheiden sich die Erfahrungen mit GIT. Bei mir genau andersrum. Ich finde "einfach diff" viel aufwändiger.

    zu tun.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!