Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

  • Ja, Github hat das schön ins Portal integriert. Aber nur deswegen ist Redmine nicht schlecht.


    Aber schlechter. Erst noch eine Nachricht schreiben mit Anrede und allem. Außerdem ist es so nicht öffentlich einsehbar. Potentiell könnte die gleiche Arbeit doppelt gemacht werden, weil nicht ersichtlich ist, dass das schonmal jemand gemacht hat und es einfach nur noch nicht eingepflegt wurde.

  • Moinsen,


    ich bin zwar kein Entwickler, aber in einigen Open Source Themen unterwegs. Neben VDR ist das auch noch kodi, emby, fhem, proxmox und openmediavault. Gefühlt ist die Entwicklung in Kombination mit Github strukturierter und auch für Nicht-Entwickler (wie mich) besser nachvollziehbar. Beim vdr bin ich froh, dass es etobis repo gibt. Mit den ganzen Patches aus der Community, die nirgends wirklich gesammelt werden, komme ich einfach nicht mehr hinterher. Es fällt mir schwer mich an dieser Entwicklung zu beteiligen, da ich nicht einfach ein git clonen kann und so die aktuellste Version bekomme.


    Ich würde mich sehr freuen, wenn ihr den vdr und die nötigsten Plugins zu github bekommt oder irgendwo zumindest mal eine zentrale Anlaufstelle etabliert.


    So die Sicht eines VDR-Users...


    Unabhängig davon finde ich es klasse, dass ihr an dem VDR dran bleibt. Zwischenzeitlich hatte ich schon das Gefühl, dass es das bald mit meinem treuen Gefährten war. Aber seit von VDR 2.3.x die Rede ist, habe ich wieder Hoffnung, ;)


    Schönen Abend noch und Gruß Hoppel

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8

  • Ach ja, noch was: GIT (wie wohl auch andere) speichert die Source-Dateien in irgend einem binären Format! Das geht schon mal gar nicht! Ich will ein Archiv-File für ein Source-File, und das Archiv muss lesbar sein!

    Ähm. Da kann ich dir irgendwie gerade nicht ganz folgen.


    Das ist nicht irgendein binäres Format. Das sind Binary-Deltas. Das machen alle Distributed VCS so.


    Edit: Dich zwingt ja auch niemand Git zu nutzen. Es wäre schön, ja. Aber wenn du RCS behalten willst, dann behalte das. Da wäre es aber dann trotzdem schön, wenn das komplett öffentlich einsehbar wäre.
    Konvertierung dann eben Read-only nach Git.


    Edit2: Ich habe übrigens mal https://github.com/vdr-projects gesichert. Nur für den Fall, dass man dort wirklich anfangen möchte Plugins zu sammeln.


    Edit3: Ich habe das gerade nochmal gegengeprüft. Es ist wirklich so. https://github.com/vdr-projects/vdr-epgsearch z.B. stünde unter der "Schirmherrschaft" der vdr-projects Organization. Owner ist weiterhin der jeweilige Entwickler. Sollte der spurlos verschwinden hat die Organization die Möglichkeit dort einen zusätzlichen Owner zu benennen (theoretisch auch den alten rauszuwerfen, aber das fände ich nicht OK).

  • Bugfixes und Verbesserungsvorschläge nehme ich gerne als Patches an, behalte mir aber die Entscheidung über deren Einbau jeweils vor.


    "Pull requests" und dergleichen würde ich darüber auf keinen Fall annehmen.


    Widerspricht sich das nicht ? Das ganze als Patch per Email zu schicken ist doch im Endeffekt die Langatmige, komplizierte, intransparente und aufwendige Art eines Pull Requests. Einzig das dies komplett im verborgenen passiert ist der Unterschied. Ob das bei einem OSS sinnvoll ist weiß ich nicht - eigentlich lebt man ja vom offen Austausch.


    Ich will ein Archiv-File für ein Source-File, und das Archiv muss lesbar sein!


    Alle Daten liegen immer als normale source file auf der Platte und kann mit jedem x-beliebigen Programm bearbeitet werden (auch gepackt, gelöscht etc). Nur die Versionierung wird in einem Binären Format gespeichert.
    In Git kann ich jeden einzelnen Commit oder Branch oder Tag der jemals gemacht wurde auschecken und daraus ein Archiv erzeugen -> github ist da noch viel einfacher https://github.com/FernetMenta/VDR/archive/fe94035.tar.gz z.B. - lädt mir den Stand des Commits fe94035 herunter (geht natürlich auch mit release tags etc).



    Ein "Pull-Request" ist ganz förmlich eine Anfrage, von einem anderen Repository zu pullen. Das kann ich über jeden beliebigen Weg machen.
    ...
    Aber nur deswegen ist Redmine nicht schlecht.


    Du sagst ja im Endeffekt das kompliziert, aufwendig und verborgen besser ist als einfach, schnell und transparent. Ich mein man kann ja zugucken das es nicht klappt. Wenn es klappen würde wäre man nicht an der jetzigen Punkt.
    Ziel ist es möglichst alle Schwierigkeiten und Probleme aus dem Weg zu räumen und die Mitarbeit so einfach wie möglich zu gestalten als aus Angst mit der Zeit zu gehen absichtlich Steine in den Weg zu werfen.


    Wie läuft denn sowas normalerweise ab:
    Ich hab ein Fork in Github (weil ich da ja eh schon bin) und mache irgend einen Patch.
    Ist die Repo auf Github: da mach ich einen Pull Request und bin nach einer Minute fertig - ggf kann man beim PR noch diskutieren etc - alles völlig transparent auch wenn es keinen Maintainer mehr gibt.


    Ist die Repo im vdr-dev: Da melde ich mich erstmal dort an nachdem ich per google die Repo gefunden habe, dann versuche ich in Kontakt mit dem Repo Inhaber zu kommen, der meldet sich nach 1-2 Monaten dann endlich und fügt evtl das entsprechende ein.
    Wenn es kein Maintainer mehr gibt passiert genau nichts und niemand kann meine Änderungen sehen. Im optimal Fall antwortet der Inhaber innerhalb eines Tages - die gesamte Kommunikation ist natürlich völlig verborgen und intransparent.


    Jetzt erklär mir mal warum vdr-dev besser bzw gleich gut ist wie github und warum sich intransparenz positiv auf OSS auswirkt.


  • Du sagst ja im Endeffekt das kompliziert, aufwendig und verborgen besser ist als einfach, schnell und transparent.


    Nein. Worauf ich hinaus wollte, ist, dass es mehrere Wege gibt zum Ziel zu kommen. Der Issue-Tracker von projects.vdr-developer.org ist z.B. komplett öffentlich einsehbar.

  • Copperhead
    Wenn sich bis Mitte Juni keiner gemeldet hat, können wir beide es gerne mal zusammen versuchen, die GitHub-Organisation auf die Beine zu stellen. Man müsste sich dann mal eine handvoll Regeln überlegen, wie man in welchen Fällen vorgehen will.


    Lars.

  • Edit3: Ich habe das gerade nochmal gegengeprüft. Es ist wirklich so. https://github.com/vdr-projects/vdr-epgsearch z.B. stünde unter der "Schirmherrschaft" der vdr-projects Organization. Owner ist weiterhin der jeweilige Entwickler. Sollte der spurlos verschwinden hat die Organization die Möglichkeit dort einen zusätzlichen Owner zu benennen (theoretisch auch den alten rauszuwerfen, aber das fände ich nicht OK).


    Hast du dazu Dokumentation gefunden, wie das mit der "Schirmherrschaft" funktioniert?
    Ich finde die Idee gut!

  • Hast du dazu Dokumentation gefunden, wie das mit der "Schirmherrschaft" funktioniert?

    In die GitHub-Spezialitäten für die Verwaltung von Nutzern, Teams und Organisationen kannst du dich hier einlesen: https://help.github.com/catego…-organizations-and-teams/

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Klasse Sache Jungs! ;)

    frontend software - android tv | libreelec | windows 10 | kodi krypton | emby for kodi | vnsi
    frontend hardware - nvidia shield tv | odroid c2 | yamaha rx-a1020 | quadral chromium style 5.1 | samsung le40-a789r2 | harmony smart control
    -------------------------------------------
    backend software - proxmox | openmediavault | debian jessie | kernel 4.4lts | zfs | emby | vdr | vnsi | fhem
    backend hardware - supermicro x11ssh-ctf | xeon E3-1240L-v5 | 64gb ecc | 8x4tb wd red | raid-z2 | digital devices max s8


  • Wenn sich bis Mitte Juni keiner gemeldet hat,


    Was wären denn grob die Anforderungen? Könnte anbieten, mich einzubringen...


    Gruß Andreas

  • Wenn sich bis Mitte Juni keiner gemeldet hat, können wir beide es gerne mal zusammen versuchen, die GitHub-Organisation auf die Beine zu stellen. Man müsste sich dann mal eine handvoll Regeln überlegen, wie man in welchen Fällen vorgehen will.

    Ich würde vorschlagen, es auf englisch zu machen, um die Verbreitung des VDR auch außerhalb des deutschsprachigen Raumes zu fördern.

  • Was wären denn grob die Anforderungen? Könnte anbieten, mich einzubringen...


    Die Anforderungen sind relativ gering. Die Idee ist ja, dass nur im äußersten Notfall eingegriffen wird.
    Ich würde mir wünschen, dass man sich vorher auf Regeln einigt, wann so ein Eingriff gerechtfertigt ist und wer die Entscheidung dazu trifft. (Abstimmung unter den Organization Membern?)


    Um es wirklich als eine zentrale Anlaufstelle zu haben auch für Repositories, die nicht innerhalb dieser Organization laufen sollen, würde ich bei mir auf dem Server einen Cronjob laufen lassen, der das täglich synchron hält. (Mirror). In der Beschreibung würde dann "Mirrored from ..." stehen und Issuetracker etc. sind für diese Repos abgeschaltet.
    Damit hätte man vom Start weg schonmal eine Sammlung an Plugins, bei denen die Repositories aktuell sind. Damit ich da auch nicht fälschlicherweise als Repository-Owner drinstehe würde ich speziell für diesen Zweck einen Bot-Account bei Github anlegen, der dann nur fürs Mirroring zuständig ist.


    Englisch ist für mich OK. Ich hätte es wahrscheinlich zweisprachig gemacht. Also Deutsch und Englisch

  • Auch wenn eine Organisation bei Github erstmal kein Fehler ist, sehe ich nach wie vor hier nicht das Problem, das zu lösen ist.


    Letztlich könnt ihr und solltet ihr den potentiellen Entwicklern nicht vorschreiben welches "Tool" sie zu verwenden haben. Und wenn jemand sein Plugin nicht in einer zentralen Organisation will, dann eben nicht.


    Was wirklich fehlt ist eine Auflistung, wo man welches Plugin aktuell bekommen kann. Gerade wenn ein Plugin in den Status "ungepflegt" geht, könnte man hier dann einfach zum Repo des neuen Entwicklers linken.

  • Hört sich doch gut an. Ohne cronjob/ mirroring wird das (jedenfalls am Anfang) nicht funktionieren.


    Was wäre denn so ein "Eingriff"? Solange man erstmal nur versucht, die Plugins aus den Entwicklerrepos zu sammeln und aktuell zu halten, bedarfs ja keiner Eingriffe.


    Wenn sich ein Entwickler dazu entschließt, in dieser github-organization zu entwickeln, sollte der volle/alleinige push-Rechte haben.
    D.h. bleibt nur der Fall übrig, wenn jemand einen Patch pushen will und es keinen aktiven Plugin-Maintainern/ Entwickler mehr gibt. Hier halte ich mindestens ein 4-Augen-Prinzip für notwendig. Man kann sich ja da nach dem Kernel richten, ala acked-by, tested-by, reviewed-by etc.
    Falls der Maintainer eines Plugins noch aktiv ist, ist sowieso vorher eine Absprache mit ihm notwendig, obs beim mirroring bleiben soll, oder man anbietet, die neue Platform zu nutzen. Jedenfalls sollte es nicht so sein, dass durch so eine Organisation Entwickler ´"übergangen" oder "enteignet" fühlen.


    Gruß Andreas


    EDIT:

    Zitat

    Was wirklich fehlt ist eine Auflistung, wo man welches Plugin aktuell bekommen kann.


    Die Auflistung wäre ja dann das Abfallprodukt, wenn man sich die Repos zentral auf github spiegelt. Ich habe das auf meinem privaten gitserver auch so gemacht. In der Beschreibung kann man ja die Ursprungsadresse hinterlegen. Die ganzen streamdev-Addons z.B. gibt es nicht als Versionsverwaltung - ich habe sie zumindest nicht gefunden. Da würde ein commit einem neuen Release entsprechen. Dafür muss man dann aber wohl manuell nachhelfen.

  • In Git kann ich jeden einzelnen Commit oder Branch oder Tag der jemals gemacht wurde auschecken und daraus ein Archiv erzeugen

    Muss man lokal nicht ausschecken, geht direkt:


    Code
    #/> git archive [Commit SHA] | xz > ../vdr-plugin-epgsearch-[Commit SHA].tar.xz ... oder
    #/> git archive [TAG] | bzip2 > ../vdr-plugin-epgsearch-[TAG].tar.bz2 ... oder
    #/> git archive [BRANCH] | gzip > ../vdr-plugin-epgsearch-[BRANCH].tar.gz ... oder auch
    #/> git archive HEAD | xz > ../vdr-plugin-epgsearch-head.tar.xz


    Jedes Tree Element kann man natürlich mit jedem Komprimierer verwenden ... :)


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

  • Vielleicht sollte man den Thread inzwischen umbenennen und/oder verschieben. Hat ja nichts mehr mit vdr4arch zu tun. Der Thread sollte eher "Wie gehts es weiter mit VDR und seinen Plugins" heißen. Denn die Frage stelle ich mir seit geraumer Zeit auch. Mir scheint irgendwie die Nutzergemeinde stark geschrumpft zu sein, oder kommt mir das nur so vor? Zumindest wenn man hier im Forum mal die aktiven Benutzer beobachtet. Ich kann aber auch nicht die Downloadzahlen der einzelnen Distris beurteilen.


    Ich persönlich nutze noch vdr-2.2, weil einige Plugins, die ich nutze unter 2.3 nicht mehr liefen und ich ehrlichgesagt auch keine Lust mehr hatte, zich Threads zu zich Plugins und Patches zu durchforsten. Daher wäre mir alles an einem zentralen Ort, wie github, auch lieber. Mit vdr-developer.org bin ich nie so richtig war geworden. Geht man beispielsweise auf http://www.vdr-developer.org/ kommt bei mir erstmal garnichts, außer eine leere Seite, also muss man erstmal das Forum oder das Wiki bemühen. Github ist da irgendwie deutlich schicker und intuitiver und wenn dort auch noch alle funtionierenden Plugins für die VDR stable und dev Versionen lägen - ein Traum.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Ich habe mal ein Skript geschrieben, das bei mir jetzt erstmal 3 Repositories von projects.vdr-developer.org auf Github mirrored.
    Das könnte man dann nach und nach weiter ausbauen und hätte damit schonmal das Thema "Zentrale Anlaufstelle" erledigt.

  • Vielleicht sollte man den Thread inzwischen umbenennen und/oder verschieben. Hat ja nichts mehr mit vdr4arch zu tun.

    Ja, das stimmt wohl, gibt nun 2 Möglichkeiten:


    - Wir lassen den Thread so wie er ist, benennen ihn um und verschieben ihn nach "VDR Plugins"?


    oder


    - Ich splitte den Thread etwa ab Klaus' erstem Post, die Frage zu "vdr4arch" lassen wir als Thread stehen und verschieben den Rest als neuen Thread nach "VDR Plugins"?


    Es wird aber ein recht harter Schnitt, weil der Übergang der Diskussion recht weich von einem Thema zum anderen erging ...


    Regards
    fnu

    HowTo: APT pinning

    Einmal editiert, zuletzt von fnu ()

Jetzt mitmachen!

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