Comment le projet Linux Kernel a-t-il suivi les bogues dans les premiers jours?

Nous savons tous que Linus Torvalds a créé Git en raison de problèmes avec Bitkeeper. Ce que je ne sais pas (du moins pour moi), c'est comment les problèmes / tickets / bugs ont-ils été suivis jusque-là? J'ai essayé mais je n'ai rien obtenu d'intéressant. La seule discussion que j'ai pu avoir sur le sujet était celle-ci où Linus partageait ses inquiétudes concernant l'utilisation de Bugzilla .

Spéculation: - Le moyen le plus simple pour les gens de suivre les bogues dans la phase initiale aurait été de placer les tickets dans une branche à part, mais je suis sûr que cela n'aurait pas évolué assez rapidement avec le bruit qui aurait pris le dessus sur les bons bogues.

J'ai vu et utilisé Bugzilla et à moins que vous ne connaissiez parfois les bons «mots clés», vous seriez perplexe. REMARQUE: je suis particulièrement intéressé par les premières années (1991-1995) quant à la façon dont ils ont utilisé pour suivre les problèmes.

J'ai regardé deux threads, " Kernel SCM saga ", et " Trivia: When did git self-host? " Mais aucun de ceux-ci n'a fait mention du suivi des bogues du noyau dans les premiers jours.

J'ai cherché autour de moi et je n'ai pu obtenir aucun logiciel de suivi des bogues FOSS qui était là en 1991-1992. Bugzilla, Request-tracker et d'autres sont venus beaucoup plus tard, ils semblent donc être sortis.

Questions clés

1. Comment Linus, les responsables du sous-système et les utilisateurs ont-ils alors signalé et suivi les bogues à cette époque?
2. Ont-ils utilisé un logiciel de suivi des bogues, créé une branche de bogues et engagé manuellement des questions et des discussions sur le bogue (ce serait coûteux et douloureux pour le faire) ou simplement utiliser le courrier électronique.
3. Beaucoup plus tard, Bugzilla est arrivé (première version 1998) et cela semble être le principal moyen de signaler les bugs par la suite .

Au plaisir d'avoir une idée plus claire de la façon dont les choses se faisaient dans le passé.

Au début, si vous aviez quelque chose à apporter (un patch ou un rapport de bogue), vous l'avez envoyé par la poste à Linus. Cela a évolué en l'envoyant à la liste (qui était linux-kernel@vger.rutgers.eduavant la kernel.orgcréation).

Il n'y avait aucun contrôle de version. De temps en temps, Linus met une archive tar sur le serveur FTP. C'était l'équivalent d'un "tag". Les outils disponibles au début étaient RCS et CVS, et Linus les déteste, donc tout le monde vient d'envoyer des correctifs. ( Linus explique pourquoi il ne voulait pas utiliser CVS.)

Il y avait d'autres systèmes de contrôle de version propriétaires d'avant Bitkeeper, mais le développement décentralisé et volontaire de Linux a rendu impossible leur utilisation. Une personne au hasard qui vient de trouver un bug n'enverra jamais de patch s'il doit passer par un système de contrôle de version propriétaire avec des licences commençant à des milliers de dollars.

Bitkeeper a contourné ces deux problèmes: il n'était pas centralisé comme CVS, et bien qu'il ne s'agisse pas de logiciel libre, les contributeurs du noyau étaient autorisés à l'utiliser sans payer. Cela l'a rendu assez bon pendant un certain temps.

Même avec le développement basé sur git d'aujourd'hui, les listes de diffusion sont toujours là où l'action est. Lorsque vous voulez contribuer quelque chose, vous le préparerez avec git bien sûr, mais vous devrez en discuter sur la liste de diffusion appropriée avant qu'il ne soit fusionné. Bugzilla est là pour avoir l'air "professionnel" et absorber les rapports de bogue à moitié cuits de personnes qui ne veulent pas vraiment s'impliquer.

Pour voir certaines des anciennes instructions de rapport de bogues, récupérez l' historique du référentiel Linux . (Il s'agit d'un référentiel git contenant toutes les versions antérieures à git; il contient principalement un commit par version depuis qu'il a été reconstruit à partir des tarballs). Les fichiers d'intérêt comprennent README, MAINTAINERSet REPORTING-BUGS.

L'une des choses intéressantes que vous pouvez y trouver est celle-ci dans le README 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.

