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

Für mich war das git von vdrdevelopers immer ein mirror. Meine Projekte sind ja alle auf github, müssten also nicht extra gespiegelt werden. Könnte man auch direkt von dort nehmen.
Finde die Idee btw gut.

Ich finde die Neuorganisierung sehr gut, da ich als Paketbauer immer wieder das Problem habe herraus zufinden wo das aktuelle Plugin nun liegt.
Die Möglichkeiten für Entwickler haben sich in den letzten Jahren nicht gerade verringert.

8 Wochen sind sehr knapp, 6 Monate sind hier schon realistischer um ein Plugin als verwaist anzusehen.

Was mir aber noch fehlt, ist ein Standard für das benennen von Branches woran man erkennen kann ob das Plugin überhaupt mit der VDR Version funktioniert.
Wobei mir natürlich am liebsten wäre ein Plugin baut sowohl mit der aktuellen Stable als auch mit der aktuellen Entwicklungsversion.

Was auch noch schön wäre, wenn die Plugins vernünftig getagged würden.

Zitat von ludi

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.

Ja und nein, OpeneELEC wurde geschwächt, es gibt zwei gleichartige Projekte, deren Stärken sich bis auf weiteres nimmer mischen lassen. Und das offensichtlichste ist, genau das was ich gesagt habe, eine anderer Name und der ursprüngliche Initiator ist sein Projekt teilweise los.

Es ist schon so das eine bestimmte seit Jahren formulierte Erwartungshaltung an die Pluginentwicklung mit dieser Umsetzung manifestiert, forciert wird. Da sage ich wie immer dazu, diese kann und darf es nicht geben. Dazu hat niemand das Recht, gerade bei Projekten die ohne Spenden mit persönlichem Freizeiteinsatz umgesetzt werden. Wer planbare Software will soll sich welche kaufen, dann kann er den Hersteller aufgrund eines Vertrags verantwortlich machen.

Eine Umsetzung als vdr-developer Alternative ohne Entscheidungshierarchien, gerne, warum nicht.

Regards
fnu

Gegen ein reines Mirroring von projects.vdr-developer.org/git spricht m.E. erstmal gar nichts. Bleibt zu überdenken, ob bzw. welche Vorteile Github als reines Spiegelungssystem überhaupt bringt.

Mir fallen spontan folgende Dinge ein, die ich beim derzeitigen Frontend als Teilzeit-Git-User vermisse/ nicht so gut finde:
1) einfaches forken, über die Weboberfläche -> patch erstellen -> pull request stellen
2) einfache Möglichkeit, repo-übergreifend branches zu vegleichen, diffs anzuzeigen etc.
3) generell einfacher zu handhabende Kommentier- und Anzeigefunktionen ...

Schlechter finde ich an Github, dass ich noch nicht herausgefunden habe,
4) wie man eine schöne Repo-Übersicht der Organization bekommt und die nach idle-time sortiert [EDIT: Ähhm, ich glaube das macht er wohl doch automatisch ... :)].

Man kann es natürlich den Entwicklern nicht vorschreiben, wo sie ihr plugin entwickeln, daher finde ich es auch nicht nachteilig, wenn es bei einem Mirror bleibt. Das war ja erstmal der Grundgedanke. Die Vorteile der pull requests per Mausklick hat man dann halt nicht. Ich würde das ganze aber auch nicht überinstrumentieren.

Den Entwicklern etwas vorzuschreiben oder sie mit einem Reaktionszeitlimit unter Druck zu setzen halte ich für nicht gut. Allerdings muss die Frage schon erlaubt sein, was mit plugins passiert, bei denen Jahre lang nichts passiert ist https://projects.vdr-developer.org/git/?s=idle&ofs=50 ... Es wäre schade, wenn sich Leute finden, die zumindest Kompatibilitätspatches erstellen, und die dann im Nirgendwo verschwinden. Es kann doch nicht nachteilig sein, solche Dinge zumindest in einem Branch zu sammeln!? Ich selbst habe mal für mich versucht, alle softhddevice forks in einem Github-Repo zu sammeln, nur um einen Überlick über den Sachstand zu bekommen. Das muss doch auch moralisch in Ordnung sein. Abgesehen davon, dass es die GPL sowieso erlaubt.
Der nächste Schritt wäre dann immer der Versuch, Kontakt zum Entwickler aufzunehmen und ggfs. den Patch anzubieten. Über welchen Weg auch immer. Wird er abgelehnt, auch gut. Es wird Gründe dafür geben. Reagiert über einen (wohl doch irgendwie zu definierenden) langen Zeitraum niemand auf Anfragen, würde mein Verstand sagen, dass dieser jenige das Kapitel plugin abgeschlossen hat. Ich halte es dann nicht für verwerflich, wenn der Allgemeinheit ein fork oder branch angeboten wird, den jemand anderes betreut. Nochmal, ich rede hier von vermeintlich "toten" Plugins. Bei "lebenden" ist die Vorgehensweise selbstredend vom Entwickler abhängig.

