Hola,
Me preguntaba algo que creo que es interesante.
Si un desarrollador ya no mantiene una integración y queremos retomarla, ¿cómo se hace?
Porque si la copiamos a otro repositorio y la publicamos, aparecerán 2 integraciones en la tienda 
Otra pregunta, ¿qué pasa si 2 personas publican la misma integración externa?
Gracias
¡Excelentes preguntas!
Puedes echar un vistazo al mercado de Jeedom y te darás cuenta de que es un poco el caos.
Después hay cosas comunitarias y de pago, por lo que a menudo encuentras varios plugins para el mismo servicio, y no he visto ninguna solución, vive y muere sin desaparecer en el mismo lugar.
No sé, hace falta una « comisión » de análisis para las integraciones duplicadas o las que tienen fallos y no se actualizan, en todo caso hay un tema real sobre esto.
Personalmente no me sorprendería si una integración muy poco mantenida fuera eliminada de la tienda (siempre activa para quienes ya la instalaron, pero no disponible en la lista / no instalable). De lo contrario, ¡será un caos!
Es una de las debilidades del código abierto. Depende del tiempo y la inversión de la persona que mantiene el proyecto. Siempre es posible dar los derechos de « mantenimiento » a varias personas de confianza, lo que limita los riesgos.
Precisamente, ¿no sería mejor dar los derechos ahora a @pierre-gilles o a una o dos personas de confianza más?
¿Qué opinan?
¡Muy buena pregunta y llega en el momento adecuado, antes de que el catálogo crezca demasiado 
Lo que ya existe hoy
Una integración no está « registrada » en ningún lugar: el indexador pasa cada hora por los repositorios públicos que llevan el tema de GitHub gladys-assistant-integration, lee el manifiesto, verifica la imagen Docker y publica el catálogo. Consecuencias directas:
docker_image a su propio registro, agregar el tema, publicar. No se necesita pedir permiso a nadie.Sobre el duplicado que esto genera
Sí, terminamos con dos entradas, y no, no tengo la intención de desduplicar. Una tienda sin revisión que rechaza los duplicados es una tienda con un árbitro, y el árbitro se convierte en un cuello de botella nuevamente. La verdadera palanca es la señal, no el filtro.
Al principio, pensé en una insignia « no mantenida desde X meses », pero al reflexionar es una falsa buena idea. Muchas integraciones simplemente están terminadas: una integración Tempo o Free Mobile puede no moverse durante un año porque funciona, simplemente. A la inversa, una integración en la nube puede romperse mañana porque el proveedor cambió su API, sin el menor commit. La fecha de la última versión no mide ni lo uno ni lo otro, y la única forma de hacer saltar la insignia sería publicar versiones cosméticas. Mala incentiva, e injusta para quienes han hecho bien el trabajo.
Lo que realmente distingue « abandonada » de « terminada » es la reactividad: un repositorio sin commits durante un año y sin issues abiertas está muy bien, un repositorio con issues sin respuesta durante meses mucho menos.
Por lo tanto, iría más bien a:
El 1 y el 2 responden bastante limpiamente al escenario de @prohand, sin necesidad de comisión.
Creo que el 2) podrá implementarse más tarde, porque por ahora el proyecto es demasiado pequeño para que tal valor sea realmente una señal para el usuario que llega desde HA, por ejemplo.
Sobre la « comisión de análisis »
No creo que sea la respuesta correcta. El día en que juzgamos la calidad de las integraciones de los demás, recreamos el modelo del que acabamos de salir, con el bonus de debates interminables. El sandbox Docker está ahí para que no cueste nada al usuario probar, y una integración mal hecha no puede desestabilizar su instancia. Una sola excepción a mis ojos: una imagen francamente maliciosa. Allí sí, podremos establecer una lista negra el día que ocurra.
Sobre darme los derechos de mantenedor
Gracias por la confianza, pero no Todo el interés de las integraciones externas era precisamente sacarme del camino crítico. Ser mantenedor de 40 repositorios que no conozco sería solo una nueva forma del mismo cuello de botella, y un mantenedor que no mergea nada no protege a nadie.
En cambio, la verdadera protección está aguas arriba.
Añade un segundo mantenedor de confianza desde el principio, antes de necesitarlo 
En ese caso, para el escenario 1, debería aparecer una etiqueta « no mantenido » o « archivado » para informar a los usuarios de que oficialmente el repositorio de la integración está archivado y poder ocultarlos en Gladys.
De acuerdo también con el escenario 2, esto permitiría ver si una integración aún se usa y funciona correctamente.
Para el mantenedor de confianza que se debe agregar desde el principio, hay que poder encontrarlo
Lo que me preocupa con todo esto es que veamos varias integraciones externas llegar a la tienda y que sea rápidamente un desastre 
Precisamente, la tienda de integraciones es una marketplace, un poco como Amazon o Carrefour.
Si varias integraciones hacen lo mismo, no es un error: ¡es exactamente el objetivo de esta arquitectura! 
Debe haber competencia entre las integraciones. Es un mercado libre, y la competencia es buena para el consumidor. Al igual que en Carrefour, puedes tener 5 marcas diferentes de salsa de tomate en el mismo pasillo: si mañana existen varias integraciones para una misma marca o servicio, será una ventaja para el usuario final, no un problema.
A nosotros, en cambio, nos corresponde construir una plataforma lo suficientemente transparente para que esta competencia pueda beneficiar realmente a los usuarios: número de instalaciones, calificaciones, votos, calidad de la documentación, última actualización, etc. Tantos datos que permitirán comparar fácilmente las diferentes integraciones.
Pero creo que no debemos buscar restringir la tienda. Debe seguir siendo abierta, libre y lo más diversa posible. Es precisamente esta libertad la que permitirá que las mejores integraciones se impongan naturalmente.
Vale, perfecto, está bien para mí con las explicaciones
Gracias
¿Tienes forma de excluir una integración si presenta un riesgo de seguridad o un problema para Gladys?
Todo es posible