Les processus utilisaient des groupes de discussion (USENET) et (principalement) des e-mails. Un bug "existait" en tant que thread, mettant " [BUG REPORT]" ou " LINUX BUG REPORT" dans le sujet était une convention courante. Il n'y avait aucun ID de bogue. Étant donné la base d'utilisateurs typique, un rapport de bogue était souvent accompagné d'un correctif. Il y avait un outil logiciel oublié depuis longtemps: ibug(voir ci-dessous), à part ça diff+ patch.

Depuis l' installation et le démarrage de Linux (janvier 1994, copie archivée 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

Voici un rapport de bogue et un correctif de décembre 1992 (0.98.6) sur comp.os.linux: https://groups.google.com/d/topic/comp.os.linux/TwPA00rZMJo/discussion

Très tôt, il y avait une liste d'email ml-linux-bugs (1992/1993), à partir de cette première FAQ dans la distribution Slackware 1.01:

VI.01) Il semble que $ # @! porté sur linux ne fonctionne pas correctement, que dois-je faire pour signaler des bogues?

[...] Notez que ma liste de rapports de bogues "ml-linux-bugs@dg-rtp.dg.com" a été supprimée. Il s'avère que Linux a si peu de bogues, dont la plupart sont résolus dans le groupe de discussion ou via Linus avant de pouvoir les accumuler et les publier. :) En bref: s'il y a un bogue sous Linux ou dans un logiciel sous Linux, il sera généralement corrigé dans le prochain niveau de patch ou la prochaine version.

Il y avait la liste de vgerdiffusion "linux-kernel" (qui fonctionnait sur l'original ), les newsgroups alt.os.linux, puis comp.os.linux (qui se sont rapidement divisés en une hiérarchie en 1993 ).

Cette première FAQ Linux (v1.11 novembre 1992) de comp.os.linux suggère également d'envoyer directement un courrier électronique à Linus.

En 1992, Matt Welsh ( Running Linux , Linux Bible , TLDP ) a annoncéibug son aide pour générer des rapports de bogue par e-mail (ironiquement, vous ne pouviez pas l'exécuter sur Linux à ce moment-là, car il ne disposait pas d'un réseau suffisant pour pouvoir envoyer un e-mail).

Un modèle de rapport de bogue parlinux.temp courrier électronique a également été régulièrement publié sur comp.os.linux et les mises à jour d'un rapport de bogue comportaient un modèle de mise à jourlinux.fix.temp .

Il y avait aussi un référentiel de correctifs (FTP) , pour autant que je sache, c'était principalement (pas exclusivement) pour les correctifs vers des programmes pour le portage vers Linux.

1993-1994

Les copies CVS de la source du noyau étaient courantes, la plus ancienne que je puisse trouver est celle de Dirk Steinberg, datant de l'ère kernal-0.99.14. La première annonce que je peux trouver date de janvier 1993 sur linux-activists. Vous pouvez toujours trouver des copies archivées (1994) . Dirk a également maintenu les binaires cvs et la source libc dans CVS.

CVS n'était pas utilisé pour suivre les bogues au sens contemporain, certains développeurs préféraient l'utiliser, et les correctifs étaient fréquemment soumis sous la forme de différences générées par cvs.

1995-1996

Vers cette époque (octobre 1995), David S. Miller a commencé à utiliser CVS pour le port SPARC du noyau Linux ( le port Linux / SPARC ). En février 1996, plusieurs autres développeurs de noyau utilisaient indépendamment CVS pour garder une trace des correctifs, de linux-kernel ce fil et ce fil : Alan Cox, Stephen Tweedie, Kai Henningsen. (Le deuxième fil rapporte Russ Nelson déclarant l'aversion de Linus à CVS.)

1997-1998

En avril 1998, peu de temps après la naissance du deuxième enfant de Linus, le problème de CVS est revenu, de linux-kernel voir ce sous-fil (Linus réitère directement ses préoccupations concernant CVS).

En décembre 1997, Andrew Tridgell a publié jitterbug , un outil de suivi des bogues basé sur le Web. En juin 1998, le "linux-patches" JitterBug était préconisé sur linux-kernel par Alan Cox . Pour autant que je sache, c'était le premier véritable système de suivi des bogues utilisé par Linus et d'autres développeurs clés, malheureusement l'instance "linux-patches" n'est plus en ligne.

En septembre 1998, bitkeeper est promu pour la première fois sur linux-kernel par Larry McEvoy.

1999 et après

En 1999/2000, la FAQ lkml a commencé à se référer (Q 1-16) à l'arborescence CVS sur (l'original) vger. Cela a été maintenu à l'époque par Andrew Tridgell.

En décembre 2001, Jitterbug était tombé en disgrâce, voyez ce thread linux-kernel , Linus, Alan Cox et bien d'autres s'impliquent pour discuter de pourquoi.

En janvier 2002, Linus a commencé à s'intéresser au bitkeeper (déjà utilisé par l'équipe du noyau PowerPC Linux).

