¿Por qué algunos proyectos grandes, como Git y Debian, solo usan una lista de correo y no un rastreador de problemas?

La preferencia que observa parece una consecuencia natural de una recomendación claramente establecida en Normas de codificación de GNU . Se sugiere reportar errores por correo electrónico, como puede ver en la siguiente cita (marqué en negrita la parte que trata directamente sus observaciones):

  

4.7.2 --help

     

La opción estándar --help debe generar una breve documentación sobre cómo invocar el programa, en la salida estándar y luego salir con éxito. Otras opciones y argumentos deben ignorarse una vez que se vea esto, y el programa no debe realizar su función normal.

     

Cerca del final de la salida de la opción ‘--help’ , coloque líneas que proporcionen la dirección de correo electrónico para los informes de error , la página de inicio del paquete (normalmente ‘http://www.gnu.org/software/pkg’ , y la página general para obtener ayuda con GNU) programas. El formato debe ser así:

    Report bugs to: mailing-address
    pkg home page: <http://www.gnu.org/software/pkg/>
    General help using GNU software: <http://www.gnu.org/gethelp/>

     

Está bien mencionar otras listas de correo y páginas web apropiadas.

La preferencia anterior, a su vez, refleja la aceptación universal del correo electrónico como una forma de comunicación electrónica. Se supone que cualquier usuario que lea el mensaje --help como se sugirió anteriormente debe entender fácilmente qué hacer si ve un error: enviarlo por correo es fácil.

El rastreador de problemas puede ser (y creo que es ) mejor para un desarrollador que trabaja en el proyecto, pero para una audiencia más amplia sería más difícil presentar y explicar cómo usarlo, especialmente teniendo en cuenta gran variedad de cuentas y diferencias entre los diferentes sistemas de seguimiento de problemas .

Un proyecto puede usar Bugzilla, otro se quedará con JIRA, tercero con ... GNATS , etc, etc., simplemente no hay forma de presentar todo este" zoológico "de una manera que sea tan estándar y uniforme como

  

Report bugs to: mailing-address

La nota anterior no significa que los proyectos no deban usar el rastreador de problemas internamente . Como se explica en una excelente respuesta a la pregunta relacionada ,

  

Su rastreador de errores es para su conveniencia , no para sus clientes. Si no puede molestarse en tomar su teléfono o correo electrónico e ingresarlo, ¿cómo cree que se sienten?

     

Debe poder ingresar problemas y asignarlos manualmente a un cliente ...

En particular, con Git, hay una razón histórica simple: Git fue iniciado por hackers de Linux para hackers de Linux, y utiliza el mismo modelo de desarrollo y herramientas que el propio Linux. Sin embargo, Linux es más antiguo que WWW, por lo tanto, cuando Linux se inició allí simplemente no tenía rastreadores de problemas basados en web, porque no había web!

Como consecuencia, la comunidad de Linux ha desarrollado herramientas y flujos de trabajo extremadamente eficientes para manejar los informes de errores y las revisiones de código a través del correo electrónico, y no había ninguna razón para que desecharan todo ese trabajo y comenzaran desde cero cuando empezaron el Proyecto Git.

Para Git:

Hay varias discusiones en la lista de correo donde la gente propone usar algún tipo de rastreador de errores. Parece que todas estas iniciativas se han esfumado, por lo que la razón por la que Git no usa un rastreador de errores es simplemente porque la mayoría de los contribuyentes no lo encuentran útil.

En un publicación en la lista de correo , Junio C Hamano (mantenedor de Git) Resumiendo por qué siente que un bug tracker no es muy útil. No quiero incluir la publicación completa (es bastante larga), pero se reduce a:

• Si solo está buscando información sobre problemas resueltos, buscar en los archivos de la lista funciona tan bien como buscar un rastreador de errores.
• Si informa un error genuino y la gente quiere cuidarlo, la lista también funciona bien.
• Si nadie está interesado en trabajar en un problema, caerá a través de las grietas, incluso en un rastreador de errores.
• Un rastreador de errores sería un sistema más que se debe mantener, buscar nuevos errores con regularidad, tener errores solucionados, etc., en breve, trabajo extra para un pequeño beneficio.

Debian utiliza un rastreador de errores, su interfaz predeterminada es el correo electrónico. Y es conveniente. Lucas Nussbaum, actual líder del proyecto Debian, publicado hace unos días :

  

debbugs es la pieza de software detrás del sistema de seguimiento de errores de Debian   (BTS). También es utilizado por el proyecto GNU. A pesar de ser a menudo   percibido como de estilo antiguo, presenta varias características únicas, como la   Seguimiento del estado de los errores en cada versión y rama de un paquete.   ), o la capacidad de realizar todas las interacciones por correo electrónico, lo que hace que sea muy fácil trabajar sin conexión o en entornos con poca conexión.

La última parte es una función asesina aquí: ¡simplemente encola esos informes en tu cola de correo local hasta que te bajes del avión!

• Mantiene a los niños de 9 años fuera.
• No es necesario crear una cuenta separada para cada foro.
• [menor] Experiencia de usuario consistente en diferentes listas de correo y una curva de aprendizaje cero al suscribirse a una nueva lista.
• Funciona sin conexión. Podrías conectarte a internet y descargar un lote. de correos, luego vaya de excursión, escriba sus respuestas mientras disfruta de la madre Naturaleza y enviarlos más tarde.
• Permite el cifrado y / o la firma de correo a través de GPG.
• Descentralizado: si el foro falla, todavía tendrías una copia, es también resistente a la manipulación, un malvado moderador / hacker no puede manipular fácilmente con lo que has dicho. Nadie puede deshacer la historia.
• Permite filtros, carpetas y todas las funciones organizativas avanzadas de un Cliente de correo electrónico.
• "Notificaciones push": puede dejar abierto su cliente de correo electrónico y obtener notificaciones de nuevas respuestas.
• Un lugar para gobernarlos a todos: no es necesario saltar entre diferentes sitios.
• Inmune a todas las vulnerabilidades de seguridad relacionadas con la web (html / javascript / injection, etc)
• Sin hinchazón: sin distintivos, firmas de lujo, anuncios, balizas web, javascript bloat. Todo es simple y al punto: discusión.
• Menos carga del servidor que una configuración LAMP.

Una desventaja de las listas de correo que viene a la mente es que los foros se dividen en categorías y subcategorías, mientras que las listas de correo no lo son. Esto se puede emular dividiendo una lista de correo en varias listas de correo, y luego los usuarios pueden usar los filtros apropiados para colocar cada mensaje con su carpeta correspondiente (cada carpeta es una categoría). En los foros web, esto es automático.