Beiträge von Copperhead

Da sind wir dann an einem Punkt, an dem man es einfach mal testen müsste.
Theoretisch müsste es so gehen:

- Der Entwickler (in dem Fall du) öffnet ein Issue (https://github.com/vdr-project…projects.github.io/issues), dass er Organization Member werden möchtest, wegen Plugin XYZ.
- Der Entwickler wird zum Organization Member gemacht.
- Der Entwickler überträgt sein Repository an die Organization (dadurch bleiben alte Direktlinks erhalten)
- Die Repository Owner Rechte werden an den Entwickler zurückgegeben.

Das VDR-Wiki halte ich VDR4Arch technisch schon länger nicht mehr auf dem neuesten Stand. Der aktuelle Wiki Artikel ist hier: https://github.com/VDR4Arch/vdr4arch/wiki
Und ans Arch Wiki selbst habe ich mich noch nicht rangetraut. Irgendwie habe ich da Respekt vor. Irgendwer hat da auch schon einen Link zu VDR4Arch reingemogelt.

Zitat von fnu

Was passiert mit einem Projekt, das der ursprüngliche Author nicht aufgegeben hat, aber Pullrequests nicht akzeptiert? Die Gefahr ist groß das dann von diesem Projekt "aus dieser Community" ein Fork/Mirror entsteht, den der ursprüngliche Author so durch seine Ablehnung verschiedener Pullrequests nicht authorisiert hat.

Diese Gefahr hat der Entwickler immer. Es wird durch vdr-projects.github.io auch nicht besonders gefördert.

Rein theoretisch kann ich jemanden sein Projekt auch "wegnehmen" indem ich es eben selbst vom Fremdrepository auschecke und auf Github wieder einchecke.
Hat es alles schon gegeben.

Wie gesagt ihr beschreibt hier Vorgänge, die so von der gewählten Lizenz nicht abgedeckt sind. Die GPL schützt niemanden davor, dass ihm das Projekt weggenommen wird. Kommt jemand anderes und entwickelt schneller und besser, werden die User dessen Variante bevorzugen.
Und bevor mir hier wieder die Wörter im Mund herumgedreht werden: Niemand will irgendjemandem etwas wegnehmen.

Ohh. Wow. Nerv getroffen, wie es scheint...
Das wird mir teilweise schonwieder zu persönlich angreifend. Ich antworte mal auf die Sachen, die es einer Antwort wert sind.

Zitat von wirbel

a) ob derjenige einverstanden ist, seinen Source in einem git zu führen (eine reine Kopie dort würde es ja schließlich auch tun). Und auch ein Nein akzeptieren.
git ist ein tool, das hilft dem Programmierer selbst kein Stück hilft, solange er alleine programmiert und eine Versionshistorie jeder Datei hat (egal welche Art).

Die GPL verbietet mir nicht einen Mirror anzulegen. Und da ich nur von Git Repositories bisher einen Mirror ziehe, nutzt der Entwickler bereits Git.

Zitat von fnu

Vmtl. auf das bezogen, sich aufzuschwingen als einzige zentrale Anlaufstelle für VDR Plugins zu gelten ... ?

Naja. Das ist nunmal die Ambition.

Zitat von fnu

Was ist wenn der Maintainer nicht auf github arbeiten möchte? Und gar keine Pullrequests akzeptieren möchte? Da entscheidet Ihr dann drüber was passiert?

Solange die Repositories nur Mirror sind, spielen Issues und Pull Requests keine Rolle. Es ist kein direkter Draht zum Entwickler vorhanden.

Zitat von fnu

Es sollte nicht zu einfach sein ein Plugin zu übernehmen, aktives Nachfragen mit Zeitlimits über mehrerer Monate bis zu einem Jahr würde ich als fair bezeichnen.

Na damit kann man doch etwas anfangen.

12 Monate? Jedem normalen Menschen ist es zuzumuten innerhalb von 4-8 Wochen auf eine E-Mail zu antworten (Und selbst das ist schon zu lange). Tut er das nicht, hat er meiner Meinung nach Pech. Wenn wirklich jemand da ist, der ein Plugin aktiv weiterentwickeln will, lege ich dieser Person garantiert keine Steine in den Weg. Im Wort-Case ist die Weiterentwicklung dann als Fork zu betrachten.

Ihr beschreibt hier teilweise Vorgänge, die durch die verwendete Lizenz einfach nicht abgedeckt sind.

Und nochmal um damit es wirklich bei allen angekommen ist: Diese 8 Wochen Regel, wie sie oben steht ist ein Entwurf und ist nicht auf die gemirrorten Repositories anzuwenden. Das gilt für Repositories, die kein Mirror mehr sind und die gibt es im Moment zumindest noch nicht.

Wie gesagt. Es ist erstmal als Entwurf zu betrachten.

Zitat von wirbel

Warum so kurz? Nicht jeder kann immer und überall Zeit für den VDR opfern.

8 Wochen war einfach mal von mir in den Raum geworfen. Was wäre denn deiner Meinung nach angemessener?

Zitat von wirbel

Und es gehört sich, nach Erlaubnis zu fragen. Anstandsweise.

Auf was bezogen? Bevor etwas mit dem Repository gemacht wird? Ja, da hast du Recht. Man sollte lieber nochmal Rückfragen.

Aber auch da braucht es Zeitlimits für eine Reaktion.
Längere Abwesenheitszeiten könnte man ja vorher ankündigen. Issue im Organization Issuetracker aufmachen z.B.

Mal so in die Runde gefragt.
Welche Zeitlimits für Reaktion auf Issues und Pull Requests haltet ihr für angemessen?
Und welche Reaktionszeit auf Rückfrage ist eurer Meinung nach angemessen?

English
Everything below is more or less a translation of what's already on http://vdr-projects.github.io . If you have any questions feel free to open an issue as stated on the project page or just post here in English.

Deutsch

Was ist das?

Das hier soll eine Sammlung aller VDR Plugin Repositories sein. Die meisten sind Mirrors von diversen anderen Seiten um einen zentralen Punkt zu erzeugen, an dem alle Plugins gefunden werden können.

Du mirrorst andere Repositories? Warum?

Wir sehen Pluginentwickler kommen und gehen. Speziell in den letzten Jahren sind es mehr Entwickler die gehen, als Entwickler die neu hinzukommen. Besonders problematisch ist es, dass diese nicht einfach weggegangen sind. Sie sind teilweise komplett verschwunden.

In all dieser Zeit ist die Entwicklung des VDRs nicht stehen geblieben. Und von Zeit zu Zeit sorgen neue Entwicklungen am VDR dazu, dass Plugins nicht mehr kompilieren oder sich komisch verhalten. Und selbst dazu gibt es hier in der Community Leute, die sich diesen Plugins annehmen und Patches zu Verfügung stellen.

Diese Patches sammeln sich hier im VDR-Portal an und ihr wisst ja, wie Foren sind. Es wird schnell unübersichtlich. Patches verteilen sich in unterschiedlichen Threads. Threadnamen sind nicht immer eindeutig genug, um darin Patches zu erwarten. Und da es hier hauptsächlich deutschsprachig ist schließen wir die größere internationale Community aus.
ional community.

Und wie helfen Mirrors?

Das tun sie nicht. Nicht alleine zumindest. Wir (das sind im Moment mini73 und ich) wünschen uns, dass alle (oder möglichst viele) noch aktive Pluginentwickler dieser Github Organization beitreten. Um verwaiste Plugins am Leben zu halten und noch aktive Entwicklung von dem gleichen Schicksal zu bewahren, wie das der bereits verwaisten Plugins.

Alles auf Github zu sammeln sollte auch One-Time Contributions fördern. Jeder hat heutzutage einen Github Account.

Schützen? Klingt gut? Wie soll das erreicht werden?

