Question sur la gestion de la durée de vie des intégrations externes

Hello,

Je me posais une question qui je penses est intéressante.

Si un développeur ne maintien plus une intégration et que l’on souhaite reprendre la main dessus, comment cela se passe ?
Car si on le copie sur un autre répo et qu’on le publie, 2 intégrations apparaîtront sur le store :sweat_smile:
Eme question mais si 2 personnes publie la meme intégration externe ? :sweat_smile:

Merci

Excellentes questions !

Tu peux aller jeter un coup d’oeil sur le market de jeedom et tu t’apercevras que c’est un peu le chaos.
Après il y a du communautaire et du payant, donc tu retrouves souvent plusieurs plugins pour une même service, et je n’ai rien vu comme solution, ça vit et ça meure sans disparaitre au même endroit.

Je ne sais pas il faut une « commission » d’analyse pour les intégrations en double ou celles qui buggent et ne sont pas mise à jour, en tout cas il y a un vrai sujet là-dessus.

Perso je ne serai pas choqué si une intégration trop peu maintenue se voyait virée du store (toujours active pour les gens qui l’ont installée, mais pas proposée dans le listing / pas installable). Sinon en effet ça va être la jungle !

C’est une des faiblesses de l’Open Source. Cela dépend du temps et de l’investissement de la personne qui maintient le projet. Il est toujours possible de donner les droits « mainteneur » à plusieurs personnes de confiance ce qui limite les risques.

Justement, il ne faudrait pas donner les droits maintenant à @pierre-gilles voir une ou deux autres personnes de confiance ?
Qu’en pensez-vous ?

Très bonne question, et elle arrive au bon moment, avant que le catalogue ne grossisse trop :slightly_smiling_face:

Ce qui existe déjà aujourd’hui

Une intégration n’est pas « enregistrée » quelque part : l’indexeur passe toutes les heures sur les dépôts publics qui portent le topic GitHub gladys-assistant-integration, lit le manifeste, vérifie l’image Docker, et publie le catalogue. Conséquences directes :

  • Retirer le topic (ou archiver le dépôt) fait disparaître l’intégration du listing au cycle suivant, sans rien casser chez ceux qui l’ont déjà installée : le conteneur tourne toujours, l’image reste sur ghcr.io. C’est exactement ce que décrit @guim31, et ça marche déjà.
  • Reprendre une intégration abandonnée, c’est donc : forker le dépôt, changer docker_image vers son propre registre, ajouter le topic, publier. Aucune permission à demander à personne.

Sur le doublon qui en résulte

Oui, on se retrouve avec deux entrées, et non, je ne compte pas dédupliquer. Un store sans review qui refuse les doublons, c’est un store avec un arbitre, et l’arbitre redevient un goulot d’étranglement. Le vrai levier c’est le signal, pas le filtre.

J’avais d’abord pensé à un badge « non maintenue depuis X mois », mais en y réfléchissant c’est une fausse bonne idée. Beaucoup d’intégrations sont simplement finies : une intégration Tempo ou Free Mobile peut ne pas bouger pendant un an parce qu’elle marche, tout simplement. À l’inverse, une intégration cloud peut casser demain parce que le fournisseur a changé son API, sans le moindre commit. La date de dernière release ne mesure ni l’un ni l’autre, et la seule façon de faire sauter le badge serait de publier des versions cosmétiques. Mauvaise incitation, et injuste pour ceux qui ont bien fait le travail.

Ce qui distingue vraiment « abandonnée » de « terminée », c’est la réactivité : un dépôt sans commit depuis un an et sans issue ouverte va très bien, un dépôt avec des issues sans réponse depuis des mois beaucoup moins.

Du coup je partirais plutôt sur :

  1. Dépôt archivé sur GitHub, donc sorti automatiquement du listing. Signal net, déclaré par l’auteur.
  2. Plus tard, un vrai indicateur de santé côté instances (combien la font tourner, combien la voient crasher), qui est la seule mesure honnête de « est-ce que ça marche encore ».

Le 1 et le 2 répondent assez proprement au scénario de @prohand, sans avoir besoin de commission.

Je pense que le 2) pourra être implémenté plus tard, car pour l’instant le projet est encore trop petit pour qu’une telle valeur soit réellement un signal pour l’utilisateur qui arrive depuis HA par exemple.

Sur la « commission d’analyse »

Je ne pense pas que ce soit la bonne réponse. Le jour où on juge de la qualité des intégrations des autres, on recrée le modèle qu’on vient de quitter, avec en prime des débats sans fin. Le sandbox Docker est là pour que ça ne coûte rien à l’utilisateur d’essayer, et une intégration mal fichue ne peut pas déstabiliser son instance. Une seule exception à mes yeux : une image franchement malveillante. Là oui, on pourra mettre en place une blacklist le jour où ça arrive.

Sur me donner les droits mainteneur

Merci de la confiance, mais non :slightly_smiling_face: Tout l’intérêt des intégrations externes, c’était justement de me sortir du chemin critique. Être mainteneur de 40 dépôts que je ne connais pas ne serait qu’une nouvelle forme du même goulot d’étranglement, et un mainteneur qui ne merge rien ne protège personne.

En revanche, la vraie protection est en amont.

Ajoutez un deuxième mainteneur de confiance dès le début, avant d’en avoir besoin :slight_smile:

Il faudrait du coup que pour le scénario 1 un tag « non maintenu » ou « archivé » apparaisse pour informer les utilisateurs qu’officiellement le dépot de l’intégration est archivé et pouvoir les masquer dans Gladys.

Ok pour le scénario 2 également cela permettrai de voir si une intégration est encore bien utilisé et fonctionne toujours.

Pour le mainteneur de confiance à ajouter dès le début il faut pouvoir le trouver :sweat_smile:

Ce que j’ai peur avec tout ceci c’est que l’on voit plusieurs integrations externes arrivent sur le store et que sa soit vite le bazard :upside_down_face:

Justement, le magasin d’intégrations est une marketplace, un peu comme Amazon ou Carrefour.

Si plusieurs intégrations font la même chose, ce n’est pas un bug : c’est précisément le but de cette architecture ! :grinning_face_with_smiling_eyes:

Il faut qu’il puisse y avoir de la concurrence entre les intégrations. C’est un marché libre, et la concurrence est une bonne chose pour le consommateur. Tout comme chez Carrefour, tu peux avoir 5 marques de sauce tomate différentes dans le même rayon : si demain il existe plusieurs intégrations pour une même marque ou un même service, ce sera un gain pour l’utilisateur final, pas un problème.

À nous, en revanche, de construire une plateforme suffisamment transparente pour que cette concurrence puisse réellement profiter aux utilisateurs : nombre d’installations, notes, votes, qualité de la documentation, dernière mise à jour, etc. Autant d’informations qui permettront de comparer facilement les différentes intégrations.

Mais je pense qu’il ne faut surtout pas chercher à restreindre le magasin. Il doit rester ouvert, libre et le plus diversifié possible. C’est justement cette liberté qui permettra aux meilleures intégrations de s’imposer naturellement. :slight_smile:

Ok parfait c’est ok pour moi avec les explications :slight_smile:
Merci

Est-ce que tu as moyen d’exclure une intégration si elle présente un risque de sécurité ou de problème pour Gladys ?

Tout est possible :slight_smile: