 Pues gracias a todos por haber estado aquí. A ver, mi pregunta es, has hablado de las unidades sociales de equipos de mantenimiento y todo esto, a la hora de arreglar un desarrollador, arregla fallos. ¿Cómo os coordenáis con el autor del paquete, no con la organización de bienes? Pues eso es, lo hace cada equipo o persona, título personal. Y normalmente intentamos, sentimos que es bueno que cada autor, perdón, cada encargado del paquete tenga una buena relación con su upstream. Básicamente la relación normalmente se consiste en informar de errores, errores que llegan al sistema de informe de errores de Debian, es decir, pues un usuario nuestro ha informado este error, yo lo he intentado reproducir y me da el problema y además, pues a lo mejor si puede, he investigado un poco y creo que pasa por esto, puedes echarle un vistazo. Entonces ahí se crea una relación que el autor proporciona fixes y nosotros ayudamos a mejorar el software transmitiendo esos errores. También pues estamos en coordinación cercana muchas veces para saber cuándo va a ser la nueva liberación del software, para saber a lo mejor Debian está aproximándose a un congelamiento por la nueva versión y les mandamos un correo diciendo, pues dentro de poco nos vamos a congelar, si te interesa, sí, cubitos, si te interesa que la nueva versión esté pues estaría bien que la sacaras dentro de no mucho, tal y cual. Pero eso se hace no de manera institucional, sino a título de cada encargado personal. Pues nada, muchas gracias. La próxima vez me quedo más rato aquí de pie. Mi pregunta es un poco el mantenimiento de paquetes que ya están en la versión estable. Sí. Cuando, en teoría, se supone que los nuevos cambios suelen ser por temas de seguridad o por algún fallo que se haya encontrado. Pero a mí me sucedió que necesitaba hacer unos pequeños cambios de funcionalidad y envíe un patch, era en PHP4 en concreto. Lo envíe tanto upstream como al mantenedor de Debian y era un cambio mínimo, pero que personalmente me resolvía una historia y que yo creo que no añadía ningún posible riesgo tal y me fue rechazado porque decían, bueno, esto no es un tema de seguridad y entonces no podemos aceptar este cambio, el tema. Puedes utilizar la versión de testing o la versión más avanzada. Sí, el problema es que el hecho de decir la decisión, decir esto es un cambio que arregla un pequeño bug y es un cambio muy pequeño y no comporta ningún riesgo. Decir eso es muy arriesgado. No, lo es, porque Debian, o sea, estable no significa sólo que es estable, sino que no cambia. ¿Por qué? Por lo siguiente. Imagínate que una empresa o una entidad o una institución hace un deployment de Debian en muchas máquinas y utilizan PHP4. Y no tan el error este, que es un error no es grave, o sea, en estable solo se arreglan errores de seguridad y errores importantes graves, pues como que el paquete no funciona en absoluto o se coma tus ficheros o cosas del estilo, aunque quizá últimamente se ha sido un poco más permisivo, pero siempre cosas importantes. Si tú cambias algo que es poco importante, pero que aún así es un bug, quizá esa institución que tenía un despliegue más a Debian había notado lo mismo y había adaptado su software a hacer un workaround de ese bug, porque saben que Debian no va a cambiar, eso lo van a tener ahí tres, cuatro años y dicen, bueno, pues nosotros hacemos el workaround y ya está. Si de repente viene una nueva versión del paquete que lo cambia, pues aunque el software sea mejor, ha roto el setup de alguien. Entonces es peligroso porque puede no tener riesgo, pero alguien está dependiendo de ese comportamiento buggy para que sus sistemas continúen funcionando. Entonces en ese sentido estable no es solo de buena calidad que lo intentamos, sino que no cambia. Por ahí detrás, hola por cierto. Hola exactamente, veo que tiene buena vista. Desde Guadalines intentamos incluir alguno de los desarrollos que hemos hecho en Debian y hacer algún tipo de colaboración. Y no voy a decir nombres, pero el técnico que lo intentó me dijo el otro día imposible totalmente meter o si bien si no el paquete, los desarrollos, conseguir un empaquetador o algo así para una mejora porque es que hay como animas versión o algo así, no sé. Y digo, pero vamos a ver, a ver si te está equivocando, dime los hechos fríos. Mira, es un programa que sirve para calcular la suma MD5 desde Nautilu, una tontería, pero que aporta usabilidad y tal. Y me han dicho que eso, ya hay muchos programas parecidos y que eso no hace falta. Digo, esa es la razón que te ha dado un mantenedor de Debian oficial para no incluir este desarrollo. Me parece raro, pero por lo visto era así. A ver, te hago un par de preguntas y entonces contesto, ¿vale? No sé toda la historia. Bueno, te la puedo aclarar mañana. No, es por saber, esto era un nuevo software que se quería introducir en Debian completamente nuevo o un cambio a un software de asistente. No, un desarrollo nuevo. O sea, es como un tipo de plugin para Nautilus. Algo así. No toca código asistente. Ya, un paquete nuevo, ¿no? Pues, pues no sé quién te diría eso. Sí que hay tendencia, sí que hay como una tendencia en Debian últimamente causada, yo creo, por la conciencia de que tenemos muchísimos paquetes y cada paquete se añade peso y limita la velocidad a la que nos podemos mover. Hay una tendencia en la lista de desarrollo cada vez que se introduce un nuevo software. A decir, pero esto ya lo hacen otros paquetes. Esto, ¿por qué este es mejor? Porque hay que introducirlo en Debian, ¿no? Esa era un poco la respuesta, ¿no? En ese sentido. Sí, pero no parecía algo muy abierto, ni muy colaborativo, ni muy democrático, sino una persona dijo, a mí no me parece bien. Eso, y entonces no. Eso es un problema. Porque muchas veces tenemos desarrolladores hablando y se toma como un desarrollador hablando como la palabra canónica del proyecto, ¿vale? Y no es así. Es, a lo mejor, un desarrollador que habla por sí mismo y otros desarrolladores piensan distinto. Entonces, la imagen parece a una persona de fuera o de semifuera. Le puede parecer que el proyecto entero piensa así y no es necesariamente. Entonces, por ejemplo, en ese caso, yo estoy seguro que podría subir el paquete y al final, ¿quién tiene que hacer la decisión? Son cuatro, cinco, seis desarrolladores que están a cargo del archivo de Debian y son ellos su área de responsabilidad es esa y por mucho que digan otros desarrolladores en la lista, si ellos deciden que entra, entra y si deciden que no, no. Si deciden que no, se puede discutir y si deciden que sí, se puede discutir. Pero uno siempre debería intentar ir a la fuente canónica de tu respuesta. El problema que tú tienes, pues, quien te tiene que responder es el que tiene la última palabra en esa área. Por eso digo que es importante entender Debian porque el problema este, ¿te crees que lo que te han dicho es la respuesta de Debian y no lo es? Otra cosa hubiera sido que hubiera sido un parche, una mejora a un software existente y el mantenedor de ese paquete hubiera dicho no, esto no, ahí es más difícil. Ahí, pues a lo mejor podría haber ido mejor upstream o lo que sea. Entiendes lo que quiero decir, ¿no? Sí, lo que pasa que a veces, yo creo que entendible esa crítica que sea derivada de Debian, es que no devuelve nada a Debian, es que a lo mejor no es tan fácil, ¿no? Ya, es que hay muchas personas de Debian y hay gente a las que consideran las derivadas algo valioso y hay gente que no les gusta, lamentablemente. Entonces, en ese sentido yo sí comprendo que Debian puede ser un proyecto difícil de trabajar con, pero eso no pasa solo fuera, dentro muchas veces hay dificultades. Bueno, nosotros no vamos a dejar de intentarlo, tres veces, a la cuarta ya no nos dedicaremos a otra cosa más productiva, pero de momento seguimos intentándolo. Bien, yo en ese caso en concreto te recomendaría que lo subieras. Espera el micrófono, por favor. Realís, manager, como puesto que desempeñas, hay ciertos tipos de proyecto, si me miran ahora la cabeza, el FIFOS o aquí el Ice Waste, que de Madrid, en la origen de Madrid tienen opciones para actualizarse ellos mismos contra el proyecto de Madrid. Vosotros decís, bueno, nosotros, dado que tenemos diferencia de modificarlo, vamos a hacer un bypass de estas opciones y solamente podremos, digo, te pregunto, no sé cómo es, solamente se podrá actualizar contra el archivo oficial de Debian. A ver, ¿me entiendes lo que quiere decir? Sí, sí, entiendo lo que querés decir. En el caso de Inso, de Eclipse. En el caso de Inso, de Eclipse, bueno, la idea es, ahí habría que diferenciar a dos cosas distintas. Una cosa es que sea el programa en sí, lo que se actualiza, y otra cosa es que sea, pues, plugins, que no están empaquetados los que se actualizan. No, es un caso muy diferente. Si algo está no empaquetado, pues el usuario lo tiene que obtener de cualquier manera y no hay ningún problema en que se actualice solo. Pero si es algo que está empaquetado en Debian, pues, dos cosas. Por una parte, la actualización que el proyecto puede ofrecer automática no va a estar integrada en Debian, va a instalar el binario en otro sitio, en sitio que no es compatible, etcétera, etcétera, no va a ser compatible, va a estar en otro sitio. Y la segunda consideración es que, aunque incluso lo fuera, aunque fuera compatible, cuando un encargado de un paquete en Debian sube en la nueva versión, en principio se compromete a que la ha compilado, ha obtenido, la ha compilado y la ha aprobado y se ha asegurado de que se entrega bien con la versión actual de Debian. Si a ti se te actualiza el software automáticamente, seguramente nadie ha comprobado que funcione bien en el estado de Debian actual. Y tú le das sí, nueva versión, qué bien y de repente no te funciona el software. Cuando la actualización viene de Debian, pues a menos que haya videoerrores por el camino, en principio tienes la garantía de que va a funcionar, ¿vale? Bueno, queda muy pocos minutos, no sé si hay alguna última pregunta, pues me dicen que termine, así que...