Posts by M-Reimer

    :tup

    Es wäre schon schön, wenn Du die Beiden: skinlcarsng und devstatus da noch mit verlinken könntest...

    Wenn, dann gibt es da später noch eine Tabelle im Markdown-Format damit jeder, der etwas nachtragen will, dieses via Pull-Request machen kann.

    Neue Repos lege ich nur für Sachen an die Stand jetzt auch im Kontext der Organisation gepflegt werden.

    kamel5 wenn sich an den Adressen nicht nochmal was ändert, dann ist das bereits umgesetzt. Links sind gesetzt. Repos sind auf "Archiviert" gesetzt. Weil man Issues und Pull-Requests dann nicht mehr anfassen kann habe ich die alle vorher zugemacht und den Link auf die neue Projektseite dabei hinterlassen. Plugins die gefehlt haben habe ich jetzt nicht neu als Repo angelegt. Falls das irgendwann nötig wird ist das ja schnell nachgeholt.

    Mag sein. Stimmt schon. Aus ursprünglich "softhddevice" sind zwei Zweige entstanden die nun aber in verschiedene Richtungen weiterentwickelt werden. Ich sehe da keinen Bedarf die zusammenzuführen. Wenn überhaupt, dann müsste die Initiative vom Entwickler einer der Zweige kommen.

    Das ist die Idee. Am saubersten wäre wenn man alles geschlossen auf GitHub halten könnte, aber GitLab ist auf jeden Fall einer der "guten". Relativ gutes Feature-Set und einen extra Account braucht es auch nicht.


    Komplett ungepflegte Plugins landen automatisch in der Organisation (bzw. ich lege die dort an). Bei gepflegten liegt es im Ermessen des aktuellen Projektleiters ob er in der Organisation mit einem Repository vertreten sein will. Alles andere macht keinen Sinn, denn was soll ich mit Pull-Requests auf einem Mirror die den eigentlichen Maintainer nicht erreichen. Der Pull-Request muss direkt im Projekt des Maintainers angelegt werden.

    Hmm, es sollte eigentlich das Bestreben der Entwickler (und der Organisation) sein, soviel wie möglich (und auch relativ zeitnah) die Änderungen in den Upstream zurückzumergen (um auch doppelte und dreifache Entwicklung zu vermeiden), notfalls in Branches, nicht nur bei "ungepflegt"...siehe oben, bei Fork-von-Fork-von...müßten die PRs schon einen langen Weg zurücklaufen...und wenn dazwischen ein ungepflegter Fork dazwischen liegt, wird's nicht einfacher.


    ...aber vielleicht ist meine Sicht altersbedingt etwas angestaubt...

    Wenn es einen Entwickler gibt und der nicht vorhat sein Repository im Kontext der Organisation zu führen oder zumindest dort aktuell zu halten, dann hat die Organisation mit dem Plugin nichts am Hut. Deshalb ja auch mein Plan die ganzen Mirrors auf "Archived" zu setzen mit Hinweis auf die tatsächliche "Heimat" des Plugins.


    Sowie ein Entwickler mal nicht mehr erreichbar ist, oder verkündet das er die Pflege nicht fortführen will, kann man so ein Plugin in die Organisation "umziehen" (nochmal aktualisieren, "Archiviert"-Status runternehmen) um Community-Mitgliedern hier zu ermöglichen Pull-Requests hinzurichten die dann ggf. von einem Mitglied der Organisation auch akzeptiert werden können um das Repository auf diesem Weg (also ohne eindeutigen Maintainer) aktuell zu halten. Und davon gibt es bei projects.vdr-developer.org noch einige. Wenn ich mal langeweile habe würde ich für das eine oder andere mal Patches von yaVDR einsammeln und ins Repo auf github.com/vdr-projects pushen.


    Und zumindest aus meiner Sicht gibt es noch genau ein Repo in dem softhddevice gepflegt wird: https://github.com/ua0lnj/vdr-plugin-softhddevice

    Wo das gepflegt wird ist eigentlich egal. Wichtig wäre m.E. das Plugins einen Maintainer haben und gepflegt werden und man nicht im Forum verstreute Patches suchen muss. Wo der aktuelle Code zu finden ist kann dann im Wiki gepflegt werden. Dort sollte auch stehen ob plugins gepflegt werden oder verwaist sind.

    Wiki hatte ich oben schon. Soweit ich weiß ist das vdr-wiki auch ohne Admin. Nur eine Frage der Zeit bis das weg ist. Hier wurde ja vor längerem mal nach einem Admin gesucht. Erst hat sich keiner gemeldet, dann hat sich doch jemand gefunden, der aber, soweit ich mich erinnere, dann keinen Kontakt zum ursprünglichen Admin mehr herstellen konnte.


    Aber im Prinzip stimme ich dir zu. So eine "wo ist was"-Liste könnte man auch auf GitHub im Kontext von github.com/vdr-projects erstellen. Wäre via Pull-Request dann auch von jedem anpassbar.


    Und eben gegen die "losen Patches" sehe ich einen potentiellen Sinn für Repositories unterhalb von github.com/vdr-projects. Ist halt so das nicht jeder ein ungepflegtes Plugin tatsächlich übernehmen will, aber ein Patch um z.B. zu einer neuen VDR-Version kompatibel zu machen stellt man halt doch mal bereit weil man das Plugin ja selber noch nutzt. Sowas könnte man dann eigentlich im Repository bei github.com/vdr-projects ablegen. Allemal besser als die verstreuten Patches die es hier schon öfter gegeben hat. Und da das Plugin "neutral" im Kontext einer Organisation steht hat man nur für den einen Fix nicht direkt "formell" die Verantwortung für das ganze Plugin übernommen.


    dann würde ich skin-nopacity, tvguide, tvguideng und skindesigner erst einmal als Link auf projects.vdr-developer.org belassen.

    Folgende würde ich Dich bitten, neu mit Link auf gitlab.com/kamel5 aufzunehmen: extrecmenung, skinlcarsng und devstatus.


    Kann ich machen. Nachteil von einem Link auf projects.vdr-developer.org wäre halt das dort keine Pull-Requests hin gehen können. Bei gitlab.com kann ich mich wenigstens noch mit meinem GitHub-Account direkt einloggen um ein Issue oder so anzulegen. Die Hürde bei einer fremden Plattform den tausendsten unnötigen Account zu erstellen schreckt viele ab. Aber ist deine Sache wie du vorgehen willst. Mir persönlich wären lauter Links auf gitlab.com lieber.


    Edit: Gerade interessehalber probiert: Ich kann, wenn ich mich mit github.com einlogge, sogar auf gitlab.com forken. Es wäre also ein kompletter Workflow bis zum Pull-Request auf gitlab.com machbar ohne dort einen weiteren Account anzulegen.

    Ich habe aber gerade gesehen, das die Projekte auf github.com/vdr-projects doch zum Teil erheblich von den letzten Ständen unter projects.vdr-developer.org abweichen. Wird da nochmal ein Abgleich stattfinden? Und wie ist es dann insgesamt mit dem Abgleich zu externen Quellen?

    Wenn der Stand github.com/vdr-projects veraltet ist, das Plugin auf projects.vdr-developer.org aber nach wie vor "unmaintained" aussieht (mehrere Jahre keine Commits, ...) dann synce ich manuell nochmal rüber um eine gute Basis für Pull-Requests zu bieten. Sollte ein Projekt aber auf projects.vdr-developer.org aktiv gepflegt werden und die Entwickler sind damit zufrieden, dann hätte ich keine Bedenken das dann trotzdem auf github.com/vdr-projects auf "archived" zu schalten und erstmal zu projects.vdr-developer.org zu verlinken.


    Ein Abgleich zu externen Quellen wird es nicht geben. Wie schon erwähnt schalte ich alle Repos, die schon woanders gepflegt werden, auf "archived" und packe einen Link zur neuen "Heimat" in die Beschreibung des Repos. Das kann man ggf. auch wieder rückgängig machen wenn sich bei den Zuständigkeiten etwas ändert.


    Ein VDR-Plugin ist letztlich ein Stück freie Software wie jede andere auch. Und jeder entscheidet frei wo er die entwickeln will. Wer gerne im Kontext von github.com/vdr-projects entwickeln will, der muss nur bescheid sagen um welche Projekte es geht und ich trage seinen GitHub-Account beim Repo ein.


    Für mich bedeutet "ist in meinen GitHub-Account" eben auch ein bisschen eine Verantwortung. Wer nur mal den einen Fix zu einem ungepflegten Plugin beitragen will, der will das Ding aber möglicherweise nicht gleich ganz übernehmen. Hier wäre eine Organisation darüber eine gute Option um eben nicht direkt den Anschein zu erwecken das ein bestimmter Nutzer die volle Verantwortung übernehmen will.

    Ich habe ja z.Z Schreibrechte für skin-nopacity, tvguide, tvguideng und skindesigner auf projects.vdr-developer.org. Die pflege ich da auch soweit weiter.

    Alternativ könntest Du auch die aus meinem Repo gitlab.com/kamel5 nutzen. da gibt es auch zusätzlich noch devstatus und skinlcarsng.

    Wenn du einen Mehrwert darin siehst deine Projekte unterhalb von github.com/vdr-projects aktuell zu haben, dann schicke mal eine Liste (ggf. auch via PM) mit den Projekten die du aktiv pflegst. Ich richte dann Commit-Rechte ein. Aktuell werden die dann indem du die bei dir als "remote" mit einträgst und hinpushst. Welche externen Repositories du dann aktuell hältst entscheidest alleine du als Projektleiter.


    Andernfalls gehen die gegen Ende der Woche bei github.com/vdr-projects auf "Archived" und werden auf deine GitLab-Repos verlinkt.


    Die Notwendigkeit von wer weiß wo her stumpf zu mirrorn sehe ich ehrlich gesagt nicht. GIT hat ein tolles Feature, welches den Verlust von Daten ganz gut kompensiert: Jeder hat das ganze Repository vorliegen. Sollte also irgendwann projects.vdr-developer.org plötzlich weg sein, dann kann jeder, der mal am Projekt entwickelt hat, mit geringem Aufwand den ganzen Stand wieder herstellen.

    Gute Arbeit! :welle


    Sobald das bei Arch drin ist tagge ich eine neue Version im "master"-Branch. Den Branch mit dem Fix lasse ich noch etwas stehen für diejenigen die nicht so einfach an eine aktuellere Library kommen.

    Erstes Beispiel für ein Plugin das nun parallel in der Organisation abliegt ist https://github.com/vdr-projects/vdr-plugin-graphlcd

    Solange es geht pushe ich parallel auf projects.vdr-developer.org aber halte das Repo in der Organisation parallel aktuell. Pull-Requests dann gerne in das Repo in der Organisation.


    Ich habe gerne ein Auge auf das Plugin und werde Pull-Requests wenn möglich akzeptieren. Ich kann es aber nicht selbst testen da mir die nötige Umgebung zum Testen fehlt. Mein persönliches Kriterium zur Übernahme auf meinen eigenen GitHub-Account ist somit nicht erfüllt und ich parke das lieber in der Organisation.

    In der Vergangenheit wurde schon ein paarmal gefragt wurde was mit den Repos im Kontext von https://github.com/vdr-projects/ los ist. Weiterhin wurde in der Vergangenheit schon von (teilweise alten) Ständen in eigene Profile geforkt um dann auf der Basis weiterzuentwickeln.


    Ich bin jetzt als "Miteigentümer" in der Organisation eingetragen und will die, sofern von einzelnen Entwicklern gewünscht, zumindest teilweise wiederbeleben.


    Bevor lange Diskussionen losgehen: Es muss jeder selber wissen wo er entwickelt. Die Organisation ist ein Angebot das nutzen kann wer will. Ich persönlich habe die Projekte, die ich tatsächlich mit einem gewissen Anteil von Initiative weiterbringen will gerne in meinem eigenen GitHub-Account. Ist vielleicht bisschen eine Marotte von mir aber da ich als Hobby Open-Source-Software entwickle habe ich einfach meinen Projektbestand gerne bei einem Hoster in meinem eigenen Profil. Das ist auch der Grund warum ich "vdrnfofs" ohne lange Aufwände zu treiben erstmal in meinen GitHub-Account umgezogen habe.


    Ich sehe die Organisation bevorzugt erstmal für etwas "verwaiste" Plugins die keiner ernsthaft pflegen will, wo aber dann und wann aus der Community Patches zugesteuert werden. Solange es keinen Entwickler gibt, dem man diese Patches senden kann, dürfen die dann gerne als Pull-Request an das Repo in der Organisation erstellt werden. Ob die Pull-Requests auch jemand akzeptiert hängt davon ab wie umfangreich der Patch ist und ob jemand, der das Plugin auch nutzt, noch sein OK gibt. Macht ja keinen Sinn ohne Qualitätskontrolle Änderungen durchzuwinken.


    Automatische Mirrors wird es auf jeden Fall keine mehr geben. Der Mehrwert hält sich in Grenzen und aktuell will auch keiner mehr Server-Kapazitäten dafür bereitstellen. Ich tendiere dazu bei allen Plugins, die neue Maintainer gefunden haben, die Adresse der neuen Heimat in die Beschreibung das "vdr-projects"-Repos zu packen und dann das Repo in der "vdr-projects"-Organisation auf "Archiviert" zu setzen. Dieser Status kann ggf. falls in Zukunft nötig und sinnvoll, auch leicht zurückgesetzt werden.


    Wenn jemand gerne ein Plugin im Kontext der GitHub-Organisation entwickeln will, dann bekommt er gerne auch Commit-Rechte eingerichtet. Muss aber jeder selber wissen ob er das will. Was woanders bereits gepflegt wird, wird ohne Initiative des neuen Maintainers in der vdr-projects-Organisation auf jeden Fall in den nächsten Tagen auf "archiviert" gesetzt und korrekt zum neuen Ziel verlinkt.

    Github kann auch "Wiki"...also wäre Reaktivierung von https://github.com/vdr-projects/ wohl das einfachste, die 2 Admins davon werden wohl doch so nett sein, noch paar Admins hinzuzufügen. Dann erzeugen wir noch eine Wiki-Seite, wer sich gerade für welches Plugin zuständig fühlt und versuchen, die Forks wieder einzusammeln, notfalls über lokales git-Repo mit mehreren Upstreams (angestaubt, fork-A, fork-B) und etwas Merge-Arbeit.


    Ich habe jetzt entsprechende Rechte.


    Allerdings sehe ich weniger das Problem "Forks einzusammeln" sondern eher das Problem der Dokumentation.


    Mir fällt spontan kein Plugin ein bei dem es nötig wäre "Forks einzusammeln" und wo die Entwickler entwickeln ist auch erstmal deren Sache. Solange ein Plugin eben entwickelt wird. Die Organisation steht jedem bereit der sie nutzen will und wenn ein Plugin "ungepflegt" wird, dann kann man den letzten Stand von der bisherigen Quelle ja wieder in die Organisation zurückmergen um ein einfaches Weiterpflegen zu ermöglichen.


    Ich habe mir jetzt auf jeden Fall schonmal Rechte für https://github.com/vdr-projects/vdr-plugin-graphlcd eingetragen und den Pull-Request akzeptiert. Da aktuell noch möglich ist auch auf projects.vdr-developer.org aktuell.

    Sehe gerade erst https://github.com/vdr-project…d5457984295fa3855cb68ed2a

    Schreibe mir doch bitte kurz als PM worum es genau geht. Kann ich im Prinzip direkt ins offizielle Repo pullen ohne den Umweg über GitHub zu gehen.


    Faktisch wäre vdr-plugin-graphlcd aber genau so ein Fall den ich im Prinzip gerne in einer Organisation sehen will solange sich keiner als richtiger "Maintainer" bereit erklärt. Ich kann gerne Patches kurz sichten und einbauen. Ich kann aber nicht testen was für den Job als Maintainer eher nachteilig ist. Mein "Steckenpferd" ist halt nur "graphlcd-base" mit meinem Kodi-Addon oben drauf. Da hab ich für den Lockdown sogar gerade ein neues Projekt. Es gibt da nette "moderne" grafische LCD (SPI, I2C) die ich gerne noch via Arduino mit anbinden will. Das wären dann 3/4 Leitungen zwischen LCD und Arduino. Ansteuerung vom PC via USB.


    In einer entsprechenden Organisation könnte man leicht Plugins "parken" die keiner "Vollzeit" weiterentwickeln will. Eben als Ziel für Pull-Requests ohne das jemand das Plugin "ganz offiziell" im Kontext seines Accounts braucht. Bei einfachen Fixes reicht es dann wenn jemand in der Organisation kurz drüberschaut und das dann halt ohne Testen pullt. Wenn das nicht hinhaut kann ja jemand ein Issue nachschieben und ein Commit ist ggf. auch schnell wieder rückgängig gemacht.


    Ich werde das mit der Organisation aber nicht nochmal diskutieren. An der Stelle habe ich auch keinen Bock mehr. Wenn sich hier ein Konsens findet das wir die Organisation brauchen können, dann kann ich aber im Prinzip ohne Probleme mit Copperhead absprechen das er mich als "Eigentümer" einträgt. Von da aus kann ich ggf. ein/zwei weitere Personen mit eintragen. Mirrors wird es aber nicht mehr geben. Wenn dann wird auf GitHub auch gearbeitet.


    Faktisch läuft das bei Kodi mit den PVR-Addons auch so. Solange das jemand aktiv pflegt hat er es in seinem GitHub-Account und an zentraler Stelle steht wo man den Kram findet. Bei ungepflegten Add-ons (aktuell VNSI PVR) wandern die in eine Organisation die vom Kodi-Team gepflegt wird. Nötige Änderungen bei API-Umstellungen werden da dann von Kodi-Entwicklern nachgereicht.

    Das mit den Mirrors ist auf einem Server von Copperhead gelaufen und der Dienst meines Wissens nach lange abgeschaltet. Eigentlich war das mit den Mirrors auch als temporäre Übergangslösung geplant.


    Die Grundidee, hier eine zentrale Anlaufstelle zu bieten, war im Prinzip nicht falsch, wurde damals aber, muss man leider so ausdrücken, mit aller Gewalt totgeredet.


    Aktuell sind wir genau an dem Stand der damals schon in den Raum gestellt wurde. Faktisch ist es sehr schwer bis unmöglich noch Commit-Rechte auf projects.vdr-developer.org zu bekommen. Eine GitHub-Organisation mit mehreren Community-Mitgliedern als "Projektleiter" wäre da deutlich einfacher handlungsfähig geblieben.


    Ich muss aktuell sagen, dass ich auch gut damit leben kann wenn jemand, der ein Projekt weiterführen will, es sich einfach in seinen GitHub-Account forkt und dort weiterführt. Meine ganzen anderen Projekte habe ich auch im Kontext von meinem GitHub-User. Ist auch irgendwie schön als OSS-Entwickler seine ganze Projektliste dort zu haben.


    "projects.vdr-developer.org" ist für mich auf jeden Fall schon auf dem Abstellgleis. "vdrnfofs" habe ich auch einfach zu mir auf GitHub umgezogen ohne noch den Aufwand zu treiben irgendwie nach langem Bitten nochmal Commit-Rechte zu bekommen.

    • vdrpbd habe ich noch parallel auf projects.vdr-developer.org. Solange das noch weiterläuft pushe ich auch dort hin. Offizielles Projekt-Repo ist aber: https://github.com/M-Reimer/vdrpbd
    • graphlcd-base hat nach wie vor seine offizielle "Basis" auf projects.vdr-developer.org. Eine Arbeitskopie liegt bei mir: https://github.com/M-Reimer/graphlcd-base
    • vdr-plugin-graphlcd habe ich Commit-Rechte auf projects.vdr-developer.org und kann ggf. Patches dort einchecken sofern sie an mich herangetragen werden. Ich kann und will das VDR-Plugin aber nicht offiziell "übernehmen" weil ich graphlcd-base selbst mit meinem Kodi-Addon nutze und mir keine Testumgebung mit dem VDR bauen will.

    Was das Wiki angeht: Ist da nicht auch der aktuelle Stand das es da faktisch keinen Admin mehr gibt?

    Mir soll's erstmal egal sein. Viele nutzen tntnet nicht. Aber wenn mir das im AUR mal jemand "out of date" markiert, dann wird das schwierig. Läuft wohl irgendwann drauf hinaus das man tntnet statisch drankompilieren müsste.

    Hat jemand schonmal versucht den aktuellen Stand von "live" mit tntnet 3.0 zu bauen?


    Vermutlich ist nicht viel anzupassen, aber bei mir läuft das sofort auf Fehler wegen einer nicht definierten Konstante.

    Streamdev-Server braucht man ja auch für die Playlisten-Lösung. Steht für Arch auch schon bei den "optdepends" mit dabei.


    Darf man die Bitte äußern das dann und wann auch Releases getaggt werden? Ist immer etwas nervig für Distributoren wenn es keine festen Stände gibt. Woran soll man dann festmachen wann neu paketiert werden muss?