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

65

El rastreador de errores para cualquier proyecto de tamaño decente me parece un poco obvio: hace que sea muy fácil organizar cientos o miles de problemas, sin problemas de colisión o confusión.

Entonces, cuando veo algunos proyectos realmente grandes, como Git, usando una lista de correo como el método principal para coordinar el mantenimiento y el desarrollo, me quedo un poco impresionado. Ejemplos:

Git - Página de la comunidad :

... Los informes de errores deben enviarse a esta lista de correo.
Sistema de seguimiento de errores de Debian , según Wikipedia:

... Su característica única es que no tiene ninguna forma de interfaz web para editar informes de errores: todas las modificaciones se realizan por correo electrónico.

Muchos rastreadores de errores modernos tienen una muy buena integración con el correo electrónico (puede recibir comentarios o notificaciones sobre errores que está viendo, o que se le asignan), así como a los sistemas de control de versiones (las confirmaciones pueden marcarse como resolución de un problema, etc. .). Gran parte de esto tendría que hacerse manualmente con una lista de correo, y recibirá toneladas de correos electrónicos sobre errores que no le interesan.

¿Cuáles son las principales ventajas de una lista de correo sobre un rastreador de errores basado en la web? ¿Por qué algunos grandes proyectos solo usan una lista de correo?

— nada101
fuente

2

Sí, no, estoy de acuerdo contigo, Git usa listas de correo :) Lo que estaba diciendo es que lo estás agrupando con "algunos proyectos realmente grandes" y estaba pensando que si lo haces deberías dar un poco más ejemplos para esos proyectos realmente grandes. De lo contrario, la pregunta se reduce a "Git usa la lista de correo, ¿por qué es eso?" en cuyo caso la respuesta de Jörg W Mittag es más adecuada ...

— Shivan Dragon

1

Bueno, tenía la impresión de que había más ... Debian usa un sistema basado en correo , aunque más complejo que una lista de correo. Ok, pero el punto principal es '¿cuáles son las ventajas de usar una lista de correo sobre un rastreador de errores?' A menos que la respuesta sea "no hay ninguno, los desarrolladores de git son simplemente luditas".

— naught101

@ naught101: ¿por qué te sorprendes cuando ves eso? Debian inestable se puede instalar y usar sin ver ningún exploit raíz remoto que necesite parches y sin necesidad de reiniciar fácilmente durante seis meses. Eso es para la versión inestable de Debian. Tengo servidores Debian bloqueados que alcanzaron 4 días de tiempo de actividad (ni un solo exploit raíz remoto que requiera un reinicio que afecte mi configuración durante ese período). Es posible que estos tipos no estén usando la última moda tecnológica, pero obviamente están haciendo las cosas bien. Dejaría los rastreadores de errores web para la estabilidad de Debian en cualquier momento.

— Cedric Martin

2

@CedricMartin: Lo sé, estoy de acuerdo. El seguimiento de errores de la lista de correo claramente funciona adecuadamente para algunos equipos, pero todavía me parece menos fácil que un rastreador de errores. Sin embargo, he estado pensando que para los desarrolladores principales del proyecto, la diferencia puede parecer muy pequeña: de todos modos, siguen casi todo lo que sucede. Pero para los recién llegados, una lista de correo es casi imposible de asimilar, por lo que no se puede tener una visión general simple de la idoneidad del proyecto. Un rastreador de errores permite a los nuevos usuarios / desarrolladores descubrir rápidamente cómo se está moviendo un proyecto y tener una idea de qué tipo de mejoras son consideradas importantes por el equipo central.

— naught101

Greg Kroah-Hartman tiene una opinión sobre esto en relación con el kernel de Linux como parte de esta discusión . En particular: " NO hay forma de que el modelo github / gerrit / gitorious funcione en absoluto para el núcleo. La escala en la que trabajamos es un nivel totalmente diferente del que podrían manejar esas herramientas ... Realmente no hay otro forma conocida de manejar 10000 parches cada 2 meses, en una versión estable, con revisión por pares, con más de 3000 desarrolladores, aparte de lo que hacemos hoy ".

— naught101

45

La preferencia que observa parece una consecuencia natural de la recomendación claramente establecida en los Estándares de codificación GNU . Sugiere informar los errores por correo electrónico, como puede ver en la cita a continuación (marqué en negrita la parte que aborda directamente sus observaciones):

4.7.2 --help

La --helpopción estándar debería generar una breve documentación sobre cómo invocar el programa, en la salida estándar y luego salir con éxito. Una vez que se ve esto, se deben ignorar otras opciones y argumentos, y el programa no debe realizar su función normal.

Cerca del final de la ‘--help’salida de la opción, coloque líneas que indiquen la dirección de correo electrónico para los informes de errores , la página de inicio del paquete (normalmente ‘http://www.gnu.org/software/pkg’, y la página general para obtener ayuda con los programas GNU. El formato debería ser el siguiente:
    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 --helpsupone que cualquier usuario que lea un mensaje como el sugerido anteriormente debe comprender fácilmente qué hacer si ve un error: el envío de correos es fácil.

El rastreador de problemas podría ser (y creo que es ) mejor para un desarrollador que trabaje en el proyecto, pero para un público más amplio sería más difícil presentar y explicar cómo usarlo, especialmente teniendo en cuenta la gran variedad y las diferencias entre los diferentes sistemas de seguimiento de problemas. .

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

Report bugs to: mailing-address

La nota anterior no significa que los proyectos no deberían 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 problema de teléfono o correo electrónico e ingresarlo usted mismo, ¿cómo cree que se sienten?

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

— mosquito
fuente

3

¡Gran respuesta! El correo electrónico es más conocido que los rastreadores de problemas y es más fácil de entender (lo que no quiere decir que todos "reciban" el correo electrónico: P)

— Andres F.

21

Además, ese consejo de GNU es antiguo, mucho más antiguo que la web y los rastreadores de problemas basados en la web.

— Ross Patterson

@RossPatterson Estaba pensando eso. Pero parece poco probable que sea más antiguo que la web, teniendo en cuenta que contiene un montón de URL ...

— nada101

66

@gnat: Una parte importante de que la respuesta vinculada sea tan genial es la parte "si es fácil para ti, puedes ingresar ese tipo de cosas allí mismo" . Esa es la clave para muchos proyectos de código abierto, ya que no hay fondos para la asistencia telefónica. Una lista de correo es una desactivación para mí como usuario de informe de errores, ya que no quiero tener que registrarme para recibir respuestas. Con un rastreador de errores, puedo ver que el problema que tengo está en el sistema, y puedo volver y buscarlo más tarde, y ver si se ha actualizado. Esto es difícil con una lista de correo, a menos que haya un buen rastreador de listas basado en la web, que a menudo no es el caso.

— naught101

1

@ naught101 Puede que no sea más antiguo que la Web, pero definitivamente es más antiguo que los rastreadores basados en la Web

— sakisk

30

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

Como consecuencia, la comunidad Linux ha desarrollado herramientas y flujos de trabajo extremadamente eficientes para lidiar con informes de errores y revisiones de código por correo electrónico, y no había razón para que desecharan todo ese trabajo y comenzaran desde cero cuando comenzaron el proyecto Git.

— Jörg W Mittag
fuente

3

Pensé que la WWW precedió a Linux. Ligeramente. Ambas fueron hechas casi al mismo tiempo y por diferentes grupos de personas; No fue realmente hasta mediados de los 90 que despegaron.

— Donal Fellows

66

Ok, pero el kernel de Linux ahora tiene un rastreador de errores: bugzilla.kernel.org . Claramente, esa no es una barrera tan grande.

— naught101

77

-1 Git es realmente más joven que la web. Vintage 2005. Hubo muchos rastreadores de problemas en ese momento, incluido, por supuesto, Bugzilla. A Linus simplemente no le gustan los rastreadores de problemas, y su palabra es ley en ese entorno.

— Ross Patterson el

66

@RossPatterson - Dijo que Linux era más antiguo que la web, no Git. No creo que su comentario justifique un voto negativo, ya que básicamente repitió lo que dijo.

— beatgammit

2

@tjameson En retrospectiva, tienes razón. De vuelta a neutral.

— Ross Patterson el

17

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 han fracasado, por lo que la razón por la que Git no usa un rastreador de errores es probablemente porque la mayoría de los contribuyentes no lo encuentran útil.

En una publicación en la lista de correo , Junio C Hamano (mantenedor de Git) resumió por qué siente que un rastreador de errores no es muy útil. No quiero incluir toda la publicación (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 solucionarlo, la lista también funciona bien.
Si nadie está interesado en trabajar en un problema, se caerá por las grietas, incluso en un rastreador de errores.
Un rastreador de errores sería un sistema más que necesita ser mantenido, revisado para detectar nuevos errores regularmente, tener errores corregidos cerrados, etc., en resumen, trabajo adicional para poco beneficio.

— sleske
fuente

55

Buena respuesta, pero diría que su tercer punto es una gran desventaja del correo electrónico: si un error es difícil de solucionar y los desarrolladores actuales son vagos, se queda mucho más enterrado que una entrada en un rastreador de problemas. Esto podría significar que ciertos errores nunca se corrigen, simplemente porque la gente no sabe que están allí

— TheLQ

1

@TheLQ: Cierto. Sin embargo, aparentemente eso es un riesgo que algunos proyectos están dispuestos a asumir. Y para ser justos, git es un software bastante sólido, incluso sin un rastreador de errores.

— sleske

1

@TheLQ: ¿No resolvería eso una simple página web que mencione todos los errores conocidos (y sus hilos relacionados)? Algo similar a esto, excepto que los enlaces apuntan a hilos de archivo.

— Hola Mundo

1

@HelloWorld: Bueno, ese sería un rastreador de problemas (simple). Y al igual que un rastreador de problemas, alguien tendría que gestionarlo ...

— sleske

Sin embargo, ¿hay una buena manera de obtener una copia sin conexión del correo electrónico que se envió mientras no estaba suscrito?

— PSkocik

6

Debian usa un rastreador de errores, su interfaz predeterminada es el correo electrónico. Y es conveniente. Lucas Nussbaum, actual líder del proyecto Debian, publicó 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 que a menudo se lo percibe como antiguo, presenta varias características únicas, como el 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 fuera de línea o en entornos mal conectados.

La última parte es una característica asesina aquí: ¡solo ponga en cola esos informes en su cola de correo local hasta que salga del avión!

— Dominik George
fuente

4

Mantiene fuera a los niños de 9 años.
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. puede conectarse a Internet y descargar un lote de correos, luego ir de excursión, escribir sus respuestas mientras disfruta de la madre naturaleza y enviarlas más tarde.
Permite el cifrado y / o firma de correo a través de GPG.
Descentralizado: si el foro se bloquea, todavía tendría una copia, también es resistente a la manipulación, un moderador / hacker malvado no puede manipular fácilmente lo que ha 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 recibir 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 / injections, etc.)
Sin hinchazón: sin distintivos, firmas elegantes, anuncios, balizas web, hinchazón de JavaScript. Todo es simple y al grano: 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 son divisibles 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 foros web, esto es automático.

— Hola Mundo
fuente

¿por qué la gente insiste en la creación de versiones basadas en web para realizar un seguimiento de los temas (por cierto, esta pregunta no es sobre todo ) se discute en otra pregunta: ¿ Cómo obtener los usuarios a escribir informes de errores dignos y útiles "informes de errores en línea el usuario puede editar son la forma más eficiente para enseñar los usuarios mejoran ... "

— mosquito

Gracias. ¿Pero esto justifica un voto negativo? El tema principal de esta respuesta son las ventajas de un ML, y responde bastante bien a la pregunta original. He eliminado la queja de "foros web".

— Hola Mundo

2

La desventaja mencionada en esta respuesta en realidad me impide fundamentalmente seguir con la mayoría de las listas de correo de desarrollo. Envían todo , así que después de informar un error, generalmente me doy de baja solo dos semanas después. Los rastreadores de errores resuelven muy bien este problema permitiéndome suscribirme a informes de errores específicos.

— Roman Starkov

66

Corrección: mantiene fuera a los 25 años. Hace poco aprendí cómo funcionan las cosas de las listas de correo para contribuir a algunos proyectos reales . ¡¡Y lo odio!!

— Ciro Santilli 新疆改造中心法轮功六四事件

2

"No es necesario crear una cuenta separada para cada foro". - a menudo para evitar el spam, debe registrarse en la lista. Pero eso se suscribe a todos los correos electrónicos. Por lo tanto, debe suscribirse Y optar por 'spam' Y agregar una solicitud para mantenerse en CC o TO. En comparación con un bugzilla, es mucho más que hacer.

— Maciej Piechotka