Au début, si vous aviez quelque chose à apporter (un correctif ou un rapport de bogue), vous l'envoyiez par courrier à Linus. Cela a évolué en l'envoyant à la liste (qui était [email protected] avant kernel.org a été créé).
Il n'y avait pas de contrôle de version. De temps en temps, Linus mettait 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 s'est contenté d'envoyer des correctifs. (Il y a une explication de Linus sur la raison pour laquelle il ne voulait pas utiliser CVS.)
Il existait d'autres systèmes de contrôle de version propriétaires pré-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 bogue n'enverra jamais de correctif s'il doit passer par un système de contrôle de version propriétaire avec des licences à partir de milliers de dollars.
Bitkeeper a contourné ces deux problèmes :il n'était pas centralisé comme CVS, et même s'il ne s'agissait pas d'un logiciel libre, les contributeurs du noyau étaient autorisés à l'utiliser sans payer. Cela l'a rendu assez bon pour un moment.
Même avec le développement actuel basé sur git, les listes de diffusion sont toujours là où se trouve l'action. Lorsque vous souhaitez 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 s'imprégner des rapports de bogues à moitié cuits de personnes qui ne le savent pas vraiment voulez vous impliquer.
Pour voir certaines des anciennes instructions de rapport de bogue, obtenez le référentiel Linux historique. (Il s'agit d'un référentiel git contenant toutes les versions antérieures à git ; il contient principalement un commit par version puisqu'il a été reconstruit à partir des archives tar). Les fichiers d'intérêt incluent README , MAINTAINERS , et REPORTING-BUGS .
L'une des choses intéressantes que vous pouvez y trouver est celle-ci dans le fichier README 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.
Les processus utilisaient des groupes de discussion (USENET) et (principalement) le courrier électronique. Un bogue "existait" en tant que thread, mettant "[BUG REPORT] " ou "LINUX BUG REPORT " dans le sujet était une convention courante. Il n'y avait pas d'ID de bogue. Compte tenu de la base d'utilisateurs typique, un rapport de bogue était souvent accompagné d'un correctif. Un outil logiciel oublié depuis longtemps était utilisé :ibug (voir ci-dessous), à part ça diff +patch .
À partir de Linux Installation and Getting Started (janvier 1994, v2.0 copie archivée)>
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 de diffusion ml-linux-bugs (1992/1993), de cette première FAQ de la distribution Slackware 1.01 :
VI.01) Il semble que $#@ ! porté sur Linux ne fonctionne pas correctement, que dois-je faire pour signaler les bogues ?
[...] Notez que ma liste de rapports de bogues "[email protected]" a été supprimée. Il s'avère que Linux a si peu de bogues, dont la plupart sont résolus sur le groupe de discussion ou via Linus avant que je puisse les accumuler et les publier. :) En bref :s'il y a un bogue dans Linux ou dans un logiciel porté sur Linux, il sera généralement corrigé dans le prochain niveau de correctif ou dans la prochaine version.
Il y avait la liste de diffusion "linux-kernel" (qui fonctionnait sur le vger d'origine ), les groupes de discussion alt.os.linux, puis comp.os.linux (qui s'est rapidement scindé 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 e-mail à Linus.
En 1992, Matt Welsh (Sous Linux , Bible Linux , TLDP) a annoncé ibug pour aider à 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 manquait de réseau suffisant pour pouvoir envoyer un e-mail).
Un modèle de rapport de bogue par e-mail linux.temp a également été périodiquement publié sur comp.os.linux, et les mises à jour d'un rapport de bogue avaient un modèle de mise à jour linux.fix.temp .
Il y avait aussi un référentiel de correctifs (FTP), pour autant que je sache, il s'agissait principalement (pas exclusivement) de correctifs pour les programmes à porter sur 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, 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 diffs générés par cvs.
1995-1996
À 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 du noyau utilisaient indépendamment CVS pour garder une trace des correctifs, depuis Linux-kernel ce fil et ce fil :Alan Cox, Stephen Tweedie, Kai Henningsen. (Le deuxième fil rapporte Russ Nelson déclarant l'aversion directe de Linus pour 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, à partir de linux-kernel voir ce sous-thread (Linus y 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, les "correctifs linux" JitterBug étaient préconisés sur linux-kernel par Alan Cox. C'était pour autant que je sache, 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é à faire référence (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, voir ce fil de discussion sur le noyau linux, Linus, Alan Cox et bien d'autres s'impliquent dans la discussion.
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'arborescence de développement 2.5.
En novembre 2002, l'OSDL hébergé Linux Bugzilla pour l'arborescence 2.5 a été annoncé. (Si vous n'avez pas déjà lu le lien bugzilla dans la question, allez le lire maintenant, il contient des diatribes vintage de Linus).
En avril 2005, Linus a annoncé qu'il s'éloignait de BitKeeper, à peu près au moment où il a mentionné pour la première fois git de nom. 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 suivi des correctifs Patchwork pour linux-kernel a été annoncé. Il s'agit d'un suivi des correctifs basé sur le Web indépendant du SCCS qui s'intègre aux listes de diffusion pour suivre les correctifs et les suivis. Son utilisation continue à ce jour, il y a environ 40 listes suivies de cette façon sur https://patchwork.kernel.org/ , bien que toutes ne soient pas actives.
Références
Références utiles :
- L'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)
- Directives pour signaler les bogues Linux (juillet 1992) http://www.linuxmisc.com/19-linux/c27174dbc2bf7185.htm
- Archives de Kenneth R. Saborio contenant des publications/e-mails Linux importants :http://www.informatica.co.cr/linux/index.htm (1991-2005)
- archives Linux-kernel d'aujourd'hui (novembre 2014) jusqu'à 1995http://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 les archives antérieures ...) L'archive LKML ne remonte qu'à 1996
- Fragments 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/(ignorer les dates dans l'URL et sur les fichiers)
- Outils de gestion des versions :CVS à BK dans le noyau Linux , Sjaikh &Cornford (vers 2003)
- Voir aussi cette Hacker News thread (mars 2015) à l'approche 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 git lui-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 ça marche 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 cherchant dans les archives des listes de diffusion de git.
Il ne s'agit pas de "nous n'avons pas encore trouvé de bug tracker 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 mainteneur 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 cela 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 de l'état hebdomadaire.
Il énumère les choses qui se passent actuellement sur les différentes branches sous forme d'articles courts. Pour un exemple du développement git, voir ceci sur le groupe de discussion gmane.comp.version-control.git miroir de la liste de diffusion :Qu'est-ce qui mijote dans git.git
Ce que je peux dire avec certitude :si vous avez un mainteneur qui est bon dans ce domaine, cela fonctionne extrêmement bien.
Par exemple, je serais très surpris si l'introduction d'un bug tracker 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 c'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 lieu central comme avec git. Il existe des listes distinctes pour les sous-thèmes, comme les systèmes de fichiers ou la mise en réseau.
Étant donné qu'il existe des sujets distincts, gérés par des développeurs pour la plupart distincts, il est possible que certains groupes utilisent des outils localement pour leur groupe.