¿Cómo hizo el proyecto Linux Kernel para rastrear errores en los primeros días?

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 entablar sobre el tema fue esta en la que Linus compartió preocupaciones sobre el uso de Bugzilla .

Especulación: - La forma más fácil para las personas de rastrear errores en la fase inicial habría sido colocar los boletos en una rama propia, pero estoy seguro de que eso no habría escalado rápidamente con el ruido que se apodera de los errores buenos.

He visto y usado Bugzilla y, a menos que conozcas las "palabras clave" correctas, a veces estarías perplejo. NOTA: Estoy específicamente interesado en los primeros años (1991-1995) sobre cómo solían rastrear los problemas.

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

Busqué y no pude obtener ningún software de seguimiento de errores de FOSS que estaba 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 mantenedores 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 cometieron preguntas y debates sobre el error manualmente (sería costoso y doloroso hacerlo) o simplemente usaron el correo electrónico.
3. Mucho más tarde, apareció Bugzilla (primer lanzamiento en 1998) y esa parece ser la forma principal de informar errores después .

Espero tener una idea más clara de cómo se hicieron las cosas en los días anteriores.

Al principio, si tenía algo que aportar (un parche o un informe de error), se lo enviaba por correo a Linus. Esto evolucionó a enviarlo por correo a la lista (que [email protected]antes kernel.orgse creó).

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

Hubo otros sistemas de control de versiones propietarios anteriores a Bitkeeper, pero el desarrollo descentralizado y voluntario de Linux hizo que fuera imposible usarlos. Una persona aleatoria que acaba de encontrar un error nunca enviará un parche si tiene que pasar por un sistema de control de versiones patentado 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 núcleo podían usarlo sin pagar. Eso lo hizo lo suficientemente bueno por un tiempo.

Incluso con el desarrollo actual basado en git, las listas de correo siguen donde está la acción. Cuando desee contribuir con algo, lo preparará con git, por supuesto, pero tendrá que discutirlo en la lista de correo relevante antes de fusionarlo. 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 informe de errores, obtenga el repositorio histórico de Linux . (Este es un repositorio de git que contiene todas las versiones de antes de que existiera git; principalmente contiene un commit por lanzamiento ya que fue reconstruido a partir de los tarballs). Archivos de interés como README, MAINTAINERS, y REPORTING-BUGS.

Una de las cosas interesantes que puede encontrar allí es esto desde el archivo README de Linux-0.99.12:

 - if you have problems that seem to be due to kernel bugs, please mail
   them to me ([email protected]), 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.

Los procesos utilizaron grupos de noticias (USENET) y (predominantemente) correo electrónico. Un error "existía" como un hilo, poner " [BUG REPORT]" o " LINUX BUG REPORT" en el tema era una convención común. No hubo ID de error. Dada la base de usuarios típica, un informe de error a menudo viene con un parche. Se usó una herramienta de software olvidada hace mucho tiempo: ibug(ver más abajo), aparte de eso diff+ patch.

Desde la instalación y el inicio de Linux (enero de 1994, copia archivada v2.0) >

2.6  The Design and Philosophy of Linux

 When new users encounter Linux, they often have a few misconceptions and
 false expectations of the system. Linux is a  unique  operating  system,
 and  it is important to understand its philosophy and design in order to
 use it effectively.  Time enough for a soapbox. Even if you are an  aged
 UNIX guru, what follows is probably of interest to you.

     In  commercial UNIX development houses, the entire system is devel-
 oped with a rigorous policy of quality assurance,  source  and  revision
 control systems, documentation, and bug reporting and resolution. [...]

     With  Linux,  you  can  throw  out  the entire concept of organized
 development, source control systems, structured bug reporting,  or  sta-
 tistical  analysis.   Linux  is,  and more than likely always will be, a
 hacker's operating system.(4)

                   [...]  For the most part, the Linux community communi-
 cates via various mailing lists and USENET newsgroups. A number of  con-
 ventions have sprung up around the development effort: for example, any-
 one wishing to have their  code  included  in  the  ``official''  kernel
 should  mail it to Linus Torvalds, which he will test and include in the
 kernel [...]

1992

Aquí hay un informe de error y corrección de diciembre de 1992 (0.98.6) en comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Muy temprano había una lista de correo electrónico ml-linux-bugs (1992/1993), de estas preguntas frecuentes iniciales en la distribución Slackware 1.01:

VI.01) Parece que $ # @! portado en Linux no se ejecuta correctamente, ¿qué debo hacer para informar de errores?

[...] Tenga en cuenta que mi lista de informes de errores "[email protected]" se ha eliminado. Resulta que Linux tiene muy pocos errores, la mayoría de los cuales se resuelven en el grupo de noticias o a través de Linus antes de que pueda acumularlos y publicarlos. En resumen: si hay un error en Linux o en un software portado por Linux, generalmente se solucionará en el siguiente parche o versión.

Estaba la lista de correo electrónico "linux-kernel" (que se ejecutaba en el original vger), grupos de noticias alt.os.linux, luego comp.os.linux (que rápidamente se dividió en una jerarquía en 1993 ).

Estas primeras preguntas frecuentes sobre Linux (v1.11 de noviembre de 1992) de comp.os.linux también sugieren enviar un correo electrónico a Linus directamente.

En 1992, Matt Welsh ( Running Linux , Linux Bible , TLDP ) anuncióibug que ayudaría a generar informes de errores por correo electrónico (irónicamente, no podía ejecutar esto en Linux en ese momento ya que carecía de una red suficiente para poder enviar un correo electrónico).

También se publicaba periódicamente una plantilla de informe de errores delinux.temp correo electrónico en comp.os.linux, y las actualizaciones de un informe de errores tenían una plantilla de actualizaciónlinux.fix.temp .

También había un repositorio de parches (FTP) , por lo que puedo decir, esto era principalmente (no exclusivamente) para parches a programas para portar a Linux.

1993-1994

Las copias CVS de la fuente del núcleo eran comunes, lo primero que puedo encontrar es la de Dirk Steinberg, de la era kernal-0.99.14. El primer anuncio que puedo encontrar es de enero de 1993 sobre linux-activistas. Todavía puede encontrar copias archivadas (1994) . Dirk también mantuvo binarios cvs y fuente libc en CVS.

CVS no se usó para rastrear errores en el sentido contemporáneo, algunos desarrolladores prefirieron usarlo, y los parches se enviaban con frecuencia en forma de diferencias generadas por cvs.

1995-1996

Alrededor de este tiempo (octubre de 1995) David S. Miller comenzó a usar CVS para el puerto SPARC del kernel de Linux ( el puerto Linux / SPARC ). En febrero de 1996, otros desarrolladores de kernel usaban CVS de forma independiente para realizar un seguimiento de los parches, desde Linux-Kernel este hilo y este hilo : Alan Cox, Stephen Tweedie, Kai Henningsen. (El segundo hilo informa que Russ Nelson afirma la aversión de Linus a CVS).

1997-1998

En abril de 1998, poco después del nacimiento del segundo hijo de Linus, volvió a surgir el problema de CVS, desde linux-kernel vea este subproceso (Linus reitera sus preocupaciones sobre CVS allí directamente).

En diciembre de 1997, Andrew Tridgell lanzó jitterbug , un rastreador de errores basado en la web. En junio de 1998, Alan Cox defendía los "parches de linux" JitterBug en linux-kernel . Hasta donde puedo decir, el primer sistema de seguimiento de errores real utilizado por Linus y otros desarrolladores clave, lamentablemente, la instancia de "parches de linux" ya no está en línea.

En septiembre de 1998, Larry McEvoy promovió Bitkeeper por primera vez en Linux-kernel .

1999 y más tarde

En 1999/2000, las preguntas frecuentes de lkml comenzaron a referirse (P 1-16) al árbol CVS en el vger (el original). Andrew Tridgell lo mantuvo en ese momento.

Para diciembre de 2001, Jitterbug había caído en desgracia, vea este hilo del kernel de Linux , Linus, Alan Cox y muchos otros se involucran en discutir por qué.

