Die Pakete für VDR4Arch sind jetzt auch aktuell. EIn kurzer Testlauf mit Kodi und VNSI-Server sieht gut aus.
Wenn Probleme mit den restlichen VDR-Plugins auftreten bitte im Issue-Tracker melden. M-Reimer oder ich kümmern uns dann.
Die Pakete für VDR4Arch sind jetzt auch aktuell. EIn kurzer Testlauf mit Kodi und VNSI-Server sieht gut aus.
Wenn Probleme mit den restlichen VDR-Plugins auftreten bitte im Issue-Tracker melden. M-Reimer oder ich kümmern uns dann.
Ich bin der Maintainer der VDR Paket im AUR. Das sind unregelmäßige Syncs vom VDR4Arch Projekt.
VDR4Arch wird tatsächlich noch weiterentwickelt und wird im Moment für VDR 2.4.0 angepasst.
Ich wurde heute auf diesen Thread aufmerksam gemacht. Ich schließe mich M-Reimer an.
Ich hatte ja schon letztes Jahr irgendwann mal angeboten bei Bedarf das RCS Repository von Klaus voll automatisiert in ein Git-Repository zu konvertieren.
Wenn es da nichts gibt, schreibe ich eben etwas. Das ganze kann dann auch gerne auf meinem Server als Cronjob laufen. Da läuft sowieso noch das Mirror-Skript für die VDR-Plugins und das bereitet mir auch keine Schmerzen.
Was ich erwartet habe? Ich wollte damit das letzte bisschen VDR archivieren. Ich selbst nutze überhaupt kein VDR Backend mehr. Alleine der zusätzliche Aufwand das einzurichten rentiert sich für mich nicht.
Live-TV schaue ich nur noch in Ausnahmefällen und dafür reicht der interne Tuner in meinem Fernseher.
Seit dem Deutschlandstart von Netflix schaue ich täglich Filme und Serien dort. Was ich will, wann ich will und in welcher Sprache ich will.
Den Rest der Zeit fülle ich mit Twitch auf.
447377: Das kann so nicht ganz richtig sein. Erstmal sollt es gar kein network.service geben. Es gibt ein network.target. Dieses zeigt aber nur an, dass jetzt ein Service da ist, der sich um das Netzwerk kümmert. Das network-online.target zeigt an, dass jetzt auch tatsächlich Netzwerk da ist.
Muss ich das noch irgendwo eintragen oder sollte systemd das automatisch über eine Namenskonvention finden ?
Nein. Das Skript einmal ausführen und fertig. Spätestens bei nächsten Reboot weiß systemd Bescheid.
Und angenommen, ich würde mal noch mehr Geräte an die Octopus Bridge stecken, muss ich dann das vdr-gensddropin noch mal machen ?
Theoretisch: Ja. Praktisch: Nicht unbedingt. Also nur wenn die neuen Karten nicht langsamer sind als die vorhandenen.
OT: Ich bin teilweise echt verwundert, wie viele Tuner ihr braucht. So toll ist doch das deutsche Fernsehprogramm überhaupt nicht.
Warum nicht RCS -> CVS -> Git ? Das ist zwar extrem bekloppt aber sollte gehen, es gibt RCS -> CVS importer und CVS -> Git klappt ja auch.
Die ganze Doku für RCS -> CVS ist zwar richtig alt aber das sollte ja trotzdem noch gehen auch wenn heute schon CVS veraltet ist. Das sollte sich ja auch automatisieren lassen.
Im schlimmsten Fall hätte ich selbst etwas programmiert. Aber das alles kann nicht funktionieren, wenn man von Klaus keinen Zugang zum RCS Repository bekommt.
Ich habe ja nix dagegen, wenn er das Git Repository bei sich selbst hosten möchte. Aber zuerst brauche ich mal vollständigen Zugang zu irgendeinem RCS Stand von dem aus ich dann eine Lösung zur Echtzeitkonvertierung finden kann. So das Klaus weiter mit RCS programmieren kann, aber alle anderen trotzdem Zugriff auf ein modernes VCS haben.
Mein Dozent an der Hochschule legt uns nahe, dass wir so oft wie möglich gut getestete Bibliotheken nutzen sollen. Begründung: Je weniger Code man selber schreibt umso weniger Fehler kann man machen.
Ahh. Also programmieren wir ab jetzt auch alles mit z.B. Boost. Wird ja häufig verwendet, ist also gut getestet.
Sollte github ein Spiegel sein, oder besser das neue master?
Eigentlich lieber das neue Master.
Sollte ich entsprechend das Projekt auf vdr-developer.org schließen?
Das ist dir überlassen. Wir zwingen niemanden. Das wollen wir auf keinen Fall. Es soll einfach nur Entwickler und Community näher zusammenbringen.
Wie bekomme ich die nötigen Zugriffsrechte auf das entsprechende github Projekt?
Mehr oder weniger so wie hier beschrieben. Nur das übertragen geht nur bei Github-internen Repositories.
Kann ich die Wiki Seiten eins-zu-eins umziehen?
Ja, das geht. Redmine unterstützt Textile und Markdown. Das kann Github unter anderem auch.
Oder man nennt diesen Branch "community" oder so, damit klar ist, dass es ein Fork ist. Und vielleicht meldet sich der ursprüngliche Maintainer ja doch noch...
+1
Und wer soll das entscheiden? Hier im Forum sind immer wieder Leute die "totgeglaubte" Plugins noch benutzen.
Ich wurde vorhin angeschrieben, mit der Bitte vdr-ac3mode hinzuzufügen. Ich musste erstmal nachlesen, was das genau macht. Soviel also zu Plugins, die wirklich genutzt werden.
Irgendwer nutzt jedes Plugin irgendwie irgendwo noch.
Maybe that somebody with more knowledge can reply to specific questions like those from rofafor.
I'll try.
How should one publish changes to the upstream, if they are forking from your mirrors?
Well actually it's not really planned to publish back upstream. We'd like the remaining developers to join us.
Are you really going to act as a man in the middle by reviewing pull request and then submitting the same changes forward to the original master?
Pull requests could be merged into a newly created "community" branch. But that's just one suggestion we're discussing right now.
Have you really though the process through as it seems to me, that you're going to kill the VDR community by making the plugin scene just messier?
Well, we try to do the exact opposite. We want to give more control to the community without taking too much control from the original developer. It's just about finding the right balance.
fnu: Du warst glaube ich der größte Kritiker hier, oder? Ich habe den Wortlaut auf der Webseite mal ein bisschen angepasst.
@all: Ein paar Änderungen in der FAQ
Die Zusammenfassung:
Es werden nicht mehr pauschal 8 Wochen festgelegt. Derjenige, der das Plugin übernimmt muss alle Organization Owner überzeugen, dass er das Recht dazu hat. Also das entweder der ursprüngliche Entwickler sein OK gegeben hat, oder dass er eben lange genug verschwunden ist.
Das nimmt ein wenig die Einfachheit raus, aber nach längerer Überlegung ist es schon ein wenig dreist. 8 Wochen und zack, Plugin weg.
Aktive Rückfrage beim Entwickler sollte sein und hierbei hat man dann auch immer eine Einzelfallentscheidung. Mehr Aufwand, aber potentiell fairer.
Zusätzlich habe ich eingefügt, wie man der Organization beitritt.
Die Zusammenfassung dazu: Öffne ein Issue und frage nach. Das muss nicht lange sein, aber da es ein manueller Prozess ist, muss es wohl zwangsläufig darüber laufen.
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-projects/v…ithub.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.
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.
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.
Vmtl. auf das bezogen, sich aufzuschwingen als einzige zentrale Anlaufstelle für VDR Plugins zu gelten ... ?
Naja. Das ist nunmal die Ambition.
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.
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.
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?
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.