Première partie de l' entretien.
Système de contrôle de version distribué Git
JA: Linux n'est que le premier de vos projets à avoir un impact global sur le monde de l'open source. En 2005, vous avez également créé Git, un système de contrôle de version distribué extrêmement populaire. Vous avez rapidement déplacé l'arborescence des sources de votre noyau Linux du dépôt propriétaire Bitkeeper vers le Git nouvellement créé, que vous avez rendu open-source, et la même année, vous avez transféré le support Git vers Junio Hamano . L'histoire de ces événements est passionnante, dites-nous ce qui vous a poussé à remettre ce projet si rapidement, et comment avez-vous trouvé et choisi Junio?
LT: La réponse à cette question comporte donc deux parties.
Premièrement, je ne voulais absolument pas créer un nouveau système de contrôle de source. Linux a été créé parce que j'étais très intéressé par l'interface de bas niveau entre le matériel et le logiciel - en principe, ce travail a été fait par amour du sujet et par intérêt personnel. Au contraire, Git a été créé par nécessité: non pas parce que je m'intéressais au contrôle de code source, mais parce que la plupart des systèmes de contrôle de version disponibles à l'époque me donnaient un réel dégoût, et celui qui me paraissait le plus supportable et à le même temps a vraiment très bien fonctionné avec le modèle de développement Linux (BitKeeper) a fait faillite.
Bottom line: je travaille sur Linux depuis plus de 30 ans (il reste encore quelques mois avant l'anniversaire de la première version , mais j'ai commencé à travailler sur ce qui est devenu plus tard Linux il y a plus de 30 ans), et pendant tout ce temps je l'ont soutenu. Mais Git? Je n'ai même pas réfléchi à la façon de le maintenir à long terme. Je l'aime vraiment, et bien sûr, je pense que c'est le meilleur système de contrôle de source disponible, mais ce n'est pas mon grand amour et ma passion, si vous voyez ce que je veux dire.
J'ai donc toujours voulu trouver quelqu'un pour entretenir ce système de contrôle de source pour moi; en fait, je serais heureux de ne pas l'écrire du tout.
Tel est le contexte.
Quant à Junio - en fait, il est l'un des premiers à vraiment se lancer dans le développement de Git. Les premiers changements de sa part m'est venu quelques jours après avoir rendu la toute première (et très rudimentaire) version de Git accessible au public. Par conséquent, Junio a été impliqué dans ce projet, pourrait-on dire, depuis les tout premiers jours de Git.
Mais ne pensez pas que je viens de confier le projet à la première personne que j'ai rencontrée. Je maintiens Git depuis plusieurs mois et ce qui m'a poussé à demander à Junio s'il souhaitait reprendre ce support, c'est le sens subtil du «bon goût». En effet, je ne peux pas le décrire plus précisément: la programmation se réduit à résoudre des problèmes techniques, mais le problème est de savoir commentvous les résolvez, et c'est une de ces choses qui commencent à se reconnaître avec le temps: certaines personnes ont «bon goût» et choisissent donc la «bonne» solution.
Je ne veux pas prétendre que la programmation est un art, car en réalité, la programmation est fondamentalement une bonne ingénierie. Je crois profondément au mantra de Thomas Edison «un pour cent de talent et quatre-vingt-dix-neuf pour cent de diligence»; presque tout le succès réside dans les petits détails et le travail de routine quotidien. Mais, néanmoins, il faut parfois montrer «l'inspiration» et ce «bon goût», c'est-à-dire non seulement résoudre un problème, mais le résoudre proprement, avec précision et, oui, même magnifiquement.
Junio a un "bon goût".
Chaque fois qu'il s'agit de Git, je me souviens d'être très clair à ce sujet: alors que j'ai été le pionnier de Git et que j'ai conçu ses idées de base, je reçois souvent une immense reconnaissance pour cela. C'était il y a plus de 15 ans, et je n'étais vraiment immergé dans Git que la première année. Junio est exemplaire pour soutenir Git, et c'est grâce à lui que Git est ce qu'il est aujourd'hui.
Au fait, toute cette histoire avec "bon goût" et à la recherche de personnes qui en ont, ainsi que la capacité de faire confiance à ces personnes - s'applique non seulement à Git, mais pas moins à toute l'histoire de Linux. Contrairement à Git, Linux est un produit que je supporte toujours . Je suis activement engagé, mais ce que Linux est à bien des égards similaire à Git, c'est l'implication d'un grand nombre de personnes dans le projet. Je pense que l'une des réalisations les plus remarquables de Linux est qu'il y a littéralement des centaines de contributeurs actifs qui le soutiennent, et tous, qui sont responsables de différentes parties du noyau, ont ce «sens du goût» difficile à définir.
JA: Avez-vous déjà délégué du soutien à quelqu'un et vous êtes-vous rendu compte que cette décision était erronée?
LT: La structure de notre travail de soutien n'a jamais été aussi noire et blanche ou inflexible qu'elle nous pose des problèmes. En fait, il est peu probable que nous essaierons jamais de documenter complètement la procédure de soutien. Oui, nous avons un fichier MAINTAINERS, mais il a été créé pour que vous puissiez trouver les bonnes personnes n'est pas vraiment le signe d'une sorte de possession exclusive.
Par conséquent, toute la structure «à qui appartient quoi» est majoritairement plastique et destinée à l'orientation, cela signifie «cette personne est active et fait bien son travail», et non «oups, on a confié le projet à la personne, mais il l'a pris et tout foiré ».
La situation est également plastique dans le sens où vous supportez peut-être un sous-système, mais vous devez récupérer quelque chose d'un autre système - donc, ces limites sont perméables. Habituellement, de telles choses sont d'abord activement discutées avec les gens, et ce n'est qu'alors qu'elles sont terminées, mais le fait est qu'il existe une telle pratique et qu'il n'y a pas de règles strictes comme «vous ne pouvez toucher que ce fichier».
En fait, nous revisitons ici le sujet des licences soulevé dans la partie 1 et soulignons l'un des principes par lesquels Git est conçu, à savoir «chacun a son propre arbre, et techniquement aucun arbre n'est spécial».
Depuis tant d'autres projets ont utilisé des outils tels que CVS ou SVN - fondamentalement certaines personnes ne deviennent spéciales et tirer parti de la « possession » qui vient avec ce statut. Dans le monde BSD, ce phénomène s'appelle le "bit de validation": c'est un bit dont le propriétaire a le droit de valider du code dans le référentiel central (ou du moins dans certaines parties de celui-ci).
J'ai toujours détesté ce modèle, car il affecte inévitablement la politique et génère une "clique" dans la communauté des développeurs, où certaines personnes deviennent privilégiées, et on leur fait confiance par défaut. Le problème n’est même pas qu’ils «font confiance par défaut», mais simplement de l’autre côté de la médaille: ils ne font pas confiance à quelqu'un, à d’ autres personnes et, par définition, ils se révèlent être des étrangers qui ont besoin d’en passer par un. des «gardes» pour faire le travail. ».
Encore une fois, ce n'est pas le cas dans Git. Tout le monde est égal. Tout le monde peut cloner une branche, démarrer son propre développement, et s'ils font du bon travail, alors lorsqu'ils fusionnent, leur branche peut revenir à la branche principale, et si très bien, alors ils se voient confier un support, et ce sont eux. qui commencent à être responsables de la fusion du code dans ces arbres. dont ils sont responsables;).
Par conséquent, il n'est pas nécessaire de doter les gens de privilèges spéciaux, un tel «peu de confirmation». Cela signifie également qu'aucune politique de validation ne survient, que personne ne doit «faire confiance par défaut». S'il s'avère que quelqu'un a fait un mauvais travail, ou, plus souvent, la personne a simplement perdu tout intérêt pour le projet et a trouvé le travail plus intéressant - son travail n'entrera pas dans la branche principale lors de la fusion, et il ne sera pas confus sous les pieds des autres qui peuvent offrir des idées nouvelles et fraîches.
JA: Avez-vous déjà été impressionné par les nouvelles fonctionnalités de Git et les avez-vous intégrées dans vos flux de travail? Pouvez-vous nommer les fonctionnalités qui, à votre avis, manquent encore dans Git?
LT: bien sûr, tout d'abord, c'était mes souhaits de fonctionnalité qui étaient satisfaits, donc je devais rarement penser à de nouvelles fonctionnalités.
Git s'est définitivement amélioré au fil des ans, et certaines de ces améliorations se sont également reflétées dans mes flux de travail. Par exemple, Git a toujours été très rapide - après tout, c'était l'un des objectifs de conception que je me suis fixé, mais une grande partie du travail était à l'origine effectuée dans des scripts shell organisés autour de programmes d'aide de base. Au fil des ans, la plupart de ces scripts shell ont disparu, ce qui signifie que je peux appliquer les kits de correctifs d'Andrew Morton encore plus rapidement que je ne le faisais à l'origine. C'est très encourageant, car c'est la vitesse de travail avec les correctifs que j'ai utilisée comme l'un des premiers points de repère dans les tests de performance.
Donc, pour moi, Git a toujours été bon, mais il s'est amélioré avec le temps.
Important les améliorations sont liées à la façon dont il est devenu plus confortable pour les "utilisateurs réguliers" de travailler avec Git. En grande partie parce que les gens ont compris comment fonctionne le flux de tâches dans Git et s'y sont habitués (c'est très différent de CVS et d'autres analogues auxquels les gens sont habitués auparavant), mais Git lui-même est devenu beaucoup plus agréable à utiliser. utiliser.
Les serveurs cloud de Macleod sont rapides et sécurisés.
Inscrivez-vous en utilisant le lien ci-dessus ou en cliquant sur la bannière et bénéficiez d'une remise de 10% pour le premier mois de location d'un serveur de toute configuration!
