¬ŅPor qu√© estoy reduciendo mi trabajo en Debian?



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?

  1. 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.
  2. 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?

  1. 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.
  2. 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.
  3. 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?

  1. Debian cambiar√° de una forma no est√°ndar de seguimiento de errores a (cualquiera) ya resuelta.
  2. 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.

Source: https://habr.com/ru/post/443490/


All Articles