fork von smarthome.py

[blubbs99]

Zufaelligerweise bin ich ueber diesen Thread gestolpert, als ich herausfinden wollte, wie es mit SmartHome.py jetzt weiter geht. Glueckglicherweise gibt es auch andere Leute, die gerne an diesem Projekt weiterarbeiten moechten. Zu diesen Leuten gehoere auch ich, weshalb ich hier anfrage ebenfalls Berechtigungen auf das neue Repo zu bekommen.

Ich hatte in den letzten Monaten (eigentlich sind es mittlerweile schon Jahre) einige Pull-Requests gestellt gehabt (User ohinckel), die teilweise integriert wurden, teilweise nicht. Diese Erweiterungen haben Zeit gekostet, weshalb ich diese Erweiterungen gerne auch in den neuen Fork integrieren moechte - und darauf hoffe ich mal mit diesem neuen Fork.

Abgesehen davon, kenne ich das System bereits schon intesiv und haben auch noch weitere Funktionen (bisher nur in meinem privaten Branch) implementiert, um es meinen Anforderungen gerecht zu machen. Auch hier stellt sich die Frage, wie mit solchen Erweiterungen prinzipiell in Zukunft umgegangen werden soll.

Konkret ist mir noch nicht ganz klar:
* Wer darf schreibenden Zugriff auf das Repo bekommen?
* Wer kennt das System soweit, dass er beurteilen kann ob ein Feature "korrekt" implementiert ist oder nicht?
* Welche Erweiterungen werden generell gesehen, wo koennen Erweiterungen nicht einfach integriert werden (z.B. Code des "Cores" wie z.B. smarthome.py oder die Sachen im lib-Ordner)?
* Wer macht sich generell Gedanken und Plaene um das Theme "wohin geht die Reise mit SmartHome.py"?

Ich wuerde mich freuen, auch wenn meine Zeit etwas beschraenkt ist, wenn ich ebenfalls Teil dieser Organisation werden kann. Gerade in Anbetracht der zahlreichen offenen Pull-Requests, die noch im "alten" Repo zu finden sind.

Btw. werden diese Pull-Request migriert, oder muss man diese neu aufmachen?

[DerSeppel]

Ich bin ein Fan davon das ganze möglichst demokratisch aufzuziehen.
Zum Thema Bewertung von Änderungen könnte man auf Gerrit setzen, wenn man das denn demokratisch haben will. Ist aber zuätzlicher Aufwand und funktioniert vermutlich nur mit vielen aktiven Entwicklern.

Das mit dem Fritzbox Plugin ist natürlich blöd. Für Markus aber sicher ein Alleinstellungsmerkmal.

Als einen der ersten Schritte würde ich gerne mal eine Bestandaufnahme machen, Features/Featurewünsche/ToDos aufnehmen und die dann auf eine Roadmap setzen.
Das erste Ziel müsste ja mal ein geordnetes, neues Release des Projekts sein. Auch wenn das nicht notwendigerweise technisch "weiter" ist als der das alte Smarthome.py.

[cmalo]

Zu diesen Leuten gehoere auch ich, weshalb ich hier anfrage ebenfalls Berechtigungen auf das neue Repo zu bekommen.

Hab Dich eingeladen, jetzt sind es 6 Personen, das sollte erstmal an Admins reichen.
Alle anderen können gerne über Pull-Requests sich in sh.py einbringen.

Auch hier stellt sich die Frage, wie mit solchen Erweiterungen prinzipiell in Zukunft umgegangen werden soll.

Wenn es nach mir gehen soll, kann man alle Plugins in sh.py integrieren. Entweder direkt über einen Pull-Request oder aber als Referenz auf ein anderes Repository.

Der Zustand den wir jetzt haben, finde ich unglücklich, da man viel im Forum suchen/lesen muss oder in irgendwelchen github repos sich seine Plugins zusammensuchen „darf“.

Es gibt aber einige Wege das eleganter zu lösen.

Im Falle der Integration in das Projekt (über Pull-Request) muss der Ersteller dann auch Pull-Requests erstellen, wenn er seine Software ändern will, hat aber den Vorteil dass mehrere Personen drauf gucken und dran arbeiten können innerhalb von sh.py.

Die zweite Möglichkeit bedeutet, dass einer der Admins, genau eine Version eines fremden repos in das Projekt aufnimmt. Die Updates auf dem fremden Repository werden nicht automatisch übernommen, sondern es muss im Hauptprojekt die Referenz aktualisiert werden. Ist etwas umständlicher als die erste Möglichkeit und bei Änderungen irgendwelcher Schnittstellen, kann man die Plugins nicht mal eben anpassen, was dazu führen kann, das Plugins nicht mehr laufen.

Als drittes, kann man eine Installationsdatei machen, die fremde Repositories nachlädt. Damit hat man ein zentrales Verzeichnis der Plugins über das der Nutzer auf alles „bekannte“ einfach zugreifen kann. Aber auch mit den Problemen wie bei fremden Repositories. Der Aufwand für die Integration dieser steigt.

Ich würde den ersten Weg bevorzugen.

* Wer darf schreibenden Zugriff auf das Repo bekommen?

Siehe oben. 6 Admins sollten reichen.

* Wer kennt das System soweit, dass er beurteilen kann ob ein Feature "korrekt" implementiert ist oder nicht?

Ich gehe davon aus, dass die Admins zusammen das beurteilen können. Zudem kann man Änderungen auch rückgängig machen.
In Zukunft sollten wir ein Releasemanagement aufbauen. Auch sollte der Zustand dass fast jeder den develop-branch Produktiv einsetzt, so schnell wie möglich wieder geändert werden und in Richtung von unstable und stable Versionen gehen.
Die Verwendung des develop-branches ist dem geschuldet, dass es keine weiteren Releases gab, macht die Weiterentwicklung der Software aber schwer.

* Welche Erweiterungen werden generell gesehen, wo koennen Erweiterungen nicht einfach integriert werden (z.B. Code des "Cores" wie z.B. smarthome.py oder die Sachen im lib-Ordner)?

Das kommt auf die Änderung an. Der Core ist natürlich sensibler als Plugins und sollte auch so behandelt werden um kompatibel zu bleiben. Erweiterungen im Sinne von neue Funktion sind auch unktitischer als Funktionsänderungen. Werden diese Notwendig, müssen sie getestet und ggf. auch ein Migrationsplan erstellt werden.

* Wer macht sich generell Gedanken und Plaene um das Theme "wohin geht die Reise mit SmartHome.py"?

Wir.

Btw. werden diese Pull-Request migriert, oder muss man diese neu aufmachen?

Ich versuche die bestehenden Pull-Reqests zu übernehmen, wenn sie unschädlich und sinnvoll sind. Die muss ich mir aber erst alle anschauen.

[Orion]

Hallo,

von meiner Seite wäre ich auch mit meinen Plugins mit dabei, zumal ich auch widgets für die smartvisu schreibe. Mein Vorschlag für das Repo bzw. der Plugins wäre, dass wir das etwas mehr dezentral machen. Marcus hatte schon einmal von einer Neustrukturierung gesprochen ich hole es wieder hervor, weil ich in anderen Projekten sehr gut Erfahrungen gemacht hatte: Git Submodules. Aus meiner Sicht kann man damit ein Kern für ein voll funktionsfähiges Image schaffen, der dann strukturiert den smarthome.py Kernanteil inkludiert, auch smartvisu aus Apollos repo dazunehmen kann und auch die Möglichkeit darstellt, dass Plugins dezentral in eigenen repos weiterentwickelt werden können. Wenn wir das alle ein ein Repo hineinpacken, dann haben wir wirklich eine hohe Änderungshäufigkeit (Commitrate), die von wenigen bewältigt werden muß. Mit der Aufteilung auf verschiedene (auch unterschiedlich verantwortete Repo's) kann man aus meiner Sicht auch mit unterschiedlichen Rahmenbedingung (Lizenzen, Erweiterungen, Plugin Alternativen usw.) umgehen.

Michel

[cmalo]

Ich bin ein Fan davon das ganze möglichst demokratisch aufzuziehen.

Dafür.

Als einen der ersten Schritte würde ich gerne mal eine Bestandaufnahme machen, Features/Featurewünsche/ToDos aufnehmen und die dann auf eine Roadmap setzen.

Fang an.

Das erste Ziel müsste ja mal ein geordnetes, neues Release des Projekts sein. Auch wenn das nicht notwendigerweise technisch "weiter" ist als der das alte Smarthome.py.

Sehe ich auch so und bin da schon bei.

[bmx]

Als einen der ersten Schritte würde ich gerne mal eine Bestandaufnahme machen, Features/Featurewünsche/ToDos aufnehmen und die dann auf eine Roadmap setzen.

Machst Du das idealerweise im Wiki? Dann kann es leicht ergänzt werden ...

Gruß,
Bernd

[DerSeppel]

Ich schau mal wie gut das im Wiki geht.
Eigentlich hatte ich an den Issue-Tracker gedacht. Ich dachte eigentlich mal bei GitHub gesehen zu haben, dass man da dann issues einem "Milestone" zuweisen kann.
Kann aber auch sein, dass es an einer angepassten Version von Github lag.

[JanT]

Hallo,

toll das es weiter geht!

Die Änderungen die ohne GPL commitet wurden, betreffen auch eine Stelle im sqlite-Plugin und das WOL-Plugin.

Um eine reimplementation der betroffene Stelle im sqlite-plugin kann ich mich kümmern. Ich habe sowiso ein offenen pull-request gegen genau diese Funktion. Gibt mir bitte nur ein bisschen Zeit, da gerade Land unter ist.

Viele Grüße,

Jan

[cmalo]

Hallo Michel

Git Submodules. Aus meiner Sicht kann man damit ein Kern für ein voll funktionsfähiges Image schaffen,... dass Plugins dezentral in eigenen repos weiterentwickelt werden können.
Mit der Aufteilung auf verschiedene (auch unterschiedlich verantwortete Repo's) kann man aus meiner Sicht auch mit unterschiedlichen Rahmenbedingung (Lizenzen, Erweiterungen, Plugin Alternativen usw.) umgehen.

Hab ich vorhin schon geschrieben, kann man machen. Alternative dazu ist hineinpacken ins Repository, der Entwickler macht nen Fork davon und arbeitet auf dem Fork. Wenn diese Weiterentwicklung fertig ist, macht er einen Pull-Request.

Meiner Meinung nach ist der Aufwand vergleichbar groß.
Der Unterschied liegt Verwaltungstechnisch nur da drin ob der Admin auf sh.py den Pull-Request anschauen und auf Kompatibilität und Stabilität bewerten muss oder ob er in dem Entwickler-Repository nach einer lauffähigen Version suchen muss.
Als einen Nachteil von Submodules sehe ich eindeutig, dass sobald der Plugin-Entwickler nicht mehr weiter macht, zwingend ein Fork erstellt werden muss damit da andere dran kommen. Zudem können globale Core-Änderungen nicht von einer Person gemacht werden, sondern jeder der 70+ Entwickler muss kontaktiert werden und mitarbeiten. Zum Beispiel eine Änderung der Plugin-Schnittstelle.

Die Submodule Funktion bietet sich primär für Libs an die in verschiedenen Projekten verwendet werden. Bei sh.py ist das so, dass die Plugins nicht ohne sh.py können und umgekehrt.

Grüße
Christian

[DerSeppel]

Wir sollten dann auch mal die Foren-Obrigkeit informieren/kontaktieren.
Wäre gut wenn zumindest 1-2 Member der GitHub Org hier Moderationsrechte bekämen. Von wegen Threads anpinnen und so. Oder weiß jemand wie das in den anderen Projektforen gehandhabt wird?

[bmx]

Zum Thema Plugins:
Wenn es so ist, das die Schnittstelle (API) für die Plugin gleich bleibt, dann scheint mir der Ansatz mit den Submodules der richtige zu sein, da dann die Plugins in callidomus genutzt werden können oder auch in smarthomeNG.

Sollte die Plugin Schnittstelle geändert werden und damit smarthomeNG und callidomus inkompatibel werden, dann fände ich es gut wenn die Plugins direkt und ohne submodules im rep von smarthomeNG zu finden sind.
Es ist ein großer Vorteil, wenn man als unbedarfter User mit dem ganzen beginnt das man nur einfach eine Quelle hat und für "Fortgeschrittene" ist es einfacher einen entdeckten Bug zu fixen.

Gruß,
Bernd

[knxmfbp]

Wo kann man denn sehen wer diese Admins sind? In der Github Org steht nur ein Admin. Wo kann man mehr über die Org erfahren, Leute, Aufstellung, Stärken usw...?

[psilo]

Ich fände auch gut die "Admins" im Wiki zu dokumentieren. Kann gerne paar Zeilen zu mir schreiben.

[cmalo]

Sollte die Plugin Schnittstelle geändert werden und damit smarthomeNG und callidomus inkompatibel werden

Meiner Meinung nach wird das API früher oder später inkompatibel oder ist es bereits. Wieso?

• Callidomus-API wird nur von Callidomus gepflegt. Wenn in einem der Projekte etwas geändert wird, wird das andere Projekt nichts davon wissen oder die Änderungen nicht gut finden und sie nicht übernehmen. Dafür sprechen bereits die vorhandenen, nicht bearbeiteten Pull-Requests.
• Callidomus wird wahrscheinlich nichts mehr zu sh.py beitragen. Weder Kernentwicklung noch Plugins, da die Rechte bei Callidomus liegen werden. Marcus hat seit 2014 einige Commits nicht unter der GPL gemacht und ich durfte sie wieder rückgängig machen.
• Wenn man sich Aktivität bei sh.py in der Vergangenheit anschaut, könnte man vermuten, dass Callidomus bereits länger entwickelt wird. Vielleicht sogar schon seit 2014. Da kann sich das API mittlerweile gewaltig unterscheiden.

Für eine gemeinsame Kernentwicklung wäre eine Kooperation notwendig, die aber auf Grund von Punkt 2 wahrscheinlich nicht vorgesehen ist.

Wo kann man denn sehen wer diese Admins sind? In der Github Org steht nur ein Admin.Wo kann man mehr über die Org erfahren, Leute, Aufstellung, Stärken usw...?

Github erlaubt nur einen Admin, wer es ist, ist egal, ich hänge da auch nicht dran. Die "Organisation" ist keine Firma nur ein paar Personen die bereits in der Vergangenheit Pull-Requests erstellt haben und in Zukunft dafür sorgen sollen, dass Pull-Requests angenommen werden. Dafür ist bei Github das anlegen einer Organisation notwendig. Die Zusammenstellung der Personen kann sich nächste Woche, nächsten Monat oder nächstes Jahr ändern.

Die Treiber der Software sind die Nutzer von sh.py. Jeder kann einen Beitrag dazu leisten in Form von Pull-Requests, Doku Erstellung, Plugins .........

[l0wside]

Schön, dass sich hier wieder etwas tut...ich hatte in letzter Zeit hier sehr selten reingeschaut, weil sh.py gefühlt eingeschlafen war.

Ich würde dafür plädieren, alles in ein einzelnes Projekt zu packen. Gründe:

• KISS. Keep it simple
• Stabilität vor Features. Mir wäre es lieb, wenn jemand anders als der Entwickler den Code noch mal prüft, bevor er er dann im Repo landet.

Ansonsten würde ich mich mal daran machen, ein neues RPi-Image aufzusetzen; 2013 ist ja schon eine Weile her. Gibt es jemand, der mich bzgl. smartVISU unterstützen würde?

Max