Très bonne question, et elle arrive au bon moment, avant que le catalogue ne grossisse trop 
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 :
- Dépôt archivé sur GitHub, donc sorti automatiquement du listing. Signal net, déclaré par l’auteur.
- 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
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 