En enero de 2002, Linus comenzó a interesarse en Bitkeeper (ya utilizado por el equipo del núcleo PowerPC Linux).

En febrero de 2002, Linus comenzó a usar Bitkeeper para el árbol de desarrollo 2.5.

En noviembre de 2002 se anunció el OSDL Linux Bugzilla alojado para el árbol 2.5 . (Si aún no has leído el enlace de bugzilla en la pregunta, ve y léelo ahora, contiene diatribas linus antiguas).

En abril de 2005, Linus anunció un alejamiento de BitKeeper , alrededor del tiempo que mencionó gitpor primera vez por su nombre . Poco después de que git fuera capaz de autohospedarse , Linus dejó de usar BitKeeper y comenzó a usar git para el núcleo.

En diciembre de 2008 se anunció el rastreador de parches Patchwork para linux-kernel , un rastreador de parches basado en web independiente de SCCS que se integra con listas de correo para rastrear parches y seguimientos. Su uso continúa hasta nuestros días, hay aproximadamente 40 listas rastreadas de esta manera en https://patchwork.kernel.org/ , aunque no todas están activas.

Referencias

Referencias útiles:

• Esencia del trabajo distribuido: el caso del kernel de Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (Nov 2000)
• Pautas para informar errores de Linux (julio de 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Archivo de Kenneth R. Saborio de publicaciones / correos electrónicos importantes de Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• archivos de Linux-kernel desde hoy (noviembre de 2014) hasta 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (lamentablemente, el primer correo electrónico es de junio de 1995 donde el administrador Chris Dent anuncia que ha perdido el anterior archivos ...) El archivo LKML solo se remonta a 1996
• Fragmentos de linux-devel 1993-1994 de tsx11 http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/linux- devel / (ignore las fechas en la URL y en los archivos)
• Herramientas de gestión de versiones: CVS a BK en el kernel de Linux , Sjaikh y Cornford (ca. 2003)
• Vea también este hilo de Hacker News (marzo de 2015) a medida que se acerca el décimo aniversario de git: https://news.ycombinator.com/item?id=9263336

Puedo decir cómo se manejan los informes de errores para el desarrollo de gitsí mismo.

No utilizan ningún software de seguimiento de errores. Los errores son reportados y discutidos en la lista de correo de desarrollo . Posiblemente sea sorprendente, pero funciona muy bien.

La pregunta o propuesta para usar algún software de seguimiento de errores surge a menudo, por lo que puede aprender mucho sobre esto al buscar en los archivos de las listas de correo de git.

No se trata de "todavía no encontramos un rastreador de errores que sea lo suficientemente bueno";
Pero tampoco se trata de "tenemos un método superior".

Con este método, el mantenedor del proyecto o subproyecto, algo así como un desarrollador principal, tiene un papel importante como moderador informal de la lista de desarrollo.
Manejar errores es parte de esto, y no parece ser una tarea trivial manejarlos de esta manera; Ciertamente depende de las habilidades de las personas en ese rol.

La parte más formal del método es un mensaje de resumen de estado semanal.
Enumera las cosas que están sucediendo actualmente en las distintas ramas como elementos cortos. Para ver un ejemplo del desarrollo de git, vea esto en el grupo de noticias que gmane.comp.version-control.gitrefleja la lista de correo: What's cooking in git.git

Lo que puedo decir con seguridad: si tiene un mantenedor que es bueno en esto, funciona extremadamente bien.
Por ejemplo, me sorprendería mucho si la introducción de un rastreador de errores tuviera un efecto positivo en la productividad de las características y la calidad implementadas, incluso a largo plazo después de la amortización de los gastos generales del cambio.

Para el kernel de Linux, es similar a cómo se hace para git, hasta hoy.
Las listas de correo de desarrollo para el desarrollo del kernel de Linux son ciertamente importantes. Pero no es una lista como un lugar central como con git. Hay listas separadas para subtemas, como sistemas de archivos o redes.
Debido a que hay temas separados, manejados por desarrolladores en su mayoría separados, es posible que algunos grupos usen herramientas locales para su grupo.