Lange Rede kurzer Sinn, ich finde die Idee Github an sich gut, auch wenns nur ein Spiegel ist. Trotzdem muss die Frage beantwortet werden, ob das projects.vdr-developer.org nicht auch könnte und man nicht mehr Verwirrung stiftet als es Vorteile gibt.
Egal wo, wenn man komplett sein will, müssen auch die release-by-tarball plugins rein. Wie z.B. http://vdr.schmirler.de/ etc.

Gruß
Andreas

Hallo,

I finde es super, dass ihr aktiv daran arbeitet, die jetzige Situation zu verbessern.

Natürlich will niemand einem Entwickler etwas wegnehmen, das geht ja auch gar nicht.
Die Verwendung von http://vdr-projects.github.io ist natürlich freiwillig.
Und wer http://vdr-projects.github.io verwendet, kann natürlich jederzeit auf den letzten von ihm erstellten Stand zugreifen.

Damit sich die jetzige Situation verbessert, ist es notwendig, dass wichtige Patches zeitnah auf http://vdr-projects.github.io landen.
Also, eigentlich finde ich 8 Wochen Reaktionszeit zu lange.
Es sollte in ein bis zwei Wochen möglich sein, eine Mail zu schreiben, in der dann z.B. steht:
- Ja, ich bin einverstanden, dass User xxx wichtige Patches einpflegt, aber bitte nur das allerwichtigste
Oder: - Bitte ändert da nichts, ich möchte das in 1-2 Monaten wieder übernehmen
Oder: - User xxx kann das übernehmen, ich bin gespannt, was er daraus gemacht hat, wenn ich in 6 Monaten wieder hereinschaue
Oder: - ... was auch immer

Wir drücken unseren Respekt dem Entwickler gegenüber aus, indem wir diese Antwort lesen und uns nach dieser Antwort richten
Und wir drücken unseren Respekt gegenüber der noch aktiven Community gegenüber aus, indem wir in Fällen, in denen gar keine Antwort kommt, selbst entscheiden. Also einen anderen Entwickler bitten, die notwendigen Patches einzupflegen.

Es geht letztlich um eine Balance zwischen den Interessen des ursprünglichen Entwicklers und denen der Community. Und http://vdr-projects.github.io wird nur erfolgreich sein, wenn wir beides angemessen berücksichtigen

- Markus

Jemand der ein Plugin bereit stellt, übernimmt *gar* keine Garantien für zukünftige Kommunikation. Weder in acht Wochen, noch in zwei.

Zitat von MarkusE

Wir drücken unseren Respekt dem Entwickler gegenüber aus, indem wir diese Antwort lesen und uns nach dieser Antwort richten

Super, toll, wunderbar ... und zeigt dann gar keinen Respekt, wenn der ursprüngliche Owner nicht antwortet ...

Umso mehr ich drüber nachdenke, umso unverschämter finde ich tatsächlich jegliches Ultimatum. So, wie es jetzt umgesetzt ist, finde ich "http://vdr-projects.github.io" bei näherer Betrachtung anmaßend, einfach mal eben alle VDR Projekte dahin zu spiegeln, mittels Gruppenzwang Druck aufzubauen und dann die hierarchischen Spielregeln akzeptieren zu müssen ...

