[mcli] Fork & Maintenance (nicht nur mcli)

  • Hallo,


    nach einem e-mail Austausch mit kamel5 meld ich mich hier mal...die aktuelle Situation mit dem verschiedenen GIT-Repos ist ja mehr als unglücklich...


    Was nun?


    Ich könnte anbieten, mich um https://projects.vdr-developer.org/git/vdr-plugin-mcli.git zu kümmern, aber so richtig zukunftsträchtig scheint mir das nicht zu sein...github ist viel flexibler und auch bei anderen Plugins findet man inzwischen interessante Forks, deren PRs oder generelle Anpassungen (falls noch kein PR existiert) integriert werden sollte, bevor das alles noch mehr zerfleddert.


    => wesentlich besser wäre, https://github.com/vdr-projects zu forcieren, da würde ich lieber mithelfen...das macht in meinen Augen wesentlich mehr Sinn..


    BTW1: paar RPM packager sind schon "übergelaufen" und paketieren Forks, weil Upstream ausaltert.


    BTW2: für graphlcd hätte ich auch schon einen PR offen: https://github.com/pbiering/vdr-plugin-graphlcd


    Servus,

    Peter

  • Hi,


    So eine Frage hatte ich auch, bei vdr-plugin-live.


    https://projects.vdr-developer.org/ : ist tot

    https://github.com/vdr-projects/ : hat sich nicht durchgesetzt.


    Ich würde einen neuen Fork auf github machen, und den dann im vdr-wiki pflegen.


    Ich erinnere mich an Diskussionen, wie lange man auf eine Antwort des Entwicklers warten muss, bevor man jemandem anderen erlaubt, auf dessen Projekt weiterzuentwickeln. Das ist aus meiner Sicht nicht zielführend. Wenn der Entwickler Patches nicht einbaut, und jemand weitermachen will, dann gibt es einen Fork. Und die Community entscheidet, welchen Fork sie verwendet.


    ~ Markus

    Client1: ASUS P5QC, Dual Core 3G, Cine S2, Ext. Board von TBE, Xubuntu 20.04, VDR 2.4x

    Client2: RPI3

    Server: RPI4, Sundtek SkyTV Dual 2x

  • "Und die Community entscheidet, welchen Fork sie verwendet." -> das mag bei Einzelanwender mit Compiler-Knowhow funktionieren, bei Packager schon weniger....die müßten dann von einem Fork zum anderen "wandern", entweder selbstgetrieben oder angestoßen...so richtig zielführend ist die komplette Dezentralität dann auch nicht...


    "https://github.com/vdr-projects/ : hat sich nicht durchgesetzt."


    Kann man das nicht wiederbeleben? Mindestens mal die Mirrors wieder aktivieren Plugin für Plugin und welche mit aktivem Kümmerer entsprechend markieren und dort die PRs einpflegen.


    Aktuell ist's ein rechtes Sammelsurium an Forks, die kann man schon in einem Wiki pflegen...da kann dann aber die Liste länger werden...

    • Upstream: verstaubt
    • Fork#A: kann X besser
    • Fork#B: kann Y besser...
    • Fork#C: versuchte A+B zu integrieren, kam nicht weiter....
    • ....

    Bisserl Zentralität mit notfalls flexibler Betreuung durch ein wachsendes bzw. wechselndes Team wäre da schon besser

  • Das mit den Mirrors ist auf einem Server von Copperhead gelaufen und der Dienst meines Wissens nach lange abgeschaltet. Eigentlich war das mit den Mirrors auch als temporäre Übergangslösung geplant.


    Die Grundidee, hier eine zentrale Anlaufstelle zu bieten, war im Prinzip nicht falsch, wurde damals aber, muss man leider so ausdrücken, mit aller Gewalt totgeredet.


    Aktuell sind wir genau an dem Stand der damals schon in den Raum gestellt wurde. Faktisch ist es sehr schwer bis unmöglich noch Commit-Rechte auf projects.vdr-developer.org zu bekommen. Eine GitHub-Organisation mit mehreren Community-Mitgliedern als "Projektleiter" wäre da deutlich einfacher handlungsfähig geblieben.


    Ich muss aktuell sagen, dass ich auch gut damit leben kann wenn jemand, der ein Projekt weiterführen will, es sich einfach in seinen GitHub-Account forkt und dort weiterführt. Meine ganzen anderen Projekte habe ich auch im Kontext von meinem GitHub-User. Ist auch irgendwie schön als OSS-Entwickler seine ganze Projektliste dort zu haben.


    "projects.vdr-developer.org" ist für mich auf jeden Fall schon auf dem Abstellgleis. "vdrnfofs" habe ich auch einfach zu mir auf GitHub umgezogen ohne noch den Aufwand zu treiben irgendwie nach langem Bitten nochmal Commit-Rechte zu bekommen.

    • vdrpbd habe ich noch parallel auf projects.vdr-developer.org. Solange das noch weiterläuft pushe ich auch dort hin. Offizielles Projekt-Repo ist aber: https://github.com/M-Reimer/vdrpbd
    • graphlcd-base hat nach wie vor seine offizielle "Basis" auf projects.vdr-developer.org. Eine Arbeitskopie liegt bei mir: https://github.com/M-Reimer/graphlcd-base
    • vdr-plugin-graphlcd habe ich Commit-Rechte auf projects.vdr-developer.org und kann ggf. Patches dort einchecken sofern sie an mich herangetragen werden. Ich kann und will das VDR-Plugin aber nicht offiziell "übernehmen" weil ich graphlcd-base selbst mit meinem Kodi-Addon nutze und mir keine Testumgebung mit dem VDR bauen will.

    Was das Wiki angeht: Ist da nicht auch der aktuelle Stand das es da faktisch keinen Admin mehr gibt?

  • Sehe gerade erst https://github.com/vdr-project…d5457984295fa3855cb68ed2a

    Schreibe mir doch bitte kurz als PM worum es genau geht. Kann ich im Prinzip direkt ins offizielle Repo pullen ohne den Umweg über GitHub zu gehen.


    Faktisch wäre vdr-plugin-graphlcd aber genau so ein Fall den ich im Prinzip gerne in einer Organisation sehen will solange sich keiner als richtiger "Maintainer" bereit erklärt. Ich kann gerne Patches kurz sichten und einbauen. Ich kann aber nicht testen was für den Job als Maintainer eher nachteilig ist. Mein "Steckenpferd" ist halt nur "graphlcd-base" mit meinem Kodi-Addon oben drauf. Da hab ich für den Lockdown sogar gerade ein neues Projekt. Es gibt da nette "moderne" grafische LCD (SPI, I2C) die ich gerne noch via Arduino mit anbinden will. Das wären dann 3/4 Leitungen zwischen LCD und Arduino. Ansteuerung vom PC via USB.


    In einer entsprechenden Organisation könnte man leicht Plugins "parken" die keiner "Vollzeit" weiterentwickeln will. Eben als Ziel für Pull-Requests ohne das jemand das Plugin "ganz offiziell" im Kontext seines Accounts braucht. Bei einfachen Fixes reicht es dann wenn jemand in der Organisation kurz drüberschaut und das dann halt ohne Testen pullt. Wenn das nicht hinhaut kann ja jemand ein Issue nachschieben und ein Commit ist ggf. auch schnell wieder rückgängig gemacht.


    Ich werde das mit der Organisation aber nicht nochmal diskutieren. An der Stelle habe ich auch keinen Bock mehr. Wenn sich hier ein Konsens findet das wir die Organisation brauchen können, dann kann ich aber im Prinzip ohne Probleme mit Copperhead absprechen das er mich als "Eigentümer" einträgt. Von da aus kann ich ggf. ein/zwei weitere Personen mit eintragen. Mirrors wird es aber nicht mehr geben. Wenn dann wird auf GitHub auch gearbeitet.


    Faktisch läuft das bei Kodi mit den PVR-Addons auch so. Solange das jemand aktiv pflegt hat er es in seinem GitHub-Account und an zentraler Stelle steht wo man den Kram findet. Bei ungepflegten Add-ons (aktuell VNSI PVR) wandern die in eine Organisation die vom Kodi-Team gepflegt wird. Nötige Änderungen bei API-Umstellungen werden da dann von Kodi-Entwicklern nachgereicht.

  • Github kann auch "Wiki"...also wäre Reaktivierung von https://github.com/vdr-projects/ wohl das einfachste, die 2 Admins davon werden wohl doch so nett sein, noch paar Admins hinzuzufügen. Dann erzeugen wir noch eine Wiki-Seite, wer sich gerade für welches Plugin zuständig fühlt und versuchen, die Forks wieder einzusammeln, notfalls über lokales git-Repo mit mehreren Upstreams (angestaubt, fork-A, fork-B) und etwas Merge-Arbeit.


    ein 2. vdr-projects-NG auf github zu starten, würde noch mehr Chaos produzieren


    Ziel wäre, zumindest für Packager (Fedora/Ubuntu) wieder einen funktionierenden Upstream bereit zu stellen, falls da mal ein PR schief läuft weil zwar merge-OK aber funktions-kaputt, wird das schneller entdeckt und dann hoffentlich auch schneller gefixt.

  • Sehe gerade erst https://github.com/vdr-project…d5457984295fa3855cb68ed2a

    Schreibe mir doch bitte kurz als PM worum es genau geht. Kann ich im Prinzip direkt ins offizielle Repo pullen ohne den Umweg über GitHub zu gehen.

    bei dem PR hat sich vor langer Zeit mal eine Inkonsistenz eingeschlichen zw. "SetupWrite" und "SetupRead"....wohl keinem aufgefallen...hat wohl noch nie jemand beim Replay das Logo deaktivieren wollen...bzw. nicht gewundert, wieso das keinen VDR-Restart überlebt...


    aktuelle setup.conf (geschrieben von "SetupWrite"...)

    graphlcd.ReplayLogo = 0

    -> "SetupRead" sucht aber nach graphlcd.ShowReplayLogo

  • Github kann auch "Wiki"...also wäre Reaktivierung von https://github.com/vdr-projects/ wohl das einfachste, die 2 Admins davon werden wohl doch so nett sein, noch paar Admins hinzuzufügen. Dann erzeugen wir noch eine Wiki-Seite, wer sich gerade für welches Plugin zuständig fühlt und versuchen, die Forks wieder einzusammeln, notfalls über lokales git-Repo mit mehreren Upstreams (angestaubt, fork-A, fork-B) und etwas Merge-Arbeit.


    Ich habe jetzt entsprechende Rechte.


    Allerdings sehe ich weniger das Problem "Forks einzusammeln" sondern eher das Problem der Dokumentation.


    Mir fällt spontan kein Plugin ein bei dem es nötig wäre "Forks einzusammeln" und wo die Entwickler entwickeln ist auch erstmal deren Sache. Solange ein Plugin eben entwickelt wird. Die Organisation steht jedem bereit der sie nutzen will und wenn ein Plugin "ungepflegt" wird, dann kann man den letzten Stand von der bisherigen Quelle ja wieder in die Organisation zurückmergen um ein einfaches Weiterpflegen zu ermöglichen.


    Ich habe mir jetzt auf jeden Fall schonmal Rechte für https://github.com/vdr-projects/vdr-plugin-graphlcd eingetragen und den Pull-Request akzeptiert. Da aktuell noch möglich ist auch auf projects.vdr-developer.org aktuell.

  • Allerdings sehe ich weniger das Problem "Forks einzusammeln" sondern eher das Problem der Dokumentation.

    Hmm, also "softhddevice" (aktuell wohl eins der wichtigsten Ausgabeplugins) hat sich ziemlich "verselbstständig", akuell wohl am besten ist der Fork-vom-Fork-vom-Fork (vdr-developer -> pesintta -> rofafor -> ua0lnj)


    https://github.com/ua0lnj/vdr-plugin-softhddevice (was z.B. von Fedora paketiert wird)


    Man sollte auf github wenigstens das Wiki aktivieren und dort eine Liste führen, für welches Plugin welcher Fork aktuell am besten ist...


    Quote

    und wenn ein Plugin "ungepflegt" wird, dann kann man den letzten Stand von der bisherigen Quelle ja wieder in die Organisation zurückmergen um ein einfaches Weiterpflegen zu ermöglichen.

    Hmm, es sollte eigentlich das Bestreben der Entwickler (und der Organisation) sein, soviel wie möglich (und auch relativ zeitnah) die Änderungen in den Upstream zurückzumergen (um auch doppelte und dreifache Entwicklung zu vermeiden), notfalls in Branches, nicht nur bei "ungepflegt"...siehe oben, bei Fork-von-Fork-von...müßten die PRs schon einen langen Weg zurücklaufen...und wenn dazwischen ein ungepflegter Fork dazwischen liegt, wird's nicht einfacher.


    ...aber vielleicht ist meine Sicht altersbedingt etwas angestaubt...

  • Zum github Wiki, der ist leider etwas eingeschränkt, z.B. keine Tabellen :(


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Tabellen sind schon möglich (vgl. z.B. https://github.com/yavdr/yavdr…/Available-output-plugins), aber je nachdem welche Auszeichnungssprache man nutzt (die Tabelleist mit org-mode in emacs entstanden, was die Formatierung wesentlich erleichtert), kann das etwas nervig werden, das ordentlich zu halten.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Hmm, es sollte eigentlich das Bestreben der Entwickler (und der Organisation) sein, soviel wie möglich (und auch relativ zeitnah) die Änderungen in den Upstream zurückzumergen (um auch doppelte und dreifache Entwicklung zu vermeiden), notfalls in Branches, nicht nur bei "ungepflegt"...siehe oben, bei Fork-von-Fork-von...müßten die PRs schon einen langen Weg zurücklaufen...und wenn dazwischen ein ungepflegter Fork dazwischen liegt, wird's nicht einfacher.


    ...aber vielleicht ist meine Sicht altersbedingt etwas angestaubt...

    Wenn es einen Entwickler gibt und der nicht vorhat sein Repository im Kontext der Organisation zu führen oder zumindest dort aktuell zu halten, dann hat die Organisation mit dem Plugin nichts am Hut. Deshalb ja auch mein Plan die ganzen Mirrors auf "Archived" zu setzen mit Hinweis auf die tatsächliche "Heimat" des Plugins.


    Sowie ein Entwickler mal nicht mehr erreichbar ist, oder verkündet das er die Pflege nicht fortführen will, kann man so ein Plugin in die Organisation "umziehen" (nochmal aktualisieren, "Archiviert"-Status runternehmen) um Community-Mitgliedern hier zu ermöglichen Pull-Requests hinzurichten die dann ggf. von einem Mitglied der Organisation auch akzeptiert werden können um das Repository auf diesem Weg (also ohne eindeutigen Maintainer) aktuell zu halten. Und davon gibt es bei projects.vdr-developer.org noch einige. Wenn ich mal langeweile habe würde ich für das eine oder andere mal Patches von yaVDR einsammeln und ins Repo auf github.com/vdr-projects pushen.


    Und zumindest aus meiner Sicht gibt es noch genau ein Repo in dem softhddevice gepflegt wird: https://github.com/ua0lnj/vdr-plugin-softhddevice

  • Hi,

    Jojo pflegt seinen Fork auch noch.

    Mfg Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068
    www.easy-vdr.de

  • Gehört zur softhd* Familie :)


    vdr-User-# 755 to_h264 chk_r vdr-transcode github

  • Mag sein. Stimmt schon. Aus ursprünglich "softhddevice" sind zwei Zweige entstanden die nun aber in verschiedene Richtungen weiterentwickelt werden. Ich sehe da keinen Bedarf die zusammenzuführen. Wenn überhaupt, dann müsste die Initiative vom Entwickler einer der Zweige kommen.

  • Ich wäre auf jeden Fall sehr dankbar, wenn klar wäre welcher Zweig für meinen externen Reel Netceiver der richtige ist... od ist das ohnehin klar.

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD

    The post was edited 2 times, last by gggggg ().

  • Mein letzter Stand zu dem Thema (etliche Jahre her) ist, dass irgendwo mindestens ein Fehler in das mcli-Plugin gewandert ist und CAM-Support ab einem bestimmten Punkt auch tot war. Mir ist keine Version bekannt die noch stabil laufen würde.


    Wenn überhaupt müsste jemand, der entsprechende Kenntnisse und die passende Hardware hat, hier grundlegend überarbeiten. Welcher Stand ist also wohl weitgehend egal weil recht wahrscheinlich ist, dass keiner zuverlässig läuft.


    Aktueller Stand dürfte also sein: mcli-Plugin nicht mehr empfehlenswert. Was meiner Erfahrung nach ganz gut geht ist libmcli (gebaut aus dem offiziellen SVN von Baycom) zusammen mit minisatip. Damit kann man vom proprietären Netceiver-Protokoll auf SatIP wandeln und das dann mit den satip-Plugin auch am VDR nutzen.

  • Nachtrag nach Vergleich der Repos:

    Das hier scheint vor kurzem erst Commits bekommen zu haben: https://github.com/pbiering/vdr-plugin-mcli/commits/master


    Ich habe hier mal einen Kommentar hinterlassen:

    https://github.com/vdr-project…/1#issuecomment-765481397


    Vielleicht hat "pbiering" ja Interesse das Plugin weiter zu pflegen. In dem Fall würde ich Commit-Rechte für vdr-projects/vdr-plugin-mcli einrichten.

  • Ich glaube ich habe gemeinsam mit cinfo vor Weihnachten raus gefunden, dass mit minisatip der CAM Slot des Netceivers mit Alphacrypt+ORF-Karte nicht funktioniert hat.

    Im Allgemeinen (zappen und wenn es mal läuft) funkioniert es, aber es kommt zu VDR Crashes im Zusammenhang mit EPGsearch wenn der NUC zum Aufnehmen startet.

    Liebe Grüße g ;-)

    BM2LTS V2.94.4, ext.NCV+AlphacryptCAM+ORFkarte, AVG1 T7400 RAM4GB SSD+HDD2TB NvidiaGT720, NCL2 mit HDD