¿Cómo rastreaba el proyecto del Kernel de Linux los errores en los primeros días?

Pregunta:

Todos sabemos que Linus Torvalds creó Git debido a problemas con Bitkeeper. Lo que no se sabe (al menos para mí) es, ¿cómo se rastrearon los problemas / tickets / errores hasta entonces? Lo intenté pero no obtuve nada interesante. La única discusión que pude tener sobre el tema fue esta en la que Linus compartió sus preocupaciones sobre el uso de Bugzilla .

Especulación: – La forma más fácil para que las personas rastrearan los errores en la fase inicial habría sido colocar los tickets en una rama propia, pero estoy seguro de que con bastante rapidez eso no habría escalado con el ruido que superó a los errores buenos.

He visto y usado Bugzilla y, a menos que conozca las 'palabras clave' correctas, a veces se quedará perplejo. NOTA: Estoy específicamente interesado en los primeros años (1991-1995) en cuanto a cómo solían rastrear problemas.

Miré dos hilos, " Kernel SCM saga " y " Trivia: ¿Cuándo git self-host? ", Pero ninguno de ellos mencionó el seguimiento de errores del kernel en los primeros días.

Busqué y no pude encontrar ningún software de seguimiento de errores de FOSS que estuviera allí en 1991-1992. Bugzilla, Request-tracker y otros llegaron mucho más tarde, por lo que parecen estar fuera.

Preguntas clave

  1. ¿Cómo entonces Linus, los encargados del mantenimiento del subsistema y los usuarios informaron y rastrearon errores en esos días?
  2. ¿Usaron algún software de seguimiento de errores, crearon una rama de errores y enviaron manualmente preguntas y discusiones sobre el error (sería costoso y doloroso hacer eso) o simplemente usaron el correo electrónico?
  3. Mucho más tarde, apareció Bugzilla (primera versión 1998) y esa parece ser la forma principal de informar errores posteriormente .

Espero tener una idea más clara de cómo se hacían las cosas en los viejos tiempos.

Respuesta:

Al principio, si tenía algo que aportar (un parche o un informe de error), se lo enviaba por correo a Linus. Esto evolucionó para linux-kernel@vger.rutgers.edu por correo a la lista (que era linux-kernel@vger.rutgers.edu antes de que se linux-kernel@vger.rutgers.edu kernel.org ).

No hubo control de versiones. De vez en cuando, Linus colocaba un tarball en el servidor FTP. Este era el equivalente a una "etiqueta". Las herramientas disponibles al principio eran RCS y CVS, y Linus las odia, así que todo el mundo envió parches por correo. (Hay una explicación de Linus sobre por qué no quería usar CVS).

Había otros sistemas de control de versiones propietarios anteriores a Bitkeeper, pero el desarrollo descentralizado y voluntario de Linux hizo imposible su uso. Una persona al azar que acaba de encontrar un error nunca enviará un parche si tiene que pasar por un sistema de control de versiones propietario con licencias que comienzan en miles de dólares.

Bitkeeper solucionó ambos problemas: no estaba centralizado como CVS, y aunque no era software libre, los contribuyentes del kernel podían usarlo sin pagar. Eso lo hizo suficientemente bueno por un tiempo.

Incluso con el desarrollo actual basado en git, las listas de correo todavía están donde está la acción. Cuando quieras contribuir con algo, lo prepararás con git, por supuesto, pero tendrás que discutirlo en la lista de correo relevante antes de que se fusione. Bugzilla está ahí para parecer "profesional" y absorber informes de errores a medias de personas que realmente no quieren involucrarse.

Para ver algunas de las antiguas instrucciones de informes de errores, obtenga el repositorio histórico de Linux . (Este es un repositorio de git que contiene todas las versiones anteriores a la existencia de git; en su mayoría, contiene una confirmación por lanzamiento, ya que fue reconstruido a partir de los archivos tar). Los archivos de interés incluyen README , MAINTAINERS y REPORTING-BUGS .

Una de las cosas interesantes que puede encontrar es esto del LÉAME de Linux-0.99.12:

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me (Linus.Torvalds@Helsinki.FI), and possibly to any other
   relevant mailing-list or to the newsgroup.  The mailing-lists are
   useful especially for SCSI and NETworking problems, as I can't test
   either of those personally anyway.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top

web tasarım