https://github.com/vdr-projects/ teilweise wiederbelebt

  • Also rein technisch gesehen hat er seinen Fork bereits als solchen gekennzeichnet indem er diesen in seinem GitHub-Account abgelegt hat. Und ich stimme in soweit zu, dass ich die Verlinkung bei vdr-projects.github.io (noch) nicht auf den Fork zeigen lasse.


    Meine Definition von "ungepflegtes Plugin" ist, dass es nicht mehr mit aktuellen VDR-Versionen gebaut werden kann. Wenn mal für über ein Jahr bei einer größeren VDR-Distribution (also nicht vdr4arch) ein Patch rumliegt der zwingend nötig ist, der Entwickler den aber nach über einem Jahr nicht in einen neue Version eingebaut hat, dann wird es meiner Meinung nach Zeit eine aktualisierte Version irgendwo abzulegen um den Patch mal "Distributions-neutral" bereitgestellt zu haben.


    Das neue Plugin "vdr-clock" ist aufgenommen. Wegen Addons habe ich auch schon nachgedacht da was aufzunehmen aber noch ist das Ziel erstmal alle Plugins zu erfassen.


    Wegen "vdr-plugin-cinebars": Mir letztlich egal wo das weiter gepflegt wird. Aktuell habe ich das bereits auf https://github.com/vdr-projects/vdr-plugin-cinebars angelegt. md_berlin sag mal bescheid ob du lieber in deinem Benutzerkontext weiterentwickeln willst oder gerne Commit-Rechte auf das vdr-projects Repo möchtest. Wenn du in deinem Kontext weiterentwickeln willst würde ich die Verlinkung anpassen und auf vdr-projects löschen.

  • ein Patch rumliegt der zwingend nötig ist, der Entwickler den aber nach über einem Jahr nicht in einen neue Version eingebaut hat, dann wird es meiner Meinung nach Zeit eine aktualisierte Version irgendwo abzulegen um den Patch mal "Distributions-neutral" bereitgestellt zu haben.

    Ich finde es besser, den Entwickler zu bitten das Problem zu lösen, anstelle deswegen einen weiteren Fork anzulegen. Ist doch nicht sooo schwer, Kontakt aufzunehmen.

  • M-Reimer Genau so. Oder eben eine umbenannte Version als Fork unter Beibehaltung der History auf github anlegen, z.B. "vdr-plugin-undeleteng".


    Das ist genau der Fall den man vor Jahren diskutiert hat, nur weil ein Entwickler nicht gitxxx verwenden möchte oder zeitlich nicht so arbeitet wie es einigen in den Kram passt ...

    HowTo: APT pinning

  • Und vor allem für den fork *eindeutige* Namen verwenden, die nicht implizieren ein Update des originalen Source zu sein, z.B. 'w_scan' vs. w_scan2'.

  • Das mag jeder so handhaben wie er es für richtig hält aber für mich gilt: Umbenannt wird nicht. Wenn ein Plugin z.B. schon 3 Jahre ungepflegt rumliegt, mit aktuellen VDR-Versionen gar nicht mehr kompiliert und auch eine Kontaktaufnahme erfolglos war (nach angemessener Wartezeit von sagen wir einem Monat), dann sehe ich persönlich da überhaupt keinen Grund warum man ein Plugin nicht unter dem ursprünglichen Namen weiterpflegen soll.


    Für die "vdr-projects"-Organisation auf GitHub habe ich das für mich so festgelegt, dass ich bei Plugins, die ich nur "auf Zuruf" aktuell halte und nicht selber "Maintainer" sein will dann jeweils nur die letzte Versionsstelle ("Revision") hochzähle. Dann wird das dann halt irgendwann im schlimmsten Fall eine Version "1.0.1234" geben. Hintergedanke: Wenn der ursprüngliche Maintainer wieder einsteigen will, dann muss er lediglich einmal die zweite Versionsstelle erhöhen und schon ist eine klare Trennung wieder gegeben.


    Ich reiße mich nicht um Arbeit. Erst recht nicht im VDR-Bereich. Was ich da noch mache ist durchgehend für andere Leute. Ich nutze VDR faktisch nicht mehr! Ich hatte lediglich die Idee das es vielleicht ganz praktisch wäre mal den ganzen Patch-Verhau, den es mittlerweile gibt, mal irgendwie zu "kanalisieren". Wenn der ursprüngliche Maintainer sich meldet, dann bin ich der erste der liebend gerne das "Zepter" wieder abgibt.


    Das ewige "-ng" oder was weiß ich finde ich eher nervig und unübersichtlich. Aber es sei jeden gegönnt da ein "-ng" anzuhängen. Entscheidend ist das Funktionalität, die noch gebraucht wird, irgendwie nachvollziehbar weitergepflegt wird. Die Info "XXXX ist alt, XXXX-ng ist neu" ist aber dann nicht unbedingt für jeden direkt klar.

  • Meine Definition von "ungepflegtes Plugin" ist, dass es nicht mehr mit aktuellen VDR-Versionen gebaut werden kann. Wenn mal für über ein Jahr bei einer größeren VDR-Distribution (also nicht vdr4arch) ein Patch rumliegt der zwingend nötig ist, der Entwickler den aber nach über einem Jahr nicht in einen neue Version eingebaut hat, dann wird es meiner Meinung nach Zeit eine aktualisierte Version irgendwo abzulegen um den Patch mal "Distributions-neutral" bereitgestellt zu haben.

    Wenn ich für ein Plugin, dessen Original-Homepage noch verfügbar ist, genau EINEN Patch habe, damit es für den aktuellen vdr compiliert/funktioniert, wäre es dann nicht sinnvoller nur diesen einen Patch zu verlinken (zusätzlich zur Original-Homepage) ?

    Auch bei dieser Lösung kann ich den Original-Author anschreiben und bitten die Patche zu übernehmen, danach ist es auch leicht auf der Liste wieder auch "Active Maintainer" zu ändern.


    Beispiel: https://madmartin.github.io/vdr-projects.github.io/ plugin epgsync

  • Nein. Das war genau der Punkt warum diese GitHub-Organisation eigentlich ins Leben gerufen wurde. Schluss mit dem Patchwust. Was ist denn wenn für eine zukünftige VDR-Version weitere Änderungen nötig werden? Zwei Patches? Neuer Patch? Wer erstellt den? Wie kommt diese Info dann wieder auf der Plugin-Liste an?


    Wenn das Plugin an sich wieder an einer Stelle gehostet ist, wo man darauf Zugriff hat, dann gibt es für interessierte wieder ein Ziel wo man auch mal ein Pull-Request hinschicken kann. Oder wegen mir den Patch in ein Issue hängen.


    Edit: Wegen epgsync: Das Limit "Zeit um Patch zu übernehmen" ist da auf jeden Fall durch. Wenn kein anderer schneller ist würde ich später eine kurze Mail schreiben mit der Bitte doch eine Version abzulegen die den nötigen Patch enthält.

  • Ok, klares Statement.

    Ich bin durchaus dafür lieber früher als zu spät ein "Fork" auf einer "öffentlichen" Plattform (sf.net, Gihub, Gitlab usw.) anzulegen, die auch ein längeres Motivationsloch oder ungeplante Abwesenheit bis him zum Tod des Besitzers überlebt. (Bin da etwas sensibel, habe letzteres schon 2x erlebt).

    Nur sehe ich an der ersten Reaktion auf meinen ersten Beitrag daß manche Leute das einfach nur dreist finden. Damit muss ich wohl leben.

  • M-Reimer Was gibt Dir das Recht darüber zu entscheiden? Das ist nicht nur dreist, sondern schon unverschämt.


    Wie wirbel schon geschrieben hat, kann es nicht zuviel Aufwand und nur fair sein zu versuchen den/die orig. Author(en) zu kontaktieren. Bin mir ziemlich sicher da wird es kaum negatives Feedback geben.


    Aber aus Faulheit sich hinzustellen, zu sagen mir gefällt nicht dass der orig. Author das auf einem Server mit dyndns Domain hostet, und sich dann das Recht rauszunehmen den Code einfach zu übernehmen geht gar nicht. Zumal z.B. phintuka im VDR Umfeld bekannt ist und bis heute aktiv ist ...


    Ok, klares Statement.

    Absolut falsches Statement!

    HowTo: APT pinning

  • Vor allem wüsste ich jetzt doch gerne mal wo genau die Stelle in einem meiner Postings ist, wo ich behauptet habe, dass ich Projekte "übernehmen" wollte (was ich sowieso nicht will. Deshalb ja die Organisation um ein ungepflegtes Projekt ohne Personenbezug "zu parken") nur weil die in dyndns-Kontext gehostet sind. Und vielleicht dann auch meine zwei letzten Postings nochmal lesen wo ich explizit genau gesagt habe, dass erstmal der ursprüngliche Autor über das Problem informiert werden sollte.


    Mich würde ja mal ganz persönlich interessieren wie oft fnu so Plugins, oder den VDR an sich, selber kompiliert.

  • S:oren Denke Du bist der deutschen Grammatik mächtig und siehst den Unterschied zwischen Frage und Statement?


    Mich würde ja mal ganz persönlich interessieren wie oft fnu so Plugins, oder den VDR an sich, selber kompiliert.

    Na klar, wenn sonst nichts hilft ... geht Dich zwar nichts an, aber erst dieser Tage wieder. Daher weiß ich auch das "vdr-plugin-undelete" weder für VDR 2.4.8 noch für 2.6.0 einen Patch benötigt.


    Am Ende ging's drum das md_berlin sich nichtmal die Mühe gemacht hat "phintuka" zu kontaktieren. undelete ist dessen Plugin, nicht ungepflegt, es gibt aktuell einfach keinen Bedarf was zu ändern. Und es ist sein Recht das Plugin so zur Verfügung zu stellen wie er möchte, der genannte Server ist seit 10 Jahren+ zuverlässig online.


    Ausserdem hat Petri mir vor Jahren mal gesagt, das er undelete als "use-as-is" zur Verfügung stellt, anders als xineliboutput. Insofern bin ich mir sicher, wenn man nett fragt, ist ein Hosting via github überhaupt kein Problem ...


    Vor allem wüsste ich jetzt doch gerne mal wo genau die Stelle in einem meiner Postings ist, wo ich behauptet habe, dass ich Projekte "übernehmen" wollte ... dass erstmal der ursprüngliche Autor über das Problem informiert werden sollte.

    Dann würde ich vorschlagen genau zu lesen was ich geschrieben habe. Nicht das Du die Projekte übernimmst, sondern irgendjemand, durchaus auch ohne Zustimmung, ein reines Informieren ist zu wenig.


    Deiner vehement vertretenen Meinung zum Thema werde ich nie zustimmen.

    HowTo: APT pinning

  • Am Ende ging's drum das md_berlin sich nichtmal die Mühe gemacht hat "phintuka" zu kontaktieren. undelete ist dessen Plugin, nicht ungepflegt, es gibt aktuell einfach keinen Bedarf was zu ändern.

    Erst mich direkt ansprechen und dann allgemein weiterschreiben. Ist zumindest nicht sofort klar wer gemeint ist. Jetzt mit der Erklärung aber schon.


    Nicht das Du die Projekte übernimmst, sondern irgendjemand, durchaus auch ohne Zustimmung, ein reines Informieren ist zu wenig.

    Ab irgendeinem Punkt muss man einmal davon ausgehen das eine Weiterentwicklung nicht mehr stattfinden wird. Und wie schon erwähnt geht es bei einer Übernahme in die vdr-project-Organisation erstmal um ein "am Leben halten". Der ursprüngliche Entwickler kann von dort dann ggf. zu späterem Zeitpunkt wieder ansetzen und, dank sauber getaggter Commits, ggf. nach eigenem Ermessen auch unerwünschte Features wieder rückgängig machen oder nur das eine oder andere Feature, das er übernehmen will, als Patch rausziehen. Sieh doch einfach die neuen Commits "on Top" als Patches und wer gerne das "Ganze" will klont eben das Repo.


    Mail wegen epgsync ist raus mit kurzer Erklärung der Situation, Link zum Patch und Bitte nach neuer Version. Zusätzlich Hinweis, dass ggf. Übernahme als "Community-Projekt" möglich wäre falls keine Weiterentwicklung mehr geplant ist. Selbst unter ehemalig aktiven VDR-Entwicklern ist ja eine Abwanderung gegeben. Und sei es nur weil Streamingplattformen immer mehr das "reguläre Fernsehen" verdrängen.

  • M-Reimer

    ich bin dir sehr dankbar das du dich der Sache angenommen hast.

    So hat man bald nur noch einen Ort wo mal alle Plugins findet, denn jetzt ist es manchmal wirklich mühsam das zu finden was man sucht.

    Trotzdem verstehe ich natürlich auch die Bedenken von fnu.

    Ich glaube in der "Mitte" liegt der richtige Weg, und werdet ihr finden.

    Danke für die Mühe

    speed

  • Hier mal meine Sichtweise (ich bin deutsch, also sehr direkt. Ich möchte aber niemanden verletzten. Also fühlt Euch bitte nicht angegriffen):

    • Jeder darf einen Fork machen, jederzeit und aus welchen Gründen auch immer
    • Jeder der selbst compiliert, kann und darf entscheiden, ob er die Originalsourcen oder den Fork (oder einen anderen Fork, ...) verwenden möchte
    • Jeder, der ein Repository für andere bereitstellt / für andere compiliert, darf entscheiden, welche Sourcen (original, Fork1, Fork2, ...) er dafür verwenden möchte
    • Jeder, der eine Liste von Sourcen zusammenstellt, darf entscheiden, welche Sourcen er in diese Liste mit aufnehmen möchte
    • Jeder, der eine Liste von Sourcen verwendet, darf entscheiden, welche Liste von Sourcen er verwenden möchte


    O.K, das war jetzt alles richtig, aber trotzdem zu einseitig. Musste aber mal gesagt werden. Die andere Seite stimmt natürlich auch:

    Natürlich ist es besser zu reden, als einen Fork zu machen. Einfach aus Höflichkeit, und um Doppelarbeit zu vermeiden. Aber wenn jemand einen Fork machen oder verwenden möchte, spricht da nichts dagegen. Und ich habe tatsächlich Lars gefragt, bevor ich einen Fork von vdr-plugin-dynamite angelegt habe. Lars Antwort war:

    Quote

    Ein eigenes Repository kannst du immer machen, ist ja GPL. Ich hab auf GitHub mein "Mutter"-Repository. Kannst es ja forken und einen Pull Request machen.

    Also, es ist sicher gut, höflich, respektvoll und hilfreich, wenn wir miteinander reden. Falls jemand aber einen Fork macht oder verwendet, ohne zu reden, dann darf er das auch machen.


    ~ 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

  • Seit GitHub ist der Begriff "fork" ohnehin etwas "verwässert". Meine Projekte werden praktisch täglich "geforkt". Aber nur ganz ganz selten gibt es auf den Forks dann auch Commits. Viele nutzen den "Fork"-Button bei GitHub auch um für interessante Projekte eine "Sicherheitskopie" zu ziehen. Besonders freue ich mich aber natürlich wenn aus so einem Fork irgendwann ein Pull-Request zurück kommt.

  • Den fork darf man natürlich machen (solange die Lizenz passt, also z.B. für alle GPL Projekte), aber es ging darum wer die Quelle des Projekts mit den Namen 'vdr-foobar' ist. Einen fork zu machen und unter gleichem Namen als neue Quelle des Projektes anzubieten, das halte ich für nicht OK.


    Andererseits muss man sogar forks machen, wenn man bei git pull requests erstellen will. Und wer GPL verwendet, stimmt der Weiterverwendung des Codes ausdrücklich zu.

  • So ist es. Es kann aber durchaus Einschränkungen geben bezüglich der Namensnutzung. Viele GPL-Projekte haben (wenn sie größer sind) die Namen als Warenzeichen eintragen lassen.


    Nachtrag: http://tvdr.de/legal.htm

    Selbst "VDR" ist ein eingetragenes Warenzeichen. Streng genommen kann Klaus also z.B. sagen "Das verpatchte Ding darf nicht unter dem Namen "VDR" verbreitet werden".

  • So. Mal ein Nachtrag zum Thema "epgsync". Ich zitiere mal direkt aus der Mail:


    Quote

    Zur Not kann ich schon eine neue Version erstellen. Da ich aber keinen Entwicklungs-VDR zum Testen habe und auch in den Foren nicht mehr aktiv bin, wäre es vermutlich das sinnvollste, meine Plugins auf Github abzulegen. Gleiches gilt für streamdev, falls da noch niemand einen Fork angelegt hat. Für streamdev hätte ich auch noch zwei Patches offen, die mir zugesandt wurden, ich aber mangels Testmöglichkeit noch nicht eingepflegt habe.


    Also kann man so rein vom Prinzip her erstmal alles von https://vdr.schmirler.de/ als "ungepflegt" annehmen.


    Kann mir jemand sagen ob es für "remotetimers" noch einen Einsatzzweck gibt? Kann der VDR mittlerweile selber, oder?


    Den Rest würde ich dann erstmal auf https://github.com/vdr-projects anlegen. Es sei denn es gibt für einzelne Plugins bereits aktiv gepflegte Forks von denen ich nichts weiß. In dem Fall würde ich direkt auf die neue "Heimat" verlinken und spare mir das Anlegen eines neuen Repositories.


    Wegen der in der Mail angekündigten Patches: Die würde ich erstmal, mangels Testmöglichkeit meinerseits, als Pull-Request für das Plugin anlegen und dann hier zur Diskussion stellen. Nur bei "OK" wird das übernommen.


    Am liebsten wäre mir aber natürlich wenn ich für die neuen Repos direkt Maintainer mit Commit-Rechten eintragen könnte. Ich kann dabei unterstützen Plugins "kompilierbar" zu halten. Mehr aber nicht. Wer neue Features will muss schon selber mit einsteigen :P