De un traductor: este texto es una traducción de una publicación de blog personal de Michael Stapelberg, un destacado desarrollador de código abierto ( perfil de GitHub ), que realizó una contribución significativa al desarrollo de Debian.
Esta publicación fue difícil de escribir desde un punto de vista emocional, pero no me limité a "una carta corta, porque no tenía tiempo". Por favor, antes de leer este texto, tenga en cuenta que lo estoy escribiendo con las mejores intenciones y no me propongo el objetivo de desmotivar o menospreciar la contribución de uno de los desarrolladores. Más bien, quiero explicar por qué mi nivel de frustración superó todos los valores aceptables.
Debian ha sido parte de mi vida durante 10 años.
Hace unas semanas, en una reunión de Debian en Zurich, me reuní con mis viejos amigos a quienes no había visto en muchos años. Cuando ya estaba manejando mi bicicleta a casa, me di cuenta de que todos los temas que habíamos discutido de alguna manera se reducían a lo que discutimos con ellos la última vez. Discutimos los méritos de systemd, que una vez más atrajo la atención de la comunidad de código abierto, tocamos el tema de los procesos en Debian. La culminación fue la discusión de la democracia como tal y los correspondientes errores teóricos y prácticos. Pero, de hecho, este es un tema puramente suizo.
Esta no es una revisión del pasado mitap, solo quiero explicar lo que me hizo pensar en mi actitud actual hacia Debian y si me conviene.
Entonces, tomé una decisión que tuve que tomar hace mucho tiempo: estoy restringiendo mi participación en el desarrollo de Debian.
¿Qué significa esto?
En las próximas semanas, sucederá lo siguiente:
- Le pasaré paquetes importantes al comando mantenido;
- Me eliminaré de los paquetes de Uploaders que contienen otros mantenedores;
- los paquetes en los que yo era la única escolta quedarían huérfanos.
Intentaré continuar manteniendo las páginas
manpages.debian.org y el servicio
codesearch.debian.net , pero agradeceré cualquier ayuda en esta área.
Si tiene alguna pregunta o alguna tarea, considere que estoy de vacaciones indefinidas. Intentaré participar en algunos asuntos administrativos (por ejemplo, la transferencia de permisos) y tareas dirigidas personalmente a mí, pero solo si no toma mucho tiempo.
Por qué
Cuando me uní a Debian, todavía estaba estudiando, es decir, tenía mucho tiempo libre. Ahora, después de cinco años de tiempo completo, he aprendido mucho, tanto en términos de cómo y qué funciona en grandes proyectos de desarrollo de software como en términos de comprender mis preferencias personales en los sistemas informáticos. Ahora sé claramente en qué paso esa pequeña parte de mi tiempo libre y en lo que me queda al final del día.
Cada una de las siguientes secciones se centrará en cosas que me duelen como desarrollador. Esta lista se da en orden aleatorio. Algunos de estos problemas se afectan entre sí, por ejemplo: si los cambios en el sistema se llevaran a cabo mejor, tendríamos la posibilidad de que los paquetes fueran más fáciles de manejar por la máquina.
Proceso de cambio de Debian
En los últimos años, mi equipo actual ha estado trabajando en varias reorganizaciones en toda la base del código (que afecta a miles de proyectos), por lo que hemos recibido muchas lecciones valiosas sobre cómo realizar estos cambios de manera eficiente. Me molesta que Debian funcione en casi todos los sentidos de manera casi opuesta. Aprecio el hecho de que cada proyecto es diferente, pero creo que muchos de los puntos enumerados a continuación se aplican a Debian en su conjunto.
En Debian, el desarrollo de paquetes se dirige en la dirección correcta utilizando un documento llamado Política de Debian, o su versión de software
, Lintian .
A pesar del hecho de que la pelusa es muy conveniente para obtener una respuesta rápida directa o local / autónoma, es aún mejor no requerir tal herramienta en absoluto. Por ejemplo, un comando C ++ que introduce un nuevo indicador de seguridad para todos los paquetes también debería poder hacer que su trabajo sea transparente (a
juzgar por el perfil de GitHub, el idioma principal de Go es Michael, aprox. Trans. ).
En cambio, ahora todos los paquetes se están haciendo "sucios" (orig. - lint-unclean): todos los asistentes deben leer qué es esta nueva cosa, cómo se puede romper, si afecta su trabajo en general y, de ser así, cómo. Luego debe ejecutar manualmente algunas pruebas y, finalmente, descartar los cambios. Todo esto es una multitud de operaciones mecánicas manuales y generales entre paquetes.
En el modelo de Debian, la
decisión de desplegar las noticias recae en los paquetes adjuntos, y no en los desarrolladores. En mi trabajo principal, descubrimos que es más eficiente hacer lo contrario: si el cambio escrito afecta a una parte significativa de los usuarios, entonces son los desarrolladores quienes deben decidir sobre la necesidad de su implementación. Este enfoque hace que el desarrollo del proyecto sea más eficiente y reduce el tiempo y los costos laborales. Por supuesto, hay excepciones, por ejemplo, en grandes áreas donde se usan chips de idioma, que deben ser atendidos por los respectivos propietarios de los conservadores, pero lo importante es que, por defecto, todo debería ser diferente de lo que es ahora.
Debian
carece de herramientas para realizar cambios importantes : es programáticamente difícil trabajar con paquetes y repositorios fragmentados (más sobre esto en la sección a continuación). El evento más cercano al “envío de cambios a la revisión” predeterminado es el proceso de abrir un informe de error con un parche adjunto. Me pareció que el proceso existente de aceptar una corrección de errores era demasiado complicado, y comencé a trabajar en un robot de fusión, pero solo Guido y nadie más mostraron interés en él (
aparentemente, el autor habla sobre Guido agx Gunter , otro desarrollador de Debian, - aprox .
Para decirlo literariamente, la reacción al empuje y, en consecuencia, la recepción de comentarios son lentas. Simplemente no hay plazos. A veces recibo correos electrónicos notificándome que el parche que envié hace varios años (!!!) finalmente estaba contenido. Esto estira los proyectos semanales durante muchos años, lo que para mí es un poderoso desmotivador.
Es curioso notarlo, pero la práctica de la actividad en línea de tortugas también se proyecta en la cultura fuera de línea, y no quiero discutir las ventajas de systemd 10 años después de haberme enterado por primera vez.
Y finalmente, cualquier cambio puede ser estancado por aquellos que no están de acuerdo, quienes finalmente se niegan a cooperar. Mi ejemplo canónico de esta situación es rsync. El curador rechazó mis parches, que agregan un soporte más sencillo al paquete, únicamente por sus propias creencias.
Otorgar tal grado de libertad personal a los mantenedores individuales nos impide a todos los participantes del proyecto elevar el nivel de abstracción de la compilación de Debian, lo que, a su vez, complica las herramientas de desarrollo.
¿Cómo se vería todo en un mundo ideal?
- Como proyecto, debemos luchar por la unificación. Después de todo, la unificación no excluye los experimentos; simplemente cambia el compromiso actual entre los experimentos más simples y la automatización más compleja en un compromiso entre los experimentos más complejos y la automatización más simple.
- Nuestra cultura de desarrollo debe alejarse del paradigma "este paquete es mi hogar, cómo te atreves a tocarlo", un sentido común de propiedad, en el que cualquier participante puede hacer o verificar cambios fácilmente, incluso sin involucrar a curadores específicos que los acompañan.
Para comprender cómo pueden ser los cambios (parches) exitosos, le recomiendo que lea
la charla de mi colega Hyrum Wright,
"Cambios a gran escala en Google: lecciones aprendidas de migraciones masivas de cinco años" .
Flujo de trabajo e infraestructura fragmentados
Debian generalmente prefiere enfoques descentralizados sobre los centralizados. Por ejemplo, los paquetes separados se almacenan en repositorios separados, y cada repositorio puede usar cualquier SCM (generalmente git y svn) o ninguno. Además, cada repositorio se puede alojar en cualquier sitio. Por supuesto, el contenido de cada repositorio también varía ligeramente de un equipo a otro, e incluso dentro del equipo.
En la práctica, las opciones de alojamiento no estándar rara vez se usan, ya que no justifican su costo, pero con la frecuencia suficiente como para causar un gran dolor al intentar automatizar el proceso de realizar cambios en los paquetes. Entonces, en lugar de usar la API de GitLab para crear solicitudes de fusión, debe desarrollar un sistema completamente diferente y más complejo que funcione con repositorios inaccesibles periódicamente (¡o constantemente!), Abstrae las diferencias en los parches entregados (informes de error, solicitudes de fusión , solicitudes de extracción) y así sucesivamente ...
Procesos de desarrollo radicalmente diferentes no son solo una pérdida de tiempo. Participé en largas discusiones sobre varios procesos de desarrollo de git durante DebConf 13 y me di cuenta de que se estaban llevando a cabo discusiones similares en ese momento.
Personalmente, no puedo tener en cuenta suficientes detalles sobre las diversas metodologías de desarrollo. Cada vez que toco un paquete que no funciona como el mío, me molesto mucho porque tengo que volver a examinar aspectos de su trabajo.
Noté una fragmentación similar del flujo de trabajo en mi propio equipo de empaquetado de Go e intenté solucionarlo
haciendo sugerencias para cambios en el flujo de trabajo , pero no pude implementarlos. La falta de automatización efectiva y la baja tasa de cambio en las herramientas, a pesar de mi disposición a gastar mi propio tiempo y energía, mataron cualquier motivación.
Infraestructura obsoleta: descargar paquetes
Cuando desea que un paquete esté disponible en Debian, carga archivos firmados por GPG a través de FTP anónimo. Hay varios tipos de tareas (daemon de cola, sin marcar, dinstall y otras) que se ejecutan en un horario fijo (por ejemplo, dinstall se ejecuta a las 01:52 UTC, 07:52 UTC, 13:52 UTC y 19:52 UTC).
Calculé que dependiendo de la hora del día, puede esperar más de 7 horas (!!!) antes de instalar su paquete.
Pero la peor parte para mí es que la retroalimentación es asíncrona con respecto a la carga. Me gusta hacer algo, terminarlo y pasar a la siguiente tarea. La configuración actual requiere una larga espera y, de hecho, un cambio costoso entre tareas sin buenas razones técnicas. Puede notar que unos minutos realmente no importan, pero cuando todo el tiempo del día que puedo dedicar a Debian se mide en minutos, es de gran importancia percibir mi propio desempeño y satisfacción por el trabajo realizado.
El último mensaje que puedo encontrar sobre acelerar este proceso es una
publicación de George Ganneff Jaspert de 2008.
¿Cómo se vería todo en un mundo ideal?
- El FTP anónimo sería reemplazado por un servicio web que acepte mi paquete y devuelva en su respuesta una decisión oficial de aceptarlo o rechazarlo.
- Para los paquetes recibidos, hay una página que muestra el estado de la compilación y la hora en que el paquete estará disponible a través de una red de espejos.
- Los paquetes deben estar disponibles a los pocos minutos de completar el ensamblaje.
Infraestructura obsoleta: Bug Tracker
Tengo miedo de interactuar con el rastreador de errores de Debian. Debbugs es un código directo de 1994 que actualmente solo usa Debian y el proyecto GNU.
Los procesos de Debbugs se basan en el uso del correo electrónico, es decir, son asíncronos y engorrosos. A pesar de que funciona en las máquinas más rápidas que tenemos en el proyecto Debian (bueno, me dijeron cuándo se planteó este tema por última vez), su interfaz web se carga extremadamente lentamente.
En particular, la interfaz web en bugs.debian.org es de solo lectura.
Configurar un
espacio de
trabajo de correo electrónico para
reportbug (1) o trabajar manualmente con archivos adjuntos es un desafío bastante serio.
Por alguna razón que no entiendo, cada interacción con debbugs conduce a
muchas conversaciones .
Además de la implementación técnica, tampoco puedo recordar de ninguna manera las diversas formas en que Debian usa paquetes de pseudogeneración para errores y procesos. Los necesito muy raramente para que finalmente pueda ponerlo todo en mi cabeza y recordar exactamente cómo funcionan y se usan, pero ocasionalmente los encuentro, por lo que esta variedad es molesta.
¿Cómo se vería todo en un mundo ideal?
- Debian cambiará de una forma no estándar de seguimiento de errores a (cualquiera) ya resuelta.
- Debian automatiza estos procesos. La interfaz principal debería ser más conveniente (por ejemplo, un formulario web).
Infraestructura obsoleta: archivos de correspondencia por correo electrónico
Estoy confundido por el hecho de que en 2019 todavía no tenemos una herramienta conveniente para ver los hilos de discusión archivados en el correo. Tan ampliamente como en Debian, el correo electrónico y las conversaciones ya no se usan en ningún lado, por lo que es algo irónico. El uso de
Gmane pareció resolver este problema, pero su disponibilidad en los últimos años ha sido, por decirlo suavemente, abrupta (ahora, al momento de escribir esta publicación, no funciona en absoluto).
Traté de crear un archivo de subprocesos múltiples, pero nuestros maestros de hoja no quedaron impresionados y se negaron a apoyar el proyecto.
Es difícil para las máquinas trabajar con Debian
Aunque es obvio que puede trabajar con paquetes Debian mediante programación, esta experiencia no es agradable. Todo parece lento y voluminoso. Seleccioné tres pequeños ejemplos para ilustrar mi posición sobre este tema.
debiman necesita
ayuda de piuparts para analizar el mecanismo alternativo de cada paquete para mostrar páginas de documentación, por ejemplo,
PSQL (1) . Esto era necesario porque los scripts modifican la base de datos alternativa llamando a los scripts de shell. Pero sin instalar realmente el paquete, no sabrá qué cambios realiza.
pk4 debe mantener su propio caché para buscar metadatos de paquetes en función de su nombre. Otras herramientas analizan la base de datos de apt desde cero con cada llamada. El formato correcto de la base de datos, o al menos el formato de intercambio binario, será de gran importancia para este proceso.
Debian Code Search quiere recibir nuevos paquetes lo más rápido posible. La instancia de
fedmsg se utilizó anteriormente, pero ya no existe. No está claro dónde recibir notificaciones de nuevos paquetes y dónde es mejor recibirlos.
Pila de compilación compleja
Aquí puede leer mi publicación
"Herramientas de compilación del paquete Debian" . Lo que realmente me preocupa es el hecho de que aumentar el número de herramientas no se considera un problema.
Debian es una experiencia dolorosa para un desarrollador
La mayoría de las preguntas que planteé se refieren a la experiencia de desarrollo de Debian, pero, como describí recientemente en mi publicación de
Debian Debug Debugging Experience , la experiencia de desarrollo que
usa Debian también deja mucho que desear.
Tengo mas ideas
El artículo resultó ser bastante voluminoso, pero espero que tengas una idea aproximada de mi motivación.
Aunque describí una serie de fallas específicas arriba, el último clavo en la tapa del ataúd es la falta de una perspectiva positiva para el futuro. Tengo otras ideas que me parecen realmente convincentes, pero, según el progreso de mis proyectos anteriores, no creo que pueda implementar ninguna de ellas como parte del proyecto Debian.
Tengo la intención de publicar algunas publicaciones más sobre formas específicas de mejorar los sistemas operativos en mi blog. Así que entra.
Y finalmente, espero que esta publicación inspire a alguien, idealmente a un grupo de personas, a mejorar la vida de los desarrolladores de Debian.