Richtiger wäre gewesen, diese "http://vdr-projects.github.io" zu erstellen, die Owner zum Mitmachen einzuladen und nur mit deren Zustimmung zu spiegeln! Wenn der/die alten Owner sich nicht melden, hätte geschaut werden müssen, ob sich jemand findet der einen Fork (!) aktiv in der Wartung übernimmt und dieser auch als solcher gekennzeichnet wird. Hierarchische Entscheidungswege darf es hier gar nicht geben. Das ist z.B. bei einem Projekt wie LibreELEC/OpenELEC was anderes, die Lösung ist ein komplettes Paket ...

Auf "http://vdr-projects.github.io" dürfen nur Projekte vorhanden sein die aktiv gepflegt werden, z.B. vom ursprünglichen Owner, wenn dieser einverstanden ist mit der Spiegelung oder eben ein Fork von jemand anderes. Projekte wo der Owner nicht teilnehmen möchte, müssen nicht teilnehmen, kein Gruppenzwang.

Es kann nicht sein das hier jetzt die Erwartungshaltung herrscht, das Plugin ist (ohne Nachfrage) auf "http://vdr-projects.github.io" gespiegelt worden, jetzt müssen Anpassungen oder Patches reinlaufen, weil die Community das so möchte. Es kann gar keine Interessen einer Community in dieser Form geben.

Jeder Entwickler hat seinen Workflow, den gilt es ohne wenn und aber zu respektieren, siehe Diskussion mit Klaus und er hat recht.

Regards
fnu

Zitat von fnu

Umso mehr ich drüber nachdenke, umso unverschämter finde ich tatsächlich jegliches Ultimatum. So, wie es jetzt umgesetzt ist, finde ich "http://vdr-projects.github.io" bei näherer Betrachtung anmaßend, einfach mal eben alle VDR Projekte dahin zu spiegeln, mittels Gruppenzwang Druck aufzubauen und dann die hierarchischen Spielregeln akzeptieren zu müssen ...

Sehe ich anders. Ich sehe weder Druck noch Gruppenzwang noch Ultimatum. Ich finde das Gespiegle auch nicht unverschämt. Ich sehe eine m.E. berechtigterweise angestossene Diskussion um die Zukunft des gesamten Projekts mit offenem Ausgang und zunehmend aggresiver werdende Stimmung. Warum das so ist, weiß ich nicht.

Zitat

Richtiger wäre gewesen, diese "http://vdr-projects.github.io" zu erstellen, die Owner zum Mitmachen einzuladen und nur mit deren Zustimmung zu spiegeln! Wenn der/die alten Owner sich nicht melden, hätte geschaut werden müssen, ob sich jemand findet der einen Fork (!) aktiv in der Wartung übernimmt und dieser auch als solcher gekennzeichnet wird. Hierarchische Entscheidungswege darf es hier gar nicht geben. Das ist z.B. bei einem Projekt wie LibreELEC/OpenELEC was anderes, die Lösung ist ein komplettes Paket ...

Sich bis wann nicht meldet? War das nicht erstmal so angedacht, wie du beschreibst? Und warum ein fork und keine branch?

Zitat

Auf "http://vdr-projects.github.io" dürfen nur Projekte vorhanden sein die aktiv gepflegt werden,

s/aktiv gepflegt werden/funktionieren/ und ich stimme dir zu.

Zitat

z.B. vom ursprünglichen Owner, wenn dieser einverstanden ist mit der Spiegelung oder eben ein Fork von jemand anderes. Projekte wo der Owner nicht teilnehmen möchte, müssen nicht teilnehmen, kein Gruppenzwang.

Es kann nicht sein das hier jetzt die Erwartungshaltung herrscht, das Plugin ist (ohne Nachfrage) auf "http://vdr-projects.github.io" gespiegelt worden, jetzt müssen Anpassungen oder Patches reinlaufen, weil die Community das so möchte. Es kann gar keine Interessen einer Community in dieser Form geben.

Jeder Entwickler hat seinen Workflow, den gilt es ohne wenn und aber zu respektieren, siehe Diskussion mit Klaus und er hat recht.

Es herrscht doch keine Erwartungshaltung nur weil ein Plugin gespiegelt wurde!? Ich persönlich spiegele Projekte wann und wie ich will, solange es die Lizenz zulässt. https://projects.vdr-developer.org/git/vdr.git/ ist doch auch nichts anderes? Ist das schlimm? Klaus, stört es dich, dass es dieses Repository gibt?

Leider habe ich das Gefühl, dass das ganze Projekt nicht an den Interessen der Community scheitert. Ich vermisse die "Community"...

Gruß
Andreas

Zitat von rell

Ich sehe weder Druck noch Gruppenzwang noch Ultimatum.

Die Erwartung einer Antwort innerhalb eines bestimmten Zeitraums ist ein Ultimatum.

Zitat von rell

Ich sehe eine m.E. berechtigterweise angestossene Diskussion um die Zukunft des gesamten Projekts mit offenem Ausgang

Ja, sehr gute Sache diese Diskussion. Stellt sich die Frage warum sich soviele nur an der Diskussion beteiligen und nicht an der Entwicklung ... ? Also herrscht doch irgendwie Gruppenzwang ...

Zitat von rell

zunehmend aggresiver werdende Stimmung.

Sicher, kann man immer rein interpretieren, würde aber um konkrete Beispiele bitten?

Zitat von rell

Sich bis wann nicht meldet? War das nicht erstmal so angedacht, wie du beschreibst?

Nun, hier könnte man sicher einen mehrmonatigen Zeitraum abwarten. Es stellt sich ja dann sowieso die Frage ob sich jemand findet der es dann weitermacht, was auch dauern wird.

Und nein, so war es nicht angedacht, die Projekte wurden einfach erstmal gespiegelt und erst jetzt wird nachgefragt.

Zitat von rell

Und warum ein fork und keine branch?

Ich finde es schlechten Stil ein Projekt ohne Zustimmung unter gleichem Namen dauerhaft zu übernehmen.

Zitat von rell

s/aktiv gepflegt werden/funktionieren/ und ich stimme dir zu.

Gut, aber in der jetzigen Umsetzung wird das so nichts werden, weil einfach mal alles angezogen wurde. Manchmal muss man auch loslassen können bzw. findet sich später jemand der ein noch nicht vorhandenes auf der Plattform weiterpflegt, also auch dann erst dort vorhanden ist. Aktiv gepflegt und funktionieren ist für mich das Gleiche und zwar so wie es der Entwickler umsetzt und nicht die Community fordert ...

Zitat von rell

Es herrscht doch keine Erwartungshaltung nur weil ein Plugin gespiegelt wurde!?

Doch genau diese Erwartungshaltung wird mit der aktuellen Umsetzung geschürt, es ist dorthin gespiegelt also muss sich was tun, weil es die Community so erwartet. Wird es nicht gepflegt, ist es tot und hat dort nichts zu suchen.

Zitat von rell

Ich persönlich spiegele Projekte wann und wie ich will, solange es die Lizenz zulässt.

Mach das, gute Sache, aber "http://vdr-projects.github.io" ist kein privater Spiegel ...

Zitat von rell

Leider habe ich das Gefühl, dass das ganze Projekt nicht an den Interessen der Community scheitert. Ich vermisse die "Community"...

Da hast Du Recht, jeder Nutzer möchte das es weitergeht, logischerweise ist so eine Idee im Interesse der Community.

Leider wird vergessen, das hier auch einer was machen muss und die Interessen der (ursprünglichen) Maintainer werden IMHO nicht berücksichtigt. Es heißt nur es wird niemand etwas weggenommen ...

Grundsatz sollte "Opt-In" sein und nicht "Opt-Out".

Regards
fnu

Also ich kann jetzt nicht sehen, warum eine Sammlung von VDR Plugins + Patches zu den VDR Plugins die Interessen der Plugin Entwickler verletzen sollte.
Wenn die Patches im git sind, sind sie leicht konsumierbar und auffindbar. Wenn die Patches verteilt sind, z.B. hier im VDR Portal, ist es schwerer, die Patches zu finden.

Auch VDR wird schon seit einiger Zeit gespiegelt und Klaus hat bisher noch nicht geschrieben, dass er da etwas dagegen hat.
Das ist open source, die entsprechenden Lizenzen sehen das vor. Wer das nicht möchte, kein ja unter anderen Lizenzen entwickeln.

Spannender ist die Frage, ob sich genügend Entwickler finden, die die Plugins weiter pflegen und geeignete Patches beisteuern.

Das wird so enden wie fast immer in der Opensource-Welt.