En février 2002, Linus a commencé à utiliser Bitkeeper pour l'arbre de développement 2.5.

En novembre 2002 pour 2,5 arbre le OSDL hébergé Linux Bugzilla a été annoncé . (Si vous n'avez pas encore lu le lien bugzilla dans la question, allez le lire maintenant, il contient des diatribes Linus vintage).

En avril 2005, Linus a annoncé son abandon de BitKeeper , à peu près au moment où il avait mentionné son gitnom pour la première fois . Peu de temps après que git soit devenu capable de s'auto-héberger , Linus a cessé d'utiliser BitKeeper et a commencé à utiliser git pour le noyau.

En décembre 2008, le patchwork patch tracker pour linux-kernel a été annoncé , il s'agit d'un patch tracker Web indépendant du SCCS qui s'intègre aux listes de diffusion pour suivre les patchs et les suivis. Son utilisation continue à ce jour, il existe environ 40 listes suivies de cette façon sur https://patchwork.kernel.org/ , bien que toutes ne soient pas actives.

Les références

Références utiles:

• Essence du travail distribué: le cas du noyau Linux (Jae Yun Moon, Lee Sproull) http://www.firstmonday.org/ojs/index.php/fm/article/view/801/710 (novembre 2000)
• Lignes directrices pour signaler les bogues Linux (juillet 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
• Archives de Kenneth R. Saborio d'importantes publications / e-mails Linux: http://www.informatica.co.cr/linux/index.htm (1991-2005)
• archives linux-kernel d'aujourd'hui (novembre 2014) à 1995 http://lkml.iu.edu/hypermail/linux/kernel/ (malheureusement, le premier e-mail date de juin 1995 où l'administrateur Chris Dent annonce qu'il a perdu la précédente archives ...) Les archives LKML ne remontent qu'à 1996
• Fragments 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 / (ignorer les dates dans l'URL et sur les fichiers)
• Outils de gestion de versions: CVS à BK dans le noyau Linux , Sjaikh et Cornford (ca.2003)
• Voir également ce fil de discussion Hacker News (mars 2015) à l'occasion du 10e anniversaire de git: https://news.ycombinator.com/item?id=9263336

Je peux dire comment le rapport de bogue est géré pour le développement de gitlui - même.

Ils n'utilisent aucun logiciel de suivi des bogues. Les bogues sont signalés et discutés sur la liste de diffusion de développement . C'est peut-être surprenant, mais cela fonctionne très bien.

La question ou la proposition d'utiliser un logiciel de suivi des bogues revient souvent, vous pouvez donc en apprendre beaucoup à ce sujet en recherchant dans les archives des listes de diffusion git.

Il ne s'agit pas de "nous n'avons pas encore trouvé de tracker de bogue qui soit assez bon";
Mais il ne s'agit pas non plus de "nous avons une méthode supérieure".

Avec cette méthode, le responsable du projet ou du sous-projet - quelque chose comme un développeur principal - a un rôle important en tant que modérateur informel de la liste de développement.
La gestion des bogues en fait partie, et il ne semble pas être une tâche triviale de gérer les bogues de cette façon; Cela dépend certainement des compétences des personnes dans ce rôle.

La partie la plus formelle de la méthode est un message récapitulatif d'état hebdomadaire.
Il répertorie les choses qui se passent actuellement dans les différentes branches sous forme d'éléments courts. Pour un exemple du développement de git, voyez ceci dans le newsgroup gmane.comp.version-control.gitreflétant la liste de diffusion: Qu'est-ce qui cuit dans git.git

Ce que je peux dire avec certitude: si vous avez un responsable qui est bon dans ce domaine, cela fonctionne extrêmement bien.
Par exemple, je serais très surpris si l'introduction d'un traqueur de bogues avait un effet positif sur la productivité des fonctionnalités implémentées et la qualité, même à long terme après amortissement des frais généraux de changement.

Pour le noyau Linux, c'est similaire à la façon dont il est fait pour git, jusqu'à aujourd'hui.
Les listes de diffusion de développement pour le développement du noyau Linux sont certainement importantes. Mais ce n'est pas une liste comme un endroit central comme avec git. Il existe des listes distinctes pour les sous-thèmes, comme les systèmes de fichiers ou les réseaux.
Étant donné qu'il existe des rubriques distinctes, gérées par des développeurs principalement distincts, il est possible que certains groupes utilisent des outils localement pour leur groupe.