Posts by M-Reimer

    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.

    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...

    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
    1. 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
    1. git push --follow-tags


    oder einmal


    Code
    1. 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.

    Kommt drauf an wie oft das Signal auf dem Weg weitergereicht wird und dort gepuffert wird. Digitale Signale kommen meist nur mit einem gewissen "Sicherheitspuffer" aus. Analoges Fernsehen war also tatsächlich "fast Live". Beim digitalen Fernsehen bist du aber um eine gewisse Zeit "hintendran" weil fast jeder beteiligter "Posten" seinen eigenen kleinen Sicherheitspuffer hat. Und dann kommt ja auch noch einmal Laufzeit "ins Weltall und zurück" oben drauf.


    Bei der Internet-Wiedergabe kann nun durchaus sein das du direkt "am Sender" beziehst. Gut, da wird noch ein CDN dazwischen liegen (Content Delivery Network), aber das macht offensichtlich nicht so viel aus.

    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.

    Ganz ehrlich: Wenn die Projekte faktisch ungepflegt sind, dann migriere die in deinen GitHub-Account und gut ist. Wenn der ursprüngliche Autor selber keinen VDR mehr hat kann ich mir auch nicht vorstellen das er bei einer freundlichen Mail mit der Bitte das Projekt "offiziell mit seinem Segen" übernehmen zu können ein "Nein" zurückschreibt.


    Genau dafür habe ich ja mal diese Liste angeregt: https://vdr-projects.github.io/

    Wo wer seine Projekte pflegt ist seine Sache. Man muss aber einfach mal irgendwo hinschreiben wo es aktuell und aktiv gepflegt wird, denn Entwickler kommen und gehen. Jeder verliert mal an einem Projekt das Interesse (erst Recht wenn es in der Freizeit entsteht) und ein anderer übernimmt ab einem gewissen Punkt.


    Und bei einem wirklich aktiv gepflegten Projekt ist ein Review eines Pull-Request jetzt erstmal nicht wirklich ungewöhnlich. Ich reiche die auch nur selten komplett ohne "Review" durch. Erst wenn ich mit der Anpassung zu sagen wir 90% zufrieden bin nehme ich den Pull-Request an, schiebe dann aber ein/zwei "Fix-Commits" nach um aus 90% die anzustrebenden 100% zu machen. Wenn ein Pull-Request aber z.B. komplett gegen meinen Coding-Style geht und ich durch Annehmen mehr Zeit ins Reparieren stecken muss als den Fix selber zu coden, dann werde ich immer erstmal Nachbesserung fordern.

    Ich sehe jetzt nichts das sich großartig ändert sofern man bisher auch via PayPal Zahlungen angenommen hat. Und das habe ich immer gemacht, denn ausschließlich Zahlung via Überweisung ist eine gute Möglichkeit bei einer Auktion weniger Geld zu bekommen. Es ist ein zusätzliches Risiko dabei (kein Käuferschutz) und entsprechend sind Käufer auch nicht bereit so hoch zu bieten.


    Auch ebay-kleinanzeigen hat mittlerweile ein Zahlungssystem und als Käufer dränge ich immer darauf das auch zu nutzen. Ja, das kostet mich als Käufer eine Gebühr, aber ich hatte jetzt schon zwei mal den Fall wo erst der Verkäufer die Zahlung via "Zahlungssystem" abgelehnt hat und kurz danach eine Warnmail von eBay kam, dass ich keine Zahlung im Fall XY veranlassen soll weil der Verkäufer wegen "nicht versendeter Ware" gesperrt wurde.

    Keiner aus unserem Team nutzt VDR, gefühlt ist eh 3/4 zu Tvheadend gewechselt (Webinterface ist hier der Hauptgrund).

    Hab ich ausprobiert und ich muss sagen: Ich finde das Webinterface von Tvheadend ziemlich Sch💩. Der einzige positive Grund für dieses Webinterface ist, dass es existiert und direkt vom Start weg da ist. Das war es aber auch. Aus Sicht eines Webentwicklers ist hier dringend "einmal neu machen" angesagt. Wird aber auch da niemand mehr machen. TV an sich hat gerade in der "technikaffinen" Zielgruppe viel an Boden verloren. Selber aufnehmen (und eventuell sogar noch schneiden) ist einfach ein Aufwand der einem von einem Streaming-Dienst abgenommen wird.

    Fazit für uns ist solange es baut alles gut, wenn es nicht mehr geht fliegts raus.

    Schön das auch mal von anderer Stelle so zu lesen.


    Und was das gelobte github betrifft, kann man bei rofafor froh sein, wenn er in zwei Wochen überhaupt reagiert. Einen VDR hat er nicht mehr.

    Änderungen durch zu bekommen, die *notwendig* sind, ist extrem schwer, seit alles dort nur noch per github geht. Habe ich hier aufgegeben.

    Die Frage ist: Was macht GitHub an der Stelle schlechter? Man kann sich ohne viel Verrenkung einen Fork ziehen, dort so viel committen wie man lustig ist und dann über einen Pull-Request nicht nur die eigenen Commits sondern auch direkt den eigenen Namen ins Upstream-Projekt bekommen. Viel besser und einfacher kann man es doch garnicht haben.


    Und wenn der ursprüngliche Autor längere Zeit (oder gar nicht) auf einen Pull-Request antwortet? Dann committe ich einfach lustig in meinem Fork weiter und irgendwann spricht sich dann schon rum (ggf. auch nach Ankündigung hier im Forum) das das Projekt eben jetzt in aktueller Version dort zu finden ist.


    Nicht anders habe ich es mit einigen Plugins gemacht die bei vdr4arch drin sind. Wenn ein Entwickler sich mehrere Jahre nicht um sein Projekt kümmert und die Patches, die nötig sind um es zu nutzen, sich schon an verschiedenen Stellen stapeln, dann gibt es doch keine Verpflichtung das Projekt vergammeln zu lassen. Die Lizenz unter der der Quellcode veröffentlicht wurde erlaubt sogar ganz ausdrücklich eine Anpassung und Erweiterung.

    eventlirc ist nicht drauf. Was verwendet arch?

    Ich hab immer direkt mit den Event-Devices gearbeitet. Ggf. mit "input-plugin". "eventlircd" ist eine elegante Sache um viele Eingabe-Geräte unter einen Hut zu bekommen, aber yaVDR hat da wohl auch viel "Vorkonfiguration" die es alles für vdr4arch nicht gibt. Hier ist, wie bei Arch allgemein, mehr Eigeninitiative gefragt.