Es gibt viele gute Ideen, doch man zerfleischt sich so lange bis allen Seiten die Lust vergeht oder wieder jeder sein eigenes Süppchen kocht und niemand mehr in dem Patch- und Forkchaos durchsieht.
Ich denke die Nutzerzahlen für lineares Fernsehen und speziell lineares Fernsehen am PC sind rückläufig. Da sollte man durchaus mal mehr an die Nutzer denken.

Irgendwie liegt hier der Fokus viel zu sehr bei den Entwicklern.
Ich denke in der heutigen Zeit, wo das Internet quasi überall verfügbar ist, kann man durchaus von einem Entwickler erwarten, innerhalb von 2-3 Monaten eine E-Mail mit ja oder nein zu beantworten (Koma-Patienten mal ausgenommen)
Wenn ich hier lese, dass über Anwortzeiten von einem Jahr nachgedacht wird, greife ich mir an Kopf.

Ich denke die wenigsten Opensource-Entwickler wollen einem anderen Entwickler irgendwas wegnehmen.
Aber wenn ich als Entwickler nicht mehr wirklich aktiv bin (warum auch immer), dann hab ich doch überhaupt nichts dagegen, wenn sich jemand "meiner Idee/Software" annimmt und sie am Leben hält. Das ist doch die Stärke von OpenSource.
Wenn einem das nicht gefällt, wähle ich halt keine Opensource-Lizenz oder lasse es halt bleiben.
Wie gesagt, auf eine einfache Mail innerhalb von 2-3 Monaten zu antworten, ob man sein Projekt noch selber verfolgen will, kann man heute durchaus von einem Entwickler erwarten.

Zitat von rell

Ist das schlimm? Klaus, stört es dich, dass es dieses Repository gibt?

Natürlich nicht, wieso sollte es?

Zum Thema: mir würde eine simple Link-Sammlung reichen, über die ich den aktuellen Stand eines Plugins finden kann - egal wo das gehostet ist.

Klaus

Zitat von nanohcv

Ich denke die wenigsten Opensource-Entwickler wollen einem anderen Entwickler irgendwas wegnehmen.
Aber wenn ich als Entwickler nicht mehr wirklich aktiv bin (warum auch immer), dann hab ich doch überhaupt nichts dagegen, wenn sich jemand "meiner Idee/Software" annimmt und sie am Leben hält. Das ist doch die Stärke von OpenSource.
Wenn einem das nicht gefällt, wähle ich halt keine Opensource-Lizenz oder lasse es halt bleiben.

Ich war dabei etwas ähnliches zu schreiben.

Wenn jemand anders eine GPL Software weiterentwickelt, sehe ich es eher als Unterstützung und nicht als Konkurrenz; denn seine Arbeit steht dem ersteren ja auch zwingend (von der GPL so gefordert) zur Verfügung.

fnu
Es ist hier alles noch nicht zu Ende gedacht, weil das Projekt noch ganz am Anfang steht. Das ergibt sich ja hoffentlich noch alles.

@all
Ansonsten muss ich im Prinzip keinen Entwickler eines GPL-Projekts um Erlaubnis fragen, ob ich seinen Source spiegeln, verändern und veröffentlichen darf. Das hat er mir mit der Lizenz schon erlaubt. Die offizielle Quelle eines Plugins steht ja normalerweise im Readme, die wird ja auch seltens verändert. Und wenn es dann doch mal einen Fork gibt, muss das auch so im Readme kenntlich gemacht werden. Falls diese Änderungen dann in das ursprüngliche Projekt übernommen werden, ist es umso schöner, aber lange kein Muss. Der vdr bei mir zu Hause ist ja auch kein vanilla-vdr, ich patche da immer selbst dran rum und veröffentlichte das auch gerne wieder. Entwicklung ist im OSS-Bereich halt nicht zwingend linear. Es ist schön, wenn es ungefähr in die gleiche Richtung geht, aber es darf auch entgegengesetzt sein.

Beispiel softhddevice: ich frage mich, ob es bald nicht sinnvoller ist, vdpau und vaapi getrennt voneinander zu entwickeln, denn keiner braucht beide Varianten gleichzeitig auf seinem vdr. Und wenn es dann zwei neue Plugins vaapidevice und vdpaudevice gäbe, wüsste jeder, was er nehmen muss. Natürlich haben beide Technologien Gemeinsamkeiten, die man durchaus in einer lib, die von beiden genutzt wird, bündeln könnte, aber da stecke ich jetzt nicht tief genug im Source.

