Al principio, si tenía algo que aportar (un parche o un informe de error), se lo enviaba por correo a Linus. Esto evolucionó hasta enviarlo por correo a la lista (que era [email protected] antes de kernel.org fue creado).
No había control de versiones. De vez en cuando, Linus ponía 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, así que todo el mundo enviaba 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 de Linux descentralizado y basado en voluntarios 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 patentado con licencias a partir de miles de dólares.
Bitkeeper resolvió 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 lo suficientemente bueno por un tiempo.
Incluso con el desarrollo actual basado en git, las listas de correo siguen estando 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 que se fusione. Bugzilla está ahí para parecer "profesional" y absorber informes de errores a medias de personas que no realmente quiere participar.
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 versión, ya que se reconstruyó a partir de los tarballs). Los archivos de interés incluyen README , MAINTAINERS y REPORTING-BUGS .
Una de las cosas interesantes que puede encontrar allí 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 ([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, poniendo "[BUG REPORT] " o "LINUX BUG REPORT " en el tema había una convención común. No había identificadores de errores. Dada la base de usuarios típica, un informe de errores a menudo venía con un parche. Se utilizó una herramienta de software olvidada hace mucho tiempo:ibug (ver más abajo), aparte de eso diff +patch .
Desde Instalación y primeros pasos 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 errores y una solución de diciembre de 1992 (0.98.6) en comp.os.linux:https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion
Muy pronto había una lista de correo electrónico ml-linux-bugs (1992/1993), de estas primeras preguntas frecuentes sobre 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 oa través de Linus antes de que pueda acumularlos y publicarlos. :) En resumen:si hay un error en Linux o en el software adaptado a Linux, generalmente se solucionará en el siguiente nivel de parche o versión.
Estaba la lista de correo electrónico "linux-kernel" (que se ejecutaba en el vger original ), 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 (ejecutando Linux , La Biblia de Linux , TLDP) anunció ibug para ayudar a generar informes de errores enviados por correo electrónico (irónicamente, no podía ejecutar esto en Linux en ese momento ya que carecía de suficiente red para poder enviar un correo electrónico).
Una plantilla de informe de errores por correo electrónico linux.temp también se publicaba periódicamente en comp.os.linux, y las actualizaciones de un informe de error tenían una plantilla de actualización linux.fix.temp .
También había un repositorio de parches (FTP), por lo que puedo decir, esto era principalmente (no exclusivamente) para parches para programas para portar a Linux.
1993-1994
Las copias CVS de la fuente del kernel eran comunes, la más antigua 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 activistas de Linux. Todavía se pueden encontrar copias archivadas (1994). Dirk también mantuvo los binarios cvs y la fuente libc en CVS.
CVS no se usaba para rastrear errores en el sentido actual, algunos desarrolladores preferían 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, varios otros desarrolladores del núcleo estaban usando 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 declara de primera mano la aversión de Linus a CVS).
1997-1998
En abril de 1998, poco después del nacimiento del segundo hijo de Linus, el tema de CVS volvió a surgir, desde linux-kernel, consulte este hilo secundario (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 el kernel de linux. Hasta donde puedo decir, este fue 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 promociona bitkeeper por primera vez en Linux-kernel.
1999 y posteriores
Para 1999/2000, las preguntas frecuentes de lkml comenzaron a hacer referencia (P 1-16) al árbol CVS en (el original) vger. Esto fue sostenido en ese momento por Andrew Tridgell.
Para diciembre de 2001, Jitterbug había caído en desgracia, mira este hilo del kernel de Linux, Linus, Alan Cox y muchos otros se involucran en discutir por qué.
En enero de 2002, Linus empezó a interesarse por bitkeeper (ya utilizado por el equipo del kernel de Linux de PowerPC).
En febrero de 2002, Linus comenzó a usar Bitkeeper para el árbol de desarrollo 2.5.
En noviembre de 2002, se anunció el Linux Bugzilla alojado en OSDL para el árbol 2.5. (Si aún no ha leído el enlace de bugzilla en la pregunta, vaya y léalo ahora, contiene diatribas antiguas de Linus).
En abril de 2005, Linus anunció que se alejaría de BitKeeper, más o menos cuando mencionó por primera vez git. por nombre. Poco después de que git se volviera capaz de hospedarse por sí mismo, Linus dejó de usar BitKeeper y comenzó a usar git para el kernel.
En diciembre de 2008, se anunció el rastreador de parches Patchwork para Linux-kernel, este es un rastreador de parches basado en la web independiente de SCCS que se integra con las listas de correo para rastrear parches y seguimientos. Su uso continúa hasta el día de hoy, hay aproximadamente 40 listas rastreadas de esta manera en https://patchwork.kernel.org/, aunque no todas están activas.
Referencias
Referencias útiles:
- La 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 (noviembre de 2000)
- Directrices para informar errores de Linux (julio de 1992)http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
- Archivo de publicaciones/correos electrónicos importantes de Linux de Kenneth R. Saborio:http://www.informatica.co.cr/linux/index.htm (1991-2005)
- archivos del kernel de Linux desde hoy (noviembre de 2014) hasta 1995http://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 los archivos anteriores...) El archivo LKML solo se remonta a 1996
- Fragmentos de linux-devel 1993-1994 de tsx11http://www.ibiblio.org/pub/historic-linux/ftp-archives/tsx-11.mit.edu/Oct-07-1996/mail-archive/ linux-devel/(ignorar las fechas en la URL y en los archivos)
- Herramientas de administración de versiones:CVS a BK en el kernel de Linux , Sjaikh y Cornford (aprox. 2003)
- Vea también estas noticias de hackers subproceso (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 git mismo.
No utilizan ningún software de seguimiento de errores. Los errores se informan y discuten en la lista de correo de desarrollo. Es posiblemente 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 listas de correo de git.
No se trata de "aún 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.
El manejo de errores es parte de esto, y no parece ser una tarea trivial manejar errores 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 suceden actualmente en las diversas ramas como artículos breves. Para ver un ejemplo del desarrollo de git, vea esto en el grupo de noticias gmane.comp.version-control.git reflejando la lista de correo:¿Qué se está cocinando en git.git?
Lo que puedo decir con seguridad:si tienes un mantenedor que es bueno en esto, funciona extremadamente bien.
Por ejemplo, yo sería muy me sorprende si la introducción de un rastreador de errores tuvo un efecto positivo en la productividad de las funciones 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 el día de 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 en su mayoría por desarrolladores independientes, es posible que algunos grupos usen herramientas localmente para su grupo.