Github Organizations haben eine feste Hierarchie. Organization Owner ist darin die höchste Position. Werauchimmer in dieser Position ist, kann Repositories neue Owner oder Member zuweisen. Diese neuen Owner oder Member können die Entwicklung fortsetzen.

Damit keine Forks und kein Durcheinander.

Moment! Du willst, dass ich mein Plugin aufgebe?

Nein! Natürlich nicht. Wir wollen nur sicherstellen, dass die Entwicklung weiterläuft. Solange du innerhalb von 8 Wochen auf einen Pull Request reagierst, ist alles OK. Danach könnten theoretisch andere interessierte Personen dem Plugin Repository als Member hinzugefügt werden. Deine Push-Rechte bleiben erhalten. Die Löschen wir niemals. Du kannst dein Plugin zu einem späteren Zeitpunkt weiterentwickeln und kannst uns auch anweisen die hinzugefügten Personen wieder zu entfernen.

Ich möchte Kontakt mit euch aufnehmen. Wie geht das?

Öffne einfach ein Issue im vdr-projects.github.io Repository. Dort klären wir alle Themen auf Organization Ebene.

-------------------------------------------------------------------------------------------------------------------------------------------

Betrachtet das oben erstmal als Entwurf. Es ist nicht perfekt, aber nach und nach wird das schon. Ich wurde darauf aufmerksam gemacht, dass es doch besser wäre, wenn ich hier eine News dazu mache um mehr Aufmerksamkeit zu bekommen. Nun, hier ist es.
Entstanden ist das ganze in diesem Thread hier: Wie gehts es weiter mit VDR und seinen Plugins? (War: wie geht es mit VDR4Arch weiter?)

Ich weiß auch, dass einige hier im Forum mit mir persönlich nicht klarkommen. Um dem entgegenzuwirken habe ich von Anfang an gesagt, dass ich nicht alleine Organization Owner sein möchte.
mini73 war so freundlich und ist nun ebenfalls auf dem höchsten Rang in dieser Organization.

Solange wir zu zweit sind, bin ich bei Entscheidungen dafür, dass alles einstimmig passieren muss. Sollten wir noch mehr Owner hinzufügen, wäre es dann ein Mehrheitsentscheid.
Zu überlegen wäre es, ob Member auch Stimmrecht bekommen.

Zur Hierarchie:
Organization Owner > Organization Member > Repository Owner > Repository Member
Repository Owner und Member können, aber müssen nicht gleichzeitig Organization Member oder Owner sein.
Vorteil auch Organization Member zu sein: Man kann selbstständig neue Repositories anlegen.

Zitat von kls

Die original RCS-Dateien möchte ich ungern rausgeben. Wenn, dann geht es nur so, daß ich daraus per Script ein GIT-Archiv generiere und das auf meinen Server hochlade.

RCS ist so unglaublich veraltet, dass es da noch kein Skript gibt. Das müsste erst geschrieben werden.
Alles was ich finde konnte zielt darauf ab, dass man zu Git konvertiert und danach RCS nicht weiterbenutzt und auch das setzen schon auf die Ähnlichkeit zu CVS.

Wenn alle Stricke reißen müsste ich mich in RCS einlesen und ein Dummy-Repository aufbauen. Dann bräuchte ich aber ein paar Infos von dir, wie du z.B. Commits kennzeichnest, die über mehrere Dateien gehen.
RCS kann scheinbar nur Commits pro Datei und ist noch "Atomic commit"-fähig. Solltest du da aber eine einheitliche Konvention haben, z.B. sind die Commitmessages gleich, oder ähnliches könnte man daraus die passenden Commits generieren.

Zitat von kls

Das würde mich jetzt aber doch interessieren, wie man aus vergangenen Änderungen Vorhersagen für künftige Versionen machen kann ;-).

Naja. Meine Hoffnung war es, dass dadurch auch Commits von zukünftigen noch nicht veröffentlichten Versionen sichtbar werden. Sozusagen "bleeding edge"

Edit: Habe mir RCS mal genauer angeschaut. Damit arbeitest du? Wirklich? Kommt mir sehr umständlich vor.

Zitat von ludi

Ich hätte eine Frage: Kann man das erste Repo (vdr-projects.github.io) nicht irgendwie nach "VDR Projects README" umbennen? Wenn ich nicht vorher über diesen Thread auf die englische Seite mit den Erläuterungen gegangen wäre, hätte ich nicht gewusst, dass es das README ist.

Leider nein. Github legt wert auf den Repositorynamen. Ich habe aber eine Readme.md angelegt, die innerhalb des Repositories darauf hinweist, dass es das Repository für die Webseite ist.

Zitat von ludi

Außerdem, würde ich vorschlagen einen "Sticky Thread" über das neue github in der NEWS und in der International Sektion dieses Forums anzulegen.

Das ist geplant. mini73 meinte er wäre die nächsten zwei Wochen schwer zu erreichen. Entweder ich warte, bis er wieder besser erreichbar ist, oder ich schreibe selber etwas zusammen. Mal sehen.
Im Moment bin ich mit dem Projekt schon weiter als ich erwartet habe.

Ich hoffe auch immernoch an die Original RCS Daten des VDRs zu kommen. Das bekomme ich sicherlich irgendwie nach Git transferiert. In gewisser Weise ist es unnötig, aber ich bin ehrlich gesagt super neugierig auf einzelne Commits und damit auch tiefere Einblicke in die Entwicklung zukünftiger VDR Versionen.
kls hat sich hier nicht mehr wirklich geäußert, eventuell schreibe ich ihn da auch nochmal direkt an.

Auch geplant ist es, das Mirroring für ältere Plugins wieder abzuschalten und stattdessen das Github Repo als neuen Hauptzweig zu betrachten. Dann entsprechend die Patches zusammentragen.

Immernoch einiges zu tun...

So. Ich bin ziemlich durch mit den Plugins. Ist so ziemlich alles gemirrored.

Außerdem habe ich mir mal die Zeit genommen eine kleine Webseite hochzuziehen, mit einer groben Erklärung.
https://vdr-projects.github.io

Is noch nicht perfekt. Aber es ist ein Anfang.

mini73: Ich habe dir mal die Einladung geschickt. Wenn du sie annimmst bist du ebenfalls Organization Owner.

Ich denke am besten änderst du den Namen in soetwas: "Wie gehts es weiter mit VDR und seinen Plugins? (War: Wie geht es mit VDR4Arch weiter?)"

Das wird beidem gerecht.

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.

Zitat von rell

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

Zitat von kls

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

Zitat von M-Reimer

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.

Was projects.vdr-developer.org gerade so veraltet macht ist genau, dass es keine Pull Requests gibt. Und Issues verschwinden irgendwo in den Tiefen von Redmine.

Und wegen den Bedenken von Klaus. Pull Requests und ein Issue Tracker auf Github machen erstmal keinen Druck. Im Gegenteil, sie nehmen Druck. Alleine weil es auf Github sehr simpel aufgebaut ist, ist es übersichtlich und Probleme werden an Ort und Stelle gemeldet und diskutiert. Nicht in 5 verschiedenen Threads im VDR Portal und zusätzlich noch auf der Mailingliste.
RCS zu konvertieren. Notfalls auch in Read-only ist wiederum eine Aufgabe für sich. Dazu müsste man aber wirklich erstmal Zugang zum RCS Repo haben.

RCS ist 35 Jahre alt und kann scheinbar keine Commits über mehrere Dateien hinweg. Das lässt sich sicher konvertieren, die Frage ist, ob man da was sauberes hinten rausbekommt.

Github Organization könnte man ja jederzeit mit ein paar Mausklicken aufsetzen. Ein passender Name fehlt mir noch und ein weiterer Freiwilliger, der sich als "Owner" miteinträgt.
Zur Erklärung es gibt "Owner" und "Member". Member können sich selbst Repositories anlegen und haben darin automatisch Rechte über alles. Owner haben die Möglichkeit die Rechte zu editieren, anderen Rechte zu geben oder Rechte zu nehmen.

Erreichbar wäre das ganze dann z.B. über vdr-projects.github.io

Die Idee mit Github fände ich gut. VDR-Developer ist heute nicht mehr zeitgemäß. Alle Plugins (oder zumindest viele) in einer Github Organization transferierieren, bei älteren nötigenfalls auch ohne Zustimmung. Die Bedenken von mini73 verstehe ich schon, aber nur weil ein Repository unter einer bestimmten Organization gelistet ist, heißt das noch lange nicht, dass jeder auf das Repository pushen kann.

Da gibt es Rechteverwaltung und es stehen eben ein paar wenige über den einzelnen Maintainern, die bei Bedarf (zum Beispiel bei Nichtreagieren auf ein Issue in einem festgelegten Zeitraum) eingreifen können und neue Contributor hinzufügen oder theoretisch Issues direkt bearbeiten könnten.

VDR-Developer ist zu schwerfällig. Man ist heute einfach zu verwöhnt von Github. Oder von mir aus auch Gitlab oder Bitbucket. Ist ja alles ähnlich.

Ich wäre sogar bereit mich oben an die Spitze dieser Github Organization zu stellen. Vorausgesetzt ich bin da oben an der Spitze nicht alleine.

Let's agree to disagree

Zitat von fnu

Und als ob die Community nur Mist liefern würde ...

Das habe ich nicht gesagt. Das Problem an Community-Fixes ist, dass im Normalfall keine neuen Releases gemacht werden. Jedem Commit hinterherrennen ist nicht Sinn der Sache.

Mit VDR4Arch geht es klar weiter. An den Binärpaketen hänge ich alleine und das Wetter ist in letzter Zeit auch zu gut, um da viel am PC zu verbringen.

Der Fokus hat sich minimal verschoben. Direkte Ausgabe des VDRs ist von den beiden Hauptentwicklern nicht mehr getestet. Wenn Probleme aufkommen, wird klar versucht diese zu lösen, aber testen muss jemand anderes.
VDR-Entwicklerversionen bekommen keinen wirklichen Support mehr. Klaus hat da zuviel mit den Plugins kaputt gemacht, da blicke ich nicht mehr durch und viel zu viele der Plugins sind nur über Community-Patches am Leben gehalten.

Binärpakete wird es nur noch für x86_64 geben. Das hängt mit der Entscheidung von Arch Linux zusammen, dass i686 nicht mehr unterstützt wird. Ich selbst werden das kompilieren schon vor dem offiziellen Aus einstellen.
Binärpakete für ARM kommen von mir ebenfalls keine mehr. Außer eine der ARM Architekturen wird von Arch Linux direkt unterstützt. Die Abspaltung Arch Linux ARM supporte ich nicht mehr, wegen persönlichen Differenzen mit dem Hauptentwickler.

Zu deinen Fragen direkt:

Wie seahawk1986 bereits geschrieben hat, hat sich der Pfad etwas verschoben. Das war im englischen Wiki nicht angepasst, ist es jetzt aber.
Ebenso hat sich der Pfad des Repositories verschoben. Das ist aber beides schon vor über einem Jahr passiert.
Und nein. die AUR Pakete sind noch weniger auf aktuellem Stand, als die Binärpakete. Wenn du wirklich schneller sein, willst als ich mit dem kompilieren der Pakete, dann solltest du die PKGBUILDs aus dem Git Repository nehmen.

Ich hoffe das erklärt das meiste. Es geht weiter. Etwas langsamer, aber es geht weiter.

Das ist möglich. MReimer hat da einige Zeit schon reingesteckt. Wenn du im Projekt ein Issue aufmachst, sieht er das sicher.

Ich selbst nutze nur noch Kodi mit VDR als Backend und Aufnahmeplatte habe ich auch keine mehr drin. Rentiert sich nicht. Deutsch übersetzte Filme und Serien tue ich mir seit einigen Jahren nicht mehr an.
Wenn dann schaue ich gelegentlich mal einen Tatort (wenn Harald Krassnitzer mitspielt)