Frage zur Verwaltung der Lebensdauer externer Integrationen

Hallo,

Ich hatte eine Frage, die ich interessant finde.

Wenn ein Entwickler eine Integration nicht mehr pflegt und man diese übernehmen möchte, wie läuft das ab?
Denn wenn man sie in ein anderes Repo kopiert und veröffentlicht, erscheinen zwei Integrationen im Store :sweat_smile:
Gleiche Frage, wenn zwei Personen dieselbe externe Integration veröffentlichen? :sweat_smile:

Danke

Exzellente Fragen!

Du kannst einen Blick auf den Jeedom-Markt werfen und wirst feststellen, dass es ein bisschen chaotisch ist.
Danach gibt es Community- und kostenpflichtige Angebote, sodass du oft mehrere Plugins für denselben Dienst findest, und ich habe keine Lösung dafür gesehen, sie leben und sterben, ohne am selben Ort zu verschwinden.

Ich weiß nicht, es braucht eine Art „Kommission“ zur Analyse von doppelten Integrationen oder solchen, die Fehler haben und nicht aktualisiert werden, jedenfalls gibt es hier ein echtes Thema.

Persönlich wäre ich nicht schockiert, wenn eine zu wenig gewartete Integration aus dem Store entfernt würde (immer noch aktiv für diejenigen, die sie installiert haben, aber nicht im Verzeichnis aufgeführt / nicht installierbar). Ansonsten wird es ja das reine Chaos!

Das ist eine der Schwächen von Open Source. Es hängt von der Zeit und dem Engagement der Person ab, die das Projekt betreut. Es ist immer möglich, die „Maintainer“-Rechte mehreren vertrauenswürdigen Personen zu übertragen, was die Risiken begrenzt.

Genau, sollte man nicht jetzt @pierre-gilles oder ein, zwei andere vertrauenswürdige Personen die Rechte geben?
Was meint ihr dazu?

Sehr gute Frage, und sie kommt genau zum richtigen Zeitpunkt, bevor der Katalog zu groß wird :slightly_smiling_face:

Was es heute schon gibt

Eine Integration wird nirgendwo « registriert »: Der Indexer durchsucht alle Stunden die öffentlichen Repositories, die das GitHub-Topic gladys-assistant-integration tragen, liest das Manifest, überprüft das Docker-Image und veröffentlicht den Katalog. Direkte Konsequenzen:

  • Das Entfernen des Topics (oder das Archivieren des Repositories) entfernt die Integration aus der Liste im nächsten Zyklus, ohne etwas bei denen zu beschädigen, die sie bereits installiert haben: Der Container läuft weiter, das Image bleibt auf ghcr.io. Genau das beschreibt @guim31, und es funktioniert bereits.
  • Eine wiederaufgenommene, verlassene Integration bedeutet: Repository forken, docker_image zu seinem eigenen Registry ändern, Topic hinzufügen, veröffentlichen. Keine Erlaubnis von irgendjemandem nötig.

Zum resultierenden Duplikat

Ja, wir haben zwei Einträge, und nein, ich habe nicht vor, Duplikate zu entfernen. Ein Store ohne Review, der Duplikate ablehnt, ist ein Store mit einem Schiedsrichter, und der Schiedsrichter wird wieder zu einem Engpass. Der echte Hebel ist das Signal, nicht der Filter.

Ich hatte zuerst an ein Badge « nicht gewartet seit X Monaten » gedacht, aber bei genauerer Betrachtung ist das eine falsche gute Idee. Viele Integrationen sind einfach fertig: Eine Integration für Tempo oder Free Mobile kann ein Jahr lang nicht aktualisiert werden, weil sie einfach funktioniert. Umgekehrt kann eine Cloud-Integration morgen kaputtgehen, weil der Anbieter seine API geändert hat, ohne dass ein Commit erfolgt. Das Datum der letzten Veröffentlichung misst weder das eine noch das andere, und die einzige Möglichkeit, das Badge zu entfernen, wäre die Veröffentlichung kosmetischer Versionen. Schlechte Anreize und unfair gegenüber denen, die die Arbeit gut gemacht haben.

Was « verlassen » wirklich von « fertig » unterscheidet, ist die Reaktionsfähigkeit: Ein Repository ohne Commits seit einem Jahr und ohne offene Issues ist in Ordnung, ein Repository mit unbeantworteten Issues seit Monaten viel weniger.

