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
- Comment Linus, les responsables du sous-système et les utilisateurs ont-ils alors signalé et suivi les bogues à cette époque?
- 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.
- 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é.
Réponses:
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
[email protected]avant lakernel.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,MAINTAINERSetREPORTING-BUGS.L'une des choses intéressantes que vous pouvez y trouver est celle-ci dans le README Linux-0.99.12:
la source
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 çadiff+patch.Depuis l' installation et le démarrage de Linux (janvier 1994, copie archivée v2.0) >
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:
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é
ibugson 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 par
linux.tempcourrier é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:
la source
dg.com. Était Data General, maintenant Dollar General. Un peu triste, mais aussi hilarant.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.gitCe 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.
la source