Umzug nach GitHub?

  • Moin,


    irgendwie finde ich es doof, dass die ganzen Skins relativ verstreut sind. Ich fände es schöner, wenn man den Skindesigner inklusive aller verfügbaren Skins "auf einen Rutsch" installieren und updaten könnte. Deshalb die Idee, Skindesigner nach GitHub umzuziehen und die dort verfügbaren Collaboration Features zu nutzen. Jeder Skinner könnte sich einfach einen Fork erstellen und pull requests stellen.


    Das ganze macht natürlich nur Sinn, wenn die meisten Skinner da mitziehen...deshalb die Frage in die Runde: was haltet ihr davon? Fändet ihr das begrüßenswert und würdet mitmachen oder würdet ihr euch eher "in eurer Freiheit beschränkt" fühlen und hättet lieber die komplette Hoheit?


    Im Prinzip würde ja nichts von der Freiheit verloren gehen, jeder könnte sich in seinem Skin Ordner austoben wie er will...lediglich die Zeit zwischen Pull Request und Übernahme meinerseits wäre die "Bremse". Vielleicht kann man das auf GitHub sogar anders lösen, da müsste man mal schauen, so genau kenne ich mich da auch nicht aus.


    Wenn wir das so machen würden, würde ich auch gerne die beiden Skins Blackhole und nOpacity "zur Adoption freigeben". Da ich mich lieber aufs programmieren konzentriere und weder die Zeit noch großartig Lust habe, drei Skins zu pflegen, fände ich es cool, wenn sich jemand der beiden Skins annehmen würde und die nach seinem Gusto optimieren / weiterentwickeln würde. Blackhole hat ja schon einige Ableger, das könnte man in diesem Zuge beispielsweise auch konsolidieren.


    Jo...her mit den Meinungen :D


    Ciao Louis

  • Habe das jetzt selbst noch nie probiert, bin aber schon öfters darüber gestolpert.
    So wie ich das verstanden habe werden die Submodule nicht automatisch geclont. Auch muss das "Eltern" GIT explizit eine Revision wohl angeben.
    Müsste man mal testen.


    http://git-scm.com/book/en/v2/Git-Tools-Submodules

  • Die Submodule muss man aber immer extra aktualisieren, das kann ein bisschen tricky sein: https://git-scm.herokuapp.com/book/de/v1/Git-Tools-Submodule

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Also ich finde die Idee gut. Würde da auch mitziehen. Allerdings bin ich froh das ich mittlerweile vom Grundwissen her GIT ohne Probleme nutzen kann. Wie das dann mit submodule, fork, usw zu machen ist ........ da bräuchte ich schon ne Einweisung ;)


    Gruß Patrick

    Gruß Patrick


    [size=8]* Meine NeverEndingProjects ;) *


    vectra --- glasslike ---

  • Und dann installiert man immer gleich alle skins mit oder wie hast du dir das vorgestellt? Irgendwann gibts dann 100 Skins und 5000 Pullrequests...ich weiss nicht.

    - Client1: Thermaltake DH 102 mit 7" TouchTFT * Debian Stretch/vdr-2.4.0/graphtft/MainMenuHooks-Patch * Zotac H55-ITX WiFi * Core i3 540 * 4GB RAM ** Zotac GT630 * 1 TB System HDD * 4 GB RAM * Harmony 900 * satip-Plugin

    - Client2: Alfawise H96 Pro Plus * KODI
    - Server: Intel Pentium G3220 * DH87RL * 16GB RAM * 4x4TB 3.5" WD RED + 1x500GB 2.5" * satip-Plugin
    - SAT>IP: Inverto iLNB

  • Alles in einem git wäre meiner Meinung nach der falsche Weg. Wenn da jeder Skin noch die ein oder andere Grafik mitbringt, muss man irgendwann ein paar hundert MB installieren, um nur einen Skindesigner-Skin zu benutzen. Ist ja nicht so, dass man alle fünf Minuten den Skin wechselt, oder? :)


    Warum sollte man alle Skins installiert haben, wenn man nur einen haben möchte? Ich bin sogar schon kurz davor, die beim Skindesigner mitgelieferten Skins in eigene Pakete auszugliedern, damit man nicht immer alle mit dem Plugin bekommt, sondern sich genau das aussucht, was man haben möchte.


    submodules sind dafür da, mehrere git-Repositories in einem zusammenzufassen bzw. andere gits im eigenen unterzubringen, weil man das andere als Modul braucht. Das wäre z.B. was für libskindesignerapi. Es hätte dann sein eigenes git, man könnte es problemlos in ein eigenes Paket verpacken, aber bei der Entwicklung kannst du weiterhin direkt auf die aktuelle Version zugreifen, ohne sie vorher installieren zu müssen. Aber das haben wir jetzt ja anders gelöst.


    Lars.

  • Sehe ich genauso!

    Ich auch. Das Paket vdr-skindesigner würde sehr "bloated" werden, vor allem bei fertigen Releases. Nichts gegen github, ich nutze es gerne, aber die derzeitige Modularität zu opfern wäre schade, auch Release-Zyklen sollten so wie es sein sollte, bei einem modularen Konzept, entkoppelt bleiben.


    Ciao,
    Lucian

  • Von einem einzigen git für alles was mit skindesigner zu tun halte ich auch nichts, ich würde mir aber wünschen das alle Skins in github ihre Sourcen ablegen. Das würde mir das Paket bauen sehr erleichtern.
    Ob skindesigner oder die skins nun auf github liegt oder verteilt bei andere git Hostern liegt ist mir egal, auch wenn es sicherlich für den ein oder anderen einfacher wäre Skins zu finden.


    Auch sehe ich ein Problem der Pflege der Skins, wenn alle in einem git liegen werden viele davon ausgehen das auch alle skins alles können, nur wer soll/will das pflegen?
    Bereits jetzt gibt es Skins welche nicht mehr angepasst werden.

    Gruß
    Frodo

  • Sehe ich auch so. Die Vorteile von Github kann man auch nutzen ohne sich die ganzen Skins "einzuverleiben". Letztlich sollte jeder mit seinem Skin machen können was er will. Inklusive der Entscheidung eventuell lieber bei einer anderen Plattform als Github zu hosten.

  • Moin,


    wenn ich das richtig sehe, hat Louis ja zwei Anliegen, die aus meiner Sicht absolut nachvollziehbar und sinnvoll sind.


    1. Die zentrale 'Verwaltung' des skindesigner-Plugins und aller skindesigner-Skins unter einem 'Dach':


    Die bisherigen Bedenken dagegen, das plugin in Zukunft mit allen verfügbaren Skins auszuliefern, kann ich auf Grund der vorgebrachten Argumente sehr gut verstehen. Ich würde vorschlagen Plugin und Skins (bis auf einen s.u.) zu trennen. Für die Skins legt man bei github einen Account 'skindesigner-skins' (oder wie auch immer) an und unter diesem Account hat jeder Skin sein eigenes Repository. So hätte man alle Skins an einer Stelle. Man könnte, wenn gewünscht, auch mit Tobi Kontakt aufnehmen, ob das in dieser Form auch auf vdr-developer.org möglich wäre.


    Wenn ich Louis richtig verstanden habe, würde er metrixHD weiterhin betreuen. Der würde dann (quasi auch als Referenzskin und Vorlage für Skinner) weiterhin direkt mit dem Plugin angeboten werden.


    2. Der Wunsch Blackhole und nOpacity in andere Hände zu geben, um mehr Freiraum zum Programmieren/Weiterentwickeln der Plugins zu haben:


    Ich denke, es gibt inzwischen genügend Leute, die dazu in der Lage wären, einen der beiden Skins zu übernehmen, man muss sich nur trauen oder auch nur einen Ruck geben ;) Wenn ich nicht selbst schon konkrete Ideen für einen weiteren Skin hätte, würde ich zumindest einen davon 'adoptieren'.


    Es ist wohl unbestritten, dass Louis momentan einer der, für mich eigentlich der aktivste Entwickler rund um den VDR ist und dass seine 'Sachen' den VDR ungemein aufwerten....also Leute, auffi geht's!



    Letztlich sollte jeder mit seinem Skin machen können was er will. Inklusive der Entscheidung eventuell lieber bei einer anderen Plattform als Github zu hosten.

    Das schließt sich ja nicht unbedingt gegenseitig aus. Man könnte den Skin ja trotzdem noch parallel bei github anbieten und wenn ein Skinner das partout nicht will, dann unterlässt man es eben.


    Gruß,
    Tomas

  • Woran ich schon gedacht habe: Eine Art "Galerie" für Skins. Beispiel: http://xbmc-skins.com/


    Extrem interessant wäre in dem Zusammenhang natürlich wenn es machbar wäre eine Skin-Ausgabe ohne VDR zu rendern um immer einheitliche "Screenshots" automatisch zu erzeugen.


    Eine zentrale Codeablage bringt dem "Endbenutzer" wenig. Der will möglichst übersichtlich verschiedene Skins, bzw. deren Aussehen, vergleichen können. Bei etwas, das die Optik eines Programms verändert, gilt "Ein Bild sagt mehr als 1000 Worte".

  • Moin,


    schöne Diskussion...ich bin für alles offen, meine Grundgedanken hat Tomas nochmal prima zusammengefasst.


    An die Päcklesbauer habe ich mal wieder nicht gedacht ;) Das ist natürlich ein KO Kriterium für meinen Vorschlag, wenn bei jeder kleinsten Aktualisierung von irgendwas das komplette Paket neu geladen werden muss. Man müsste es also so hinbekommen, dass der Skindesigner selbst und jeder Skin irgendwo autark bleibt, aber trotzdem alles "unter einem Dach" wäre.


    Das Thema "Aktualität und Weiterentwicklung" von Skins sehe ich nicht so kritisch. Ob ein nicht aktueller Skin jetzt irgendwo gehostet wird oder zentral, ist ja eigentlich egal. Wichtig ist aus meiner Sicht, dass die Skins mit der aktuellen Skindesigner Version funktionieren. Es könnte ja auch vorkommen, dass ich in Zukunft aus irgendwelchen Gründen nicht abwärtskompatible Änderungen einführen muss, die in jedem Skin nachzuziehen sind. Deshalb schwebt mir eine Art "SkinningAPI Versioning" vor (ähnlich wie bei der libskindesignerapi Thematik), die ich bei jeder solchen Änderung hochzählen würde. Jeder Skin müsste dann die Version angeben, mit der er funktioniert. Ein Skin würde dann nur geladen werden, wenn die Version passt.


    Auch im Hinblick auf die vorgeschlagene Skin Gallery wäre es ggf. überlegenswert, ein komplett neues "Zuhause" für Skindesigner plus Skins zu schaffen, sprich einen kleinen VServer oder ähnliches für ein paar Euros zu mieten und alles darauf zu hosten. Wäre natürlich wesentlich aufwändiger als bestehende Lösungen wie GitHub zu benutzen, aber man wäre auch wesentlich flexibler.


    Ciao Louis

  • Auch im Hinblick auf die vorgeschlagene Skin Gallery wäre es ggf. überlegenswert, ein komplett neues "Zuhause" für Skindesigner plus Skins zu schaffen, sprich einen kleinen VServer oder ähnliches für ein paar Euros zu mieten und alles darauf zu hosten. Wäre natürlich wesentlich aufwändiger als bestehende Lösungen wie GitHub zu benutzen, aber man wäre auch wesentlich flexibler.
    Ciao Louis


    Ich hab da noch genuegend resourcen frei auf meinem vserver ...

  • Ich hab da noch genuegend resourcen frei auf meinem vserver ...


    Na das wäre doch was...schaumer mal wohin sich die Diskussion entwickelt :D


    Ciao Louis

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!