Ist ja auch kein Wunder, da "Letztes Update 02/2011"
Ähmm, du hast aber schon verstanden, dass damit das letzte offizielle Update des Plugins gemeint ist, nicht das dieser wiki Seite?
Und ja, das ist die aktuellste Version des Plugins, Stand heute.
version 0.1.9 released
Von randy vor mehr als 6 Jahren hinzugefügt
Und du erwartest ERNSTHAFT, dass alle möglichen Displays dort angesprochen werden? *kopfschüttel*
Und du erwartest ERNSTHAFT, dass alle möglichen Displays dort angesprochen werden? *kopfschüttel*
Was soll denn dieser Kommentar jetzt wieder, bitte?
Genau wie schon so oft gesagt, ist die Stimmung hier total vergiftet, wahrscheinlich auch deshalb, weil's nur Probleme gibt und man diese nicht ansprechen darf!
Nur zur Info gelistet sind folgende Displays:
ZitatAlles anzeigenHitachi HD61830
Samsung KS0108
Toshiba T6963c
Epson SED1520
Epson SED1330
Noritake GU140X32F-7806
Noritake GU256X64-372
Noritake GU256X64C-3XX0
Optrex 323
PCD8544-basierende Nokia-Displays (z.B. im Nokia 51xx)
Nokia 7110-Display (Controller: SED1565)
Ericsson T2x
ALPS LSU7S1011A (a.k.a. 'Pollin'-Display)
Hyundai HP12542R (Pollin)
Möchte mal sehen, wer die alle kennt. Das AlphaCool haben viel mehr Leute und ich habe es selbst mit GraphLCD am Laufen.
Ein Wiki lebt vom Mitmachen und letztlich kann jeder, der Fehler findet, diese auch direkt korrigieren.
Die Lust hier irgendwo mitzumachen ist mir schon lange vergangen, s. o.
Da gibt es Rechteverwaltung[...]
Mit der Rechteverwaltung von GitHub hab ich mich nie ernsthaft beschäftigt, bei yavdr sind wir da sehr pauschal, weil da einfach jeder alles darf.
Wenn jemand so eine Organisation anfängt, ist es natürlich kein Problem, dort die Upstream-Repositories als Fork zu sammeln. Aber eigentlich sind wir dann schon wieder bei einer Art Distribution.
Ich würde mich nicht sperren, bin gespannt, ob da "alle" zusammenkommen...
Lars.
Dafür gibt es doch projects.vdr-developer.org. Da gibt es auch Wikis, Issues usw. Sicherlich kann man da nicht so einfach Merge/Pull Requests stellen, aber die müssen ja nicht immer per Weboberfläche zusammen geklickt werden. Das geht ja auch problemlos auf der Kommandozeile mit Repositories bei unterschiedlichen git-Hostern.
Wohl wahr, aber ein Wechsel zu Github etc. hätte m.E. Vorteile, die überwiegen:
- Man könnte endlich einen "Frühjahrsputz" starten und nur die Sachen umziehen, die mit VDR > 2.3.* laufen. Das würde das ganze Thema veraltete Plugins anpacken.
- Wenn jemandem Plugins fehlen, müssen diese halt entsprechend angepasst werden und somit werden auch die aussortiert, die in der Praxis keiner mehr verwendet.
- Es gibt nachwievor eine zentrale Anlaufstelle, wo alles zusammenläuft - wie natürlich jetzt auch...
- Die Oberfläche ist deutlich benutzerfreundlicher oder besser gesagt "einsteigerfreundlicher", da man (auch außerhalb vom Kommandozeilen-git oder lokalen webclients) branches vergleichen, pull requests erstellen kann etc.
- Das Projekt VDR an sich würde sich selbst einen Tick mehr "Modernität" verpassen...
Das alles vor dem Hintergrund, dass die grundlegenden notwendigen Dinge gemeinschaftlicher Entwicklung das jetzige System auch kann.
Ob ein Wechsel wirklich dazu führen würde, dass das Gesamtprojekt davon profitiert, d.h. mehr Ordnung, aktivere Beteilung etc. ist fraglich.
Mir persönlich ist das grundsätzlich egal, denn ich baue mir meine 5 Plugins sowieso selber und forke sie mir bei Bedarf in irgendein Repo zentral, aber das muss ja auch nicht sein.
Die Möglichkeit, Plugins oder VDR nur zu "spiegeln" und die Patches als commit einzupflegen, wie es bei VDR selbst ja jetzt gemacht wird, hat man ja immer. Das würde ich von der Gewohnheit des Maintainers abhängig machen, wenn es einen gibt.
Zitat
Und ich würde meine Plugins sicherlich nicht unter einen Account stellen, wo verschiedenste Leute Zugriff haben. Über die offiziellen Sourcen meiner Plugins habe ich gerne die alleinige Kontrolle. Und das widerspricht sich nicht damit, dass ich natürlich gerne Patches von anderen Leuten bekomme.
Lars.
Das würde die Rechteverwaltung von github, gitlab etc. schon erlauben, das zu organisieren.
Falls das jemand zu offtopic wird, würde sich wohl ein Thread mit einer Grundsatzdiskussion rentieren. Ob und wie man dann zu einen Ergebnis kommt oder unbedingt kommen muss, ist die andere Sache.
Gruß
Andreas
Die Lust hier irgendwo mitzumachen ist mir schon lange vergangen, s. o.
Ok, aber dann solltest Du Dich geschmeidig zügeln irgendwas zu kritisieren ...
Vergiften tut hier nur die Meinung einzelner, die sich auf ein sehr hohes Ross setzen und nur erwarten das ihnen was zufliegt ... 
... so funktioniert kein OpenSource Project.
Kein OpenSource Entwickler ist verpflichtet irgendwas für irgendwen zu liefern. Stattdessen sollte etwas Demut und Dankbarkeit vorherrschen, das jemand seine Freizeit und sein Talent investiert. Wenn es einem nicht passt muss man eben selbst mithelfen, z.B. im Wiki.
Regards
fnu
OK, dann verrate doch mal, wie ein Anfänger sich in so ein Projekt hineinarbeiten soll, wenn ihm als erstes RTFM! an den Kopf geworfen wird, zumal es unvollständig und fehlerhaft ist.
Ich rede nicht von mir, ich bin durchaus in der Lage, meinen VDR wieauchimmer aufzubauen.
Aber das Verhalten gegenüber Neulingen ist mir hier schön öfters sehr negativ aufgefallen. Und manche Moderatoren machen da keine Ausnahme.
OK, dann verrate doch mal, wie ein Anfänger sich in so ein Projekt hineinarbeiten soll, wenn ihm als erstes RTFM!
Dann zeig doch mal bitte her wo Du einem Anfänger hier was ausführlich erklärt hast?
Und manche Moderatoren machen da keine Ausnahme.
Klar, sicher, wie immer ... 
Aber nochmal, Du tönst hier rum, willst aber nichts dazu beitragen das sich das ändert, READMEs oder Wiki Artikel aktualisieren? Echt jetzt? Dafür muss niemand programmieren können ...
Regards
fnu
Hitachi HD61830
Samsung KS0108
Toshiba T6963c
Epson SED1520
Epson SED1330
Das sind keine Displays. Steht auch auch so in der wiki: " die folgenden Controller und natürlich alle dazu kompatiblen Displays"
Und dein alphacool hat auch nix anderes drin.
fnu hat schon recht, ein wiki lebt nicht vom meckern drüber (noch dazu unverstandenem), sondern von mitarbeit..
Ein großer Faktor an all diesen Problemen ist die Zeit. Einfach schnell und bequem ist immer besser als kompliziert und langwierig. Und was hat wohl eher Erfolg, ein PR bei gh der in einer Minute zusammengeklickt ist oder den Author suchen und anbettelt (wenn es denn noch einen gibt) das er den Patch irgendwo mit einfügt wenn man denn eine Kommunikation überhaupt herstellen kann?
Statt auf gedeih und verderb einen Sonderweg gehen zu müssen wäre es schon Benutzer und Entwickler freundlich sich an die Gepflogenheiten zu halten die im Jahr 2017 vorherrschen.
Z.B. projects.vdr-developer.org ist heute nicht mehr zeitgemäß - das war in der vor Github Ära sicherlich anders - aber das hat sich mittlerweile nun geändert und darauf sollte man auch reagieren.
Ein anderes Beispiel ist das VDR in keiner mir bekannten SVN/Git gepflegt wird sondern nur per Archiv - empfinde ich jetzt persönlich nicht als Verbesserung und macht es alles unnötig kompliziert. Einen Bugfix backporten oder ähnliches wird zur Qual ohne ersichtlichen Zwang es kompliziert zu machen.
Und ja einer/mehrere müssen es machen und Zeit investieren - aber besser hier anstatt auf Jahre hinweg die Zeit ins Wiki zu stecken um irgendwie der Patchsammlung Herr zu werden.
Wenn man z.B. github.com/vdr/vdr-plugin-name je Plugin anlegt hat man einerseits kein Rechteproblem und kann vom originalen Author weiterhin gepflegt werden und anderseits kann man trotzdem alle Vorteile mitnehmen. Es lassen sich ja auch bestehende github.com gits via Submodule einbinden womit bestehende gits auch problemlos zu integrieren sind ohne das der originale Author sein gewohntes git verlassen muss (vdr-vnsi z.b).
Eins ist natürlich auch klar, ein Wunder darf man nicht erwarten das nach einem Wechsel von Heute auf Morgen alles viel besser ist - es ist lediglich ein Schritt in eine Zukunftsorientierte Richtung statt Stagnation.
Na ja, man sollte schon erwarten können, dass ein maintainer nicht beim ersten winzigen Problem schulterzuckend aufgibt
Tote Software wiederbeleben ist aber auch nicht im Sinne des Erfinders - bis zu einem gewissen Grad an Problemen ist das sicherlich kein Problem da ein Patch oder ähnliches beizusteuern. Aber es handelt sich hier in der Regel um richtig alte Software wo es mit trivialen Patches nicht gelöst ist. Und da stellt sich dann die Frage ist man Maintainer oder Entwickler.
Meinerseits finde ich eigenartig, dass der VDR selbst nicht beim git repository zu finden ist.
https://projects.vdr-developer.org/git/
Gibt es überhaupt in der Zwischenzeit einen Bugtracker für den VDR? Die Plugins haben ja in der Zwischenzeit Bugtrackers bei dem von mir gerade genannten git, der auch einfach über google zu finden ist.
Die Frage ist, was kann man tun, um zu vermeiden, dass der VDR nicht in mittelbarer Zukunft aussterben wird? Für mich sieht es so aus, als werde der VDR hauptsächlich von seinen alten Benutzern am Leben gehalten. Wie lange das so weiter gehen wird ist fraglich, besonders wenn man jetzt TVH mit in den Ring wirft.
Alleine schon die Tatsache, dass wichtige Plugins wie epgsearch und live keine richtigen Maintainer mehr haben ist kein gutes Zeichen.
Bitte nicht falsch verstehen: dieses Posting ist nicht dazu gedacht, den VDR zu kritisieren; es geht darum, den VDR am Leben zu erhalten und erfolgreich zu machen.
Ich frage mich auch, was kls von dieser ganzen Diskussion hält.
Meinerseits finde ich eigenartig, dass der VDR selbst nicht beim git repository zu finden ist.
CvH
gh.com ist nicht GitHub bzw. github.com, wäre schön, wenn du das in deinem Post ändern könntest.
Und git-submodules (anderes git-Repositoy als Unterverzeichnis in einem vorhandenen git-Repository) sind was ganz anderes, als was du meinst. Du meinst einen Fork (Klon eines git-Repositories).
Nur, dass da nicht irgendwelche Missverständnisse aufkommen.
Lars.
Ich frage mich auch, was kls von dieser ganzen Diskussion hält.
Ich finde es gut, wenn es für jedes Plugin eine definierte Stelle gibt, wo man die aktuelle Source finden kann. Dabei ist es mir egal, ob das GIT, eine Webseite oder ein FTP-Server ist. Hauptsache man weiß, wo man den aktuellen Stand findet (sinnvollerweise steht das im README des Plugins). Suboptimal ist es, wenn es (wie zur Zeit beim softhddevice-Plugin) mehrere separate Zweige gibt, weil man dann erstmal herausfinden muß, welcher denn für einen selber jetzt geeignet ist. Aber klar ist auch, daß jeder Entwickler vorranging an den Themen arbeitet, die für ihn persönlich wichtig sind.
GIT benutze ich selber nicht, und ich habe auch nicht vor, das zu ändern. Ich arbeite ganz klassisch mit einem lokalen RCS, auf das nur ich Zugriff habe. Bugfixes und Verbesserungsvorschläge nehme ich gerne als Patches an, behalte mir aber die Entscheidung über deren Einbau jeweils vor.
Wie "rell" in seinem Posting ja schon geschrieben hat gibt es ein GIT, in das offensichtlich auch immer die jeweils aktuelle Version von VDR eingepflegt wird. Allerdings mache das nicht ich, sondern ein hilfbereiter VDR-User, dessen Namen ich nicht zur Hand habe.
Ich habe schon ab und zu mal überlegt, vielleicht auf meinem Server ein GIT für VDR anzulegen, das jede Nacht (falls sich was an der Source geändert hat) per Script aus meinem RCS generiert wird. Ich habe aber bisher noch kein derartiges Script gefunden, das ohne große Verrenkungen OOTB funktioniert. So ein generiertes GIT wäre auch immer nur "read only", da es nur eine Kopie meines original Softwarestandes (im RCS) wäre. "Pull requests" und dergleichen würde ich darüber auf keinen Fall annehmen.
Ich werde weiterhin den jeweils aktuellen Source-Stand auf ftp.tvdr.de zur Verfügung stellen und neue Versionen über die VDR-ML ankündigen (es findet ja auch immer ein hilfsbereiter User, der das dann im VDR-Portal meldet).
Wer mag darf mich jetzt gerne altmodisch nennen ;-).
Klaus
Hi,
das ist doch ein gutes Beispiel...
Nach ca. 4 Wochen findet dort ein commit vom Nicht-Autor statt. 2.3.4 fehlt ganz... Wobei das nicht gegen den Committer gerichtet ist! Toll, dass es überhaupt wer macht...
Ein git mit srcen für sehr viele Plugins gibt es doch schon mehrere, easyvdr pflegt eins, yavdr mehrere...
Quellen für ein zentral git gäbe es also...
Nur bringt ein zusammenkopieren in ein Master git doch z. Einen auch nur einen snapshot der aktuellen Situation und zum anderen muss der auch gepflegt werden. Mit dem Zwang zu einem System wird der Autor nicht motivierter... Jeder sollte schon das System nutzen können dürfen, das er möchte.
Eine zentrale Liste mit Links zum aktuellem src für jedes Plugin wäre etwas. Die Liste mit den Plugins für VDR 2.3.x im VDR-wiki ist das doch quasi...
Die müsste nur besser gepflegt werden.
BTW: zu vdr-developer: Ich denke mal etobi als Betreiber könnte bei Bedarf die Rechte für verschollene Autoren weitergeben... Ob das rechtlich geht ist die Frage...
MfG,
Stefan
Vielen Dank für die Antworten; insbesondere an Klaus für die Ausführlichkeit.
Wie "rell" in seinem Posting ja schon geschrieben hat gibt es ein GIT
Ich hatte den VDR git übersehen. Vielleicht sollte man ihn an den Anfang auf die erste Seite verschieben.
"Pull requests" und dergleichen würde ich darüber auf keinen Fall annehmen.
Sind mit "dergleichen" auch ein Bug/FeatureRequest tracker gemeint?
Sind mit "dergleichen" auch ein Bug/FeatureRequest tracker gemeint?
Damit ist alles gemeint, was mir in irgend einer Weise "Druck" machen könnte ;-).
Klaus
BTW: zu vdr-developer: Ich denke mal etobi als Betreiber könnte bei Bedarf die Rechte für verschollene Autoren weitergeben... Ob das rechtlich geht ist die Frage...
Klar geht das. Der Serverbetreiber hat das "Hausrecht". Angemessene Reaktionszeit des ursprünglichen Autors natürlich vorausgesetzt.
Ich finde projects.vdr-developer.org auch nicht so schlecht wie es einige machen wollen. Letztlich wird dort auch GIT als Versionsverwaltung angeboten und auch wenn es bei Github besonders prominent angeboten wird, kann jeder jederzeit Pull-Requests auch zwischen verschiedenen Servern stellen. Dazu braucht es kein Github. Wer beim Erstellen eines Pull-Requests gerne Github als Remote-Server nehmen will, der kann das natürlich tun. Es reicht dann die Git-Adresse dem Autor zu nennen und er kann mit "git pull" davon in sein eigenes Repository pullen. Habe das selber schon beim Entwickeln für "Skindesigner" genau so gemacht und meine Commits sind alle sauber bei projects.vdr-developer.org angekommen.
GIT benutze ich selber nicht, und ich habe auch nicht vor, das zu ändern. Ich arbeite ganz klassisch mit einem lokalen RCS, auf das nur ich Zugriff habe. Bugfixes und Verbesserungsvorschläge nehme ich gerne als Patches an, behalte mir aber die Entscheidung über deren Einbau jeweils vor.
Hast du dir GIT wenigstens einmal angeschaut? GIT ist erstmal auch rein lokal. Ich selber erstelle neue Projekte immer erst lokal. Man kann ganz ohne Server alle Funktionen von GIT verwenden und beliebig viele Commits und Branches lokal erstellen. Wenn ich dann der Meinung bin, mein Projekt kann veröffentlicht werden, trage ich lediglich noch den Remote-Server ein und pushe zum Server. Jeder der dann wieder pullt hat genau meine lokale Kopie inklusive aller Commits auf seiner Platte. Jeder, der mitentwickelt, hat also folglich eine komplette Serverkopie auf der Platte (verteiltes Backup).
Je nachdem was deine Anforderungen sind, dürftest du für rein lokales Arbeiten auf einem Branch mit sehr wenigen Befehlen auskommen können.
Zitat
Ich habe schon ab und zu mal überlegt, vielleicht auf meinem Server ein GIT für VDR anzulegen, das jede Nacht (falls sich was an der Source geändert hat) per Script aus meinem RCS generiert wird. Ich habe aber bisher noch kein derartiges Script gefunden, das ohne große Verrenkungen OOTB funktioniert.
Am einfachsten wäre natürlich, wenn du auf GIT umsteigen würdest. Ist, wie gesagt, auch rein lokal und wann du zum Server synchronisierst ist ganz deine Sache. Dann reicht halt hin und wieder ein "git push" und der Stand ist oben.
Wenn es aber unbedingt RCS bleiben soll, dann könnte ich mir das eventuell mal anschauen was da machbar ist. Wäre natürlich spannend exakt deine Commits auf dem GIT zu sehen und vor allem initial einen kompletten Import aller alten Commits zu machen. Natürlich ohne jetzt direkt etwas zu versprechen, denn ich habe selber alle Hände voll zu tun. Das Klaus das mit dem öffentlichen Repository ernst meint natürlich vorausgesetzt.
Edit: Ich habe RCS wohl überschätzt. Am einfachsten wäre in der Tat "Generische" Commits zu erstellen die mit einer generischen Commit-Message einfach täglich erzeugt werden. Sowas sollte recht schnell gescriptet sein.
Ich finde ein öffentliches Repository wäre schonmal ein sehr interessanter Schritt. Bisher werden Patches für gemeldete Fehler mal in der Mailingliste und mal hier im Forum gepostet. Mit einem öffentlichen Repository wäre ein neuer Fix dagegen ein Commit der dann für jeden, der die Entwicklung verfolgt, sichtbar wäre. Neben den Entwicklerversionen hätte man dann sozusagen auch eine "Nightly-Version".
Was Bugtracker und Pull-Requests angeht: Das solltest du eigentlich nicht als "Druck" verstehen sondern eher als zentrale Aufgaben/Anforderungsliste. Und ein Pull-Request oder Issue kann mit nur einer kurzen Bemerkung und einem Mausklick auch abgelehnt werden. Dann ist auch für jeden leicht ersichtlich, dass diese Anforderung bereits einmal abgelehnt 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
Was projects.vdr-developer.org gerade so veraltet macht ist genau, dass es keine Pull Requests gibt.
Ein "Pull-Request" ist ganz förmlich eine Anfrage, von einem anderen Repository zu pullen. Das kann ich über jeden beliebigen Weg machen. Wie ich noch beim Skindesigner mitgeholfen habe, ging das schlicht über VDR-Portal PNs. Könnte man aber auch über einen Kommentar zu einem Ticket in Redmine machen.
Das ist aber erstmal ein Git-Standardfeature und wurde nicht von Github erfunden. Man kann beliebig zwischen Servern pullen.
Man braucht als Beitragender natürlich ein öffentliches Repository von dem gepullt werden kann. Kann dann gerne auch, unabhängig vom Originalprojekt, bei Github liegen.
Ja, Github hat das schön ins Portal integriert. Aber nur deswegen ist Redmine nicht schlecht.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
