Neuorganisierung der VDR Plugins auf Github (vdr-projects.github.io)

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

  • >> Solange du innerhalb von 8 Wochen auf einen Pull Request reagierst, ist alles OK


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


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

  • Das finde ich sehr gut, endlich mal wird ein deutlicher Fortschritt erkennbar :tup

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 2GB RAM | 40GB SSD System + 2TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P461 | SEDU + 80 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

  • 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?

  • Meine Meinung wäre eher...



    Bevor man einen -> Maintainer wechselt oder jmd. anderes temporär etwas übernimmt sollten mind. 6..12 Monate echter Inaktivität liegen.
    Und auch nicht nur ein x-beliebiger Request, sondern wirklich komplett in allen Fragen inaktiv. Ein Wechsel des maintainers wird perspektivisch immer
    tiefgreifende Änderungen am Quellcode bedeuten, jeder hat seinen Style.


    Für Requests sollte es kein festes Timeout geben, eher Vorschläge.


    Und auf die Frage, worauf man denn nach Erlaubnis fragen sollte:


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


    b) falls jmd Maintainer von einem Plugin/whatever ist, ob er abgeben/teilen möchte. Auf diese Frage wird jeder, der aktiver Maintainer ist,
    zumindest antworten. Was nicht automatisch ja heißen muss und man respektieren sollte. Die Möglichkeit eines Forks besteht bei GPL ja immer.



    Und den Satz würde ich komplett streichen, der ist Unsinn: "Jeder hat heutzutage einen Github Account."

  • Auf was bezogen?

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


    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?


    Ich z.B. finde github nicht zwingend besser als z.B. redmine. Bei vdr-developer.git redmine kann ich mir ein tarball (gz/bz2) zu was auch immer ganz einfach mit einem Mausklick ziehen. Kein wget blabla/archive/blubblub ...


    Es ist schön wenn Nutzer wie <kein> sich über sows tolles freut, aber pflegt er auch ein verweistes Plugin weiter?


    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.


    Regards
    fnu

    HowTo: APT pinning

  • 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?

    Ich hatte es so verstanden: auf github gibt es ein Mirror des Plugins. Wenn der Maintainer weiter wie vorher arbeiten möchte, kann er das ruhig tun.


    Könnte dieses zentrale Repository mit der Zeit nicht auch von Vorteil für einen Entwickler sein, der sich entschieden hat, so weiter zu arbeiten wie bislang? Falls das Konzept sich durchsetzt, hat auch er eine Anlaufstelle wo er über Probleme mit seinem Plugin informiert wird.


    Ich habe vor wenigen Minuten auch ein Thread im englischen Forum hier geöffnet. Falls ich dort etwas ändern soll, sagt mir bitte Bescheid.

  • ? Die hat jedes Plugin ohnehin: die email in der Readme

  • Es ist schön wenn Nutzer wie <kein> sich über sows tolles freut, aber pflegt er auch ein verweistes Plugin weiter?


    Sicher nicht, dafür fehlt mir schlichtweg die Zeit. Aber wenn alle relevanten Plugins samt Patches zentral verfügbar wären, entfällt bspw. zumindest die von TheChief hier angesprochene Herumsucherei nach fehlenden Teilen. Ich bin ja wohl nicht der Einzige dem das auf den Zeiger geht...


    Ich persönlich nutze noch vdr-2.2, weil einige Plugins, die ich nutze unter 2.3 nicht mehr liefen und ich ehrlichgesagt auch keine Lust mehr hatte, zich Threads zu zich Plugins und Patches zu durchforsten. Daher wäre mir alles an einem zentralen Ort, wie github, auch lieber. Mit vdr-developer.org bin ich nie so richtig war geworden. Geht man beispielsweise auf http://www.vdr-developer.org/ kommt bei mir erstmal garnichts, außer eine leere Seite, also muss man erstmal das Forum oder das Wiki bemühen. Github ist da irgendwie deutlich schicker und intuitiver und wenn dort auch noch alle funtionierenden Plugins für die VDR stable und dev Versionen lägen - ein Traum.

    HW VDR: Thermaltake DH102 | Gigabyte GA-M720-US3 | AMD 270u | 2GB RAM | 40GB SSD System + 2TB HDD Daten | L4M Cine CT V6 + Flex S2 | Zotac GT630 | Futaba MDM166A | Atric IR-Einschalter Rev. 5 | NEC P461 | SEDU + 80 PIX | Pioneer SC-LX85 | Jamo S606
    SW VDR: Debian Wheezy | Kernel 3.2.0-4-amd64 | Mate 1.6 | VDR 2.2.0 | nVidia 331.79 | LIRC 0.9.0 | media_build_experimental | Plugins: permashift 1.0.3, softhddevice 0.6.1rc1-git, menuorg 0.5.1, skinnopacity 0.1.3, tvscraper 0.2.0-git, seduatmo 0.0.2-git, mplayer 0.10.2-hg, fritzbox 1.5.3, vdradmin-am 3.6.9, femon 1.7.19, targavfd 0.3.0, span 0.0.7, dvd 0.3.6-cvs, graphtftng 0.4.10-git, extrecmenu 1.2.4-git, epgsearch 1.0.1-git, block 0.1.2-git, cpumon 0.0.6a, ac3mode 0.1, HD-- 1.0.0-hg, u. v. a. ...

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

  • Ich bin ja wohl nicht der Einzige dem das auf den Zeiger geht...

    Hab's Dir schonmal gesagt, rummeckern ist "billig". Wenn man selbst nicht das Deut beitragen möchte, muss man demütig und dankbar sein, das überhaupt jemand noch einen Patch schreibt, auch wenn man den vllt. suchen muss ... :(


    Wer mit welcher Plattform persönlich klarkommt, ist auch jedem sein persönliches Problem. Irgendeine als einzig Gute darzustellen, geht nicht, grad bei Entwicklern, die durchaus ihren Eigensinn haben (dürfen), sind schließlich Freizeit Projekte. Ohne Entwicklung geht nichts voran ...


    Das soll nicht heißen das ich github schlecht finde, aber wie bei jedem Software Werkzeug, gibt es Höhen und Tiefen. Auch habe ich nichts gegen diese Gruppierung der Plugins auf github, im Gegenteil man wird sehen wie es sich entwickelt, könnte positive Impulse geben.


    Bzgl. Wartezeit, 8 Wochen ist wie schon geschrieben zu kurz, mehrere Monate sollten es schon sein. Aber man muss halt auch den gesunden Menschenverstand nutzen, wenn ein Projekt seit 5,6,7 Jahren oder mehr kein Update erfahren hat, braucht's IMHO keine Wartezeit, wenn jemand wirklich aktiv Interesse hat ...


    Aber es sollte an seinem ursprünglichen Ort weiterentwickelt werden, oder auf/für github umbenannt (...ng etc.) werden, sonst wird's nicht besser als mit den Patches (siehe softhddevice, 1 orig. & 4 Forks/Mirrors). eTobi sicher der letzte der hier bei den Zugriffen auf die Projekte bei vdr-developer.git nicht weiterhilft.


    Und dann gibt es noch die Projekte, wo der Entwickler entschieden hat, das nur als tarball zur Verfügung zu stellen. Wie soll hier ein Pullrequest funktionieren, egal welche Wartezeit? Eine Weiterentwicklung ohne Zustimmung des Ursprungsauthors, kann eigentlich auch nur unter angepasstem Namen stattfinden ...


    Regards
    fnu

    HowTo: APT pinning

    Dieser Beitrag wurde bereits 3 Mal editiert, zuletzt von fnu ()

  • Hi,
    Ich denke die Hürde sich zu melden sollte herabgesetzt werden für die Plugin-Autoren: sich dort anzumelden um zu sagen, dass man nicht weitermacht wird keiner tun... Dort wäre eine Mail-Adresse sinnvoll zusätzlich...


    Aber: Danke für eure Mühen zur Wiederbelebung und hoffentlich besseren Fortführung der Plugins!
    MfG Stefan

    Test-VDR1: HP rp5700 Fertigsystem, Core2Duo E6400, 2GB RAM, FF-SD C-2300, nvidia Slim-GT218 x1 | easyVDR 2.0 64Bit
    VDR3: in Rente

    VDR4: MSI G31M2 v2, Digitainer2-Geh., t6963c 6" gLCD, E5200, 2GB, 3TB WD Red, GT730, 2x TT S2-3200; easyVDR 3.5 64bit
    VDR5: Gigabyte
    GA-G31M-S2L, Intel E2140, Zotac GT730 passiv, Digitainer2-Geh., t6963c 6 " gLCD, 2 TB WD Red, 2x TT S2-3200 (an 1 Kabel) easyVDR 3.5 64bit
    VDR6:
    Intel E5200, GT630 passiv, F1 750 GB, t6963c gLCD, 2x TT S2-3200 | easyVDR 3.5 64bit
    VDR-User #1068 
    www.easyvdr.de 

  • Jetzt mal eine Sicht von einem Nutzer:

    muss man demütig und dankbar sein

    Ja, dass bin ich in der Tat und mir wurde schon sehr oft sehr gut geholfen.


    Ich drücke Euch die Daumen, dass Ihr das unter einen Hut bekommt.


    Torsten

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


    Ein Mirror ist etwas anderes, als die Entwicklung mikroschrittchenweise in git durch zu exerzieren.


    Zitat

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


    Es gibt durchaus auch Leute, die mal ne Weile im Ausland sind oder beruflich zu tun haben. Oder was auch immer.


    Deine Art und Weise Druck aufbauen zu wollen schreckt eigentlich eher davon ab, jemals wieder Plugins für VDR zu schreiben.

  • Und dann gibt es noch die Projekte, wo der Entwickler entschieden hat, das nur als tarball zur Verfügung zu stellen.

    Als Laie denke ich folgendes: Kann man nicht für jeden tarball ein branch auf github erstellen? Gibt es ein Bug, so kann jemand ein Patch für ihn schreiben und auf dem git veröffentlichen.


    Kommt ein neues Release vom Entwickler gibt es zwei Möglichkeiten:
    - Der Entwickler hat den Patch übernommen und alles ist gut.
    - Der Entwickler hat den Patch nicht übernommen: die Person, die den Branch für das neue Tarball aufsetzt kann den alten Patch zum neuen Branch hinzufügen, falls es Sinn macht.


    Eigentlich frage ich mich, ob dies nicht auch eine Lösung ist, um mit dem VDR Core umzugehen? Somit könnte Klaus einfach so weiterarbeiten wie er es gewöhnt ist und eventuell nur die Patches nehmen, die ihn interessieren.

  • 1) Tarballs lassen sich wunderbar mit import-orig in ein git übernehmen, mit pristine-tar sogar so, dass man aus dem git wieder die originalen Tarballs exportieren kann,so dass sie die gleiche Prüfsumme behalten.


    2) Für mich zählt auch eine Reaktion a la "ist mir bekannt, komm ich gerade nicht zu", damit ein Plugin nicht verwaist ist. Ich selbst bin auch schon seit Monaten nur sporadisch am Programmieren, kenne also das Problem. Ich würde Patches auch nie einfach nach master oder upstream oder wie auch immer der Hauptbranch heißt übernehmen, sondern immer nur in einen extra gekennzeichneten Branch, der durchaus auch wieder verwaisen oder gelöscht werden kann, falls es upstream zu einer anderen Lösung kommt.


    3) Eine Umbenennung von Plugins nach dem Muster ...ng finde ich nicht schön. Das ist Sache der Distributoren, welche Art von Kennzeichnung sie in die Pakete übernehmen wollen, meist lässt sich das mit einer speziellen Version oder andere Art von Tag machen. Einem Forker steht es natürlich frei, seinen Fork so zu benennen,wie er will. Aber ein Schema kann es da gar nicht geben, spätestens beim zweiten Fork klappt das nicht mehr.


    Ich hoffe, wir können zusammen einen Weg finden, wie wir die Situation verbessern können, ohne persönlich zu werden. Und wem das alles gar nicht passt, wird auch nicht gezwungen, hier in irgend einer Form mitzumachen. Und seine Plugins würden ihm auch nicht "weggenommen" werden, geht ja auch gar nicht. Besser wäre es dann, sich einfach zurück zu halten. Am besten wäre es aber, wenn konstruktive Vorschläge gemacht werden würden.


    Das Motto sollte immer noch sein: Have fun!


    Lars.

  • 1) Tarballs lassen sich wunderbar mit import-orig in ein git übernehmen, mit pristine-tar sogar so, dass man aus dem git wieder die originalen Tarballs exportieren kann,so dass sie die gleiche Prüfsumme behalten.

    Das ist mir durchaus bekannt, nutze ich selbst lokal zuhauf, zwingt aber das Plugin in diesem Fall nach github, obwohl der ursprüngliche Author das nicht wollte ... ? Wie ja generell hierdurch auch irgendwie ein github Zwang ensteht ...


    Have fun ist mir noch zu wenig, wenn ich den Eindruck habe einige Dinge sind noch nicht zu Ende gedacht sind.


    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. Welches Project dann auch immer dann genutzt wird, ist es genau die Situation genau die vermieden werden sollte, ein Stück weit wäre der Author dann auch sein Projekt los ... ?


    Und das Thema Hierarchie zur Entscheidungsfindung innerhalb dieser zentralisierten Struktur weckt bei mir große Bedenken ... ich sehe hier auch keine riesen Community die das so wollte, nur ein paar wenige die das für sich so umsetzen ...


    Regards
    fnu

    HowTo: APT pinning

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

    Ist das dann nicht wie OpenElec und LibreElec, wo (soviel ich weiß) es zu einer Spaltung kam und die Projekte verschiedene Wege eingeschlagen haben. Ich sehe nicht ein, warum das schlecht sein sollte.

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