Letztendlich wollen Copperhead und ich ja nur eine Schar von Entwicklern von Plugins und Patches unter einen Hut bekommen, damit eben nicht sowas passiert, dass z.B epgsearch und live eine halbe Ewigkeit nicht mit der aktuellen Version laufen. Wir suchen Leute, die an dieser Idee mitarbeiten wollen. Natürlich mag es da auch welche geben, die das alles nicht in Ordnung oder unsinnig oder was auch immer finden. Diese bitte ich dann einfach, Abstand davon zu nehmen. Keiner muss das Angebot, welches wir auf die Beine stellen wollen, annehmen oder nutzen. Es gibt dann eben einfach noch eine Quelle für den vdr und seine Plugins.
projects.vdr-developer.org ist eine super Sache, aber sie hängt an einer einzelnen Person (die immer einen sehr guten Job gemacht hat, keine Frage!). Die GitHub-Organisation würde uns eine einfache Möglichkeit geben, die Last auf mehrere Schultern zu verteilen, ohne auch noch die technischen Hürden des Hostens auf einem eigenen Server bewältigen zu müssen. Denn auch sowas wie Redmine muss aktuell gehalten werden, es müssen Datensicherungen gemacht werden und diese müssen im Fall der Fälle auch wiederhergestellt werden können. Und falls es mal zu einem tragischen Unfall dieser einen Person kommen sollte und der Server dann von einem Tag auf den anderen verschwindet, haben wir ein ganz anderes Problem. Natürlich kann auch GitHub verschwinden, da sind wir nie vor geschützt, aber es ist doch eher unwahrscheinlich, denn diese Plattform wird auch von Firmen wie Microsoft und Google genutzt. Und die werden das genauso wenig aufgeben wollen.

Lars

Ohne alles verfolgt zu haben, bin ich dabei
Die Antwort von fnu kann ich sehr gut nachvollziehen auch wenn ich sie nicht in gänze teile. Es ist schwierig hier allen gerecht zu werden. Die Plugin-Entwickler werden schon irgendwie gezwungen mitzumachen. Aber auch ich denke das es anders nicht geht, weil sich nicht jeder melden wird und es jetzt schon verwaiste Plugins gibt.
Ich hatte mich ja damals auch das zaphistory Plugin angenommen, ich fühle mich nicht wirklich verantwortlich tue aber mein Bestens bei der Entwicklung beim VDR mitzugehen.

Bei mir ist die Entwicklung in den letzten Jahren auch stark stagniert da mir einfach die Zeit fehlt und andere Programmierprojekte im Vordergrund stehen. Aber meine Entwicklung ist nicht tot und ich werde weiter für den VDR programmieren. Ich als Entwickler wünsche mir nur das es einfach wird mit dem neuen github. Und ich habe keine Lust meine Plugins in mehreren git zu organisieren.

Ansonsten finde ich es auch gut, das Ihr euch dem Thema annimmt und versucht die aktuelle Situation zu verbessern.

Grüße
Martin

Ich stimme fnu in soweit zu, dass "weiterpflegen" ohne Einverständnis des Autors nur nach Umbenennen erfolgen sollte.

Das wäre ein klassischer fork und völlig okay.

wie mini73 schon richtig erwähnte, wäre das btw nicht ohne Einverständnis, wenn GPL.

Also,

ich finde es gut, wenn man eine zentrale Anlaufstelle für Code von VDR und Plugins hat. GitHub zu nehmen ist naheliegend. Und es ist gut, wenn verwaiste Projekte sichtbar werden und ggf. zentral weitergepflegt werden. Danke für eure Mühe!

Zitat

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.

So halte ich das für unproblematisch. Nach vier oder auch nach acht Wochen zu Programmänderungen genötigt zu sein, würde ich mich unwohl mit fühlen. Aber ein "Hallo" zurückzuschreiben, ist ja nicht weiter wild.

Ich hab da noch was für die Plugin-Sammlung:
https://github.com/eikesauer/Permashift

Kann/will man das irgendwie einbinden (ohne mir Rechte abzunehmen), oder würdet ihr das auch als Mirror machen?

Ciao,
Eike