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

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.

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.

Zitat von kamel5

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.

Zitat von kamel5

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.

Zitat von zillerbaer

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.

Zitat von kamel5

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.

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.

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.

Zitat von kamel5

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.

Hier mal ein erster Stand:

https://vdr-projects.github.io/

Noch einiges zu tun und das sind auch nur die Plugins, die bei Arch dabei sind.

Offene Punkte:

• Pflegestatus vom Rest der Liste rausfinden
• Sicherstellen das für echt ungepflegte die Repositories angelegt und in der Liste als aktuelle "Projektseite" verlinkt sind
• Die Patches, die bereits stand heute auf diverse ungepflegte Plugins angewendet werden, dass diese noch funktionieren, in die neuen Community-Repos committen.
• Quelle bei Arch auf die Community-Repos umstellen und alle Patches bei Arch raushauen

Ich bin eigentlich nicht unbeding scharf drauf alles selber zu machen.

Kannst du vielleicht einen Pull-Request dazu erstellen?

https://github.com/vdr-projects/vdr-projects.github.io

Und da einige direkt von dir gepflegt werden: Besteht Interesse daran auch in das Repo in der vdr-projects-Organisation zu pushen oder soll ich das, sofern vorhanden, auf "archiviert" setzen?

MarkusE War gerade sowieso dran und habe deine Liste nachgetragen. Danke für das Zusammentragen.

Wenn wegen der Repositories kein Veto kommt gehe ich davon aus, dass die im Kontext der Organisation archiviert werden können. Bei aktiv gepflegten Plugins bringt ein zweites Repo nämlich sowieso kaum Mehrwert.

Es sind bereits einige "Community maintained" nicht nur gelistet sondern auch erste Helfer direkt als "Maintainer" bei den Repo in der Organisation eingetragen.