Daher würde ich eher Folgendes vorschlagen:

  1. Repository auf GitHub archiviert, also automatisch aus der Liste entfernt. Klare Signalisierung, vom Autor erklärt.
  2. Später ein echter Gesundheitsindikator auf der Instanzenseite (wie viele nutzen sie, wie viele sehen Abstürze), der die einzige ehrliche Messung von « funktioniert es noch » ist.

1 und 2 beantworten das Szenario von @prohand recht sauber, ohne dass eine Kommission nötig ist.

Ich denke, 2) kann später implementiert werden, denn im Moment ist das Projekt noch zu klein, als dass ein solcher Wert für einen Nutzer, der z. B. von HA kommt, wirklich ein Signal wäre.

Zur « Analysekommission »

Ich glaube nicht, dass das die richtige Antwort ist. Sobald man die Qualität der Integrationen anderer bewertet, schafft man das Modell, das man gerade verlassen hat, mit dem zusätzlichen Problem endloser Debatten. Der Docker-Sandbox ist da, damit es dem Nutzer nichts kostet, es auszuprobieren, und eine schlecht gemachte Integration kann seine Instanz nicht destabilisieren. Einzige Ausnahme aus meiner Sicht: ein wirklich bösartiges Image. Ja, da könnte man eine Blacklist einrichten, wenn es soweit kommt.

Dass ich die Rechte eines Maintainers bekomme

Danke für das Vertrauen, aber nein :slightly_smiling_face: Der ganze Sinn der externen Integrationen war es ja, mich aus dem kritischen Pfad herauszuhalten. Maintainer von 40 Repositories zu sein, die ich nicht kenne, wäre nur eine neue Form desselben Engpasses, und ein Maintainer, der nichts merget, schützt niemanden.

Im Gegenteil, der echte Schutz ist vorgelagert.

Fügt von Anfang an einen zweiten vertrauenswürdigen Maintainer hinzu, bevor ihr ihn braucht :slight_smile:

Für Szenario 1 müsste dann ein Tag wie „nicht mehr gewartet“ oder „archiviert“ erscheinen, um die Nutzer darüber zu informieren, dass das Repository der Integration offiziell archiviert ist und sie in Gladys ausblenden zu können.

Für Szenario 2 ist das auch in Ordnung, das würde ermöglichen zu sehen, ob eine Integration noch gut genutzt wird und funktioniert.

Für den vertrauenswürdigen Maintainer, der von Anfang an hinzugefügt werden soll, muss man ihn finden können :sweat_smile:

Was mir bei alldem Angst macht, ist, dass wir mehrere externe Integrationen im Store sehen und dass es schnell ein Chaos wird :upside_down_face:

Gerade deshalb ist der Integrationsmarkt ein Marktplatz, ein bisschen wie Amazon oder Carrefour.

Wenn mehrere Integrationen dasselbe tun, ist das kein Bug: genau das ist der Sinn dieser Architektur! :grinning_face_with_smiling_eyes:

Es muss Wettbewerb zwischen den Integrationen geben. Es ist ein freier Markt, und Wettbewerb ist gut für den Verbraucher. Genau wie bei Carrefour kannst du fünf verschiedene Marken von Tomatensauce im selben Regal haben: Wenn es morgen mehrere Integrationen für dieselbe Marke oder denselben Dienst gibt, wird das ein Gewinn für den Endnutzer sein, kein Problem.

Unsere Aufgabe ist es hingegen, eine ausreichend transparente Plattform zu schaffen, damit dieser Wettbewerb den Nutzern tatsächlich zugutekommen kann: Anzahl der Installationen, Bewertungen, Stimmen, Qualität der Dokumentation, letztes Update usw. So viele Informationen, die es ermöglichen, die verschiedenen Integrationen leicht zu vergleichen.

Aber ich glaube, man sollte den Marktplatz auf keinen Fall einschränken. Er muss offen, frei und so vielfältig wie möglich bleiben. Gerade diese Freiheit wird es den besten Integrationen ermöglichen, sich natürlich durchzusetzen. :slight_smile:

Alles klar, mit den Erklärungen ist es für mich in Ordnung :slight_smile:
Danke

Kannst du eine Integration ausschließen, wenn sie ein Sicherheitsrisiko oder ein Problem für Gladys darstellt?

Alles ist möglich :slight_smile: