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 "ml-linux-bugs@dg-rtp.dg.com" 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: