Erster Teil des Interviews.
Verteiltes Versionskontrollsystem Git
JA: Linux ist nur das erste Ihrer Projekte, das sich global auf die Open Source-Welt auswirkt. Im Jahr 2005 haben Sie auch Git erstellt, ein äußerst beliebtes verteiltes Versionskontrollsystem. Sie haben Ihren Linux-Kernel-Quellbaum schnell vom proprietären Bitkeeper-Repository auf das neu geprägte Git verschoben, das Sie als Open Source erstellt haben, und im selben Jahr haben Sie die Git-Unterstützung an Junio Hamano übertragen . Die Geschichte dieser Ereignisse ist faszinierend. Erzählen Sie uns, was Sie dazu veranlasst hat, dieses Projekt so schnell zu übergeben, und wie haben Sie Junio gefunden und ausgewählt?
LT: Die Antwort auf diese Frage besteht also aus zwei Teilen.
Erstens wollte ich absolut kein neues Versionsverwaltungssystem erstellen. Linux wurde geschaffen, weil ich mich sehr für die Low-Level-Schnittstelle zwischen Hardware und Software interessierte - im Prinzip wurde diese Arbeit aus Liebe zum Thema und persönlichem Interesse gemacht. Im Gegenteil, Git wurde aus der Not heraus geschaffen: nicht weil ich an der Quellcodeverwaltung interessiert war, sondern weil die meisten der damals verfügbaren Versionskontrollsysteme mir einen echten Ekel bereiteten und das, das mir am erträglichsten und am erträglichsten erschien Gleichzeitig hat das Linux-Entwicklungsmodell (BitKeeper) sehr gut funktioniert und ist bankrott gegangen.
Fazit: Ich arbeite seit über 30 Jahren an Linux (es gibt noch ein paar Monate vor dem Jahrestag der ersten Veröffentlichung , aber ich habe vor mehr als 30 Jahren angefangen, an dem zu arbeiten, was später Linux wurde), und die ganze Zeit ich habe es unterstützt. Aber Git? Ich habe nicht einmal darüber nachgedacht, wie ich es langfristig aufrechterhalten kann. Ich mag es definitiv und natürlich denke ich, dass es das beste verfügbare Quellcodeverwaltungssystem ist, aber es ist nicht meine große Liebe und Leidenschaft, wenn Sie wissen, was ich meine.
Deshalb wollte ich immer jemanden finden, der dieses Versionsverwaltungssystem für mich wartet. in der Tat würde ich mich freuen, es überhaupt nicht zu schreiben.
Dies ist der Kontext.
Was Junio betrifft - tatsächlich ist er einer der ersten, der sich wirklich mit der Git-Entwicklung beschäftigt. Die ersten Änderungen von ihm kamen innerhalb weniger Tage zu mir, nachdem ich die allererste (und sehr grobe) Version von Git öffentlich zugänglich gemacht hatte. Daher war Junio von Anfang an an diesem Projekt beteiligt, könnte man sagen.
Aber denken Sie nicht, dass ich das Projekt gerade der ersten Person übergeben habe, die ich getroffen habe. Ich habe Git seit mehreren Monaten gewartet, und was mich dazu veranlasste, Junio zu fragen, ob er diese Unterstützung übernehmen möchte, ist das subtile Gefühl von "gutem Geschmack". In der Tat kann ich es nicht genauer beschreiben: Die Programmierung beschränkt sich auf die Lösung technischer Probleme, aber der Punkt ist, wieSie lösen sie, und dies ist eines der Dinge, die im Laufe der Zeit erkannt werden: Bestimmte Menschen haben einen "guten Geschmack" und wählen daher die "richtige" Lösung.
Ich möchte nicht so tun, als sei Programmieren eine Kunst, denn in Wirklichkeit ist Programmieren im Grunde genommen eine gute Technik. Ich glaube fest an Thomas Edisons Mantra "ein Prozent Talent und neunundneunzig Prozent Fleiß"; Fast der ganze Erfolg liegt in kleinen Details und der täglichen Routinearbeit. Trotzdem muss man manchmal „Inspiration“ und diesen „guten Geschmack“ zeigen, dh nicht nur ein Problem lösen, sondern es sauber, genau und ja sogar schön lösen.
Junio hat so einen "guten Geschmack".
Wenn es um Git geht, erinnere ich mich daran, dass ich mir darüber im Klaren war: Während ich Pionierarbeit bei Git geleistet und seine Kernideen entworfen habe, bekomme ich oft überwältigende Anerkennung dafür. Das war vor über 15 Jahren und ich war erst im ersten Jahr wirklich in Git versunken. Junio ist vorbildlich in der Unterstützung von Git, und wegen ihm ist Git das, was es heute ist.
Übrigens gilt diese ganze Geschichte mit "gutem Geschmack" und der Suche nach Menschen, die sie haben, sowie mit der Fähigkeit, diesen Menschen zu vertrauen - nicht nur für Git, sondern in nicht geringerem Maße für die gesamte Geschichte von Linux. Im Gegensatz zu Git ist Linux ein Produkt, das ich immer noch unterstütze. Ich bin aktiv engagiert, aber was Linux in vielerlei Hinsicht Git ähnelt, ist die Beteiligung einer großen Anzahl von Menschen an dem Projekt. Ich denke, eine der bemerkenswertesten Errungenschaften von Linux ist, dass es buchstäblich Hunderte von aktiven Mitwirkenden gibt, die es unterstützen, und alle, die für verschiedene Teile des Kernels verantwortlich sind, haben diesen schwer zu definierenden "Geschmackssinn".
JA: Haben Sie jemals Unterstützung an jemanden delegiert und dann festgestellt, dass diese Entscheidung falsch war?
LT: Die Struktur unserer Unterstützungsarbeit war noch nie so schwarzweiß oder unflexibel, dass es uns Probleme bereitet. Tatsächlich ist es unwahrscheinlich, dass wir jemals versuchen werden, das Support-Verfahren gründlich zu dokumentieren. Ja, wir haben eine MAINTAINERS-Datei, aber sie wurde erstellt, damit Sie können Die richtigen Leute zu finden ist nicht wirklich ein Zeichen für einen exklusiven Besitz.
Daher ist die gesamte Struktur „Wem gehört was?“ Meist plastisch und dient zur Orientierung. Dies bedeutet, dass „diese Person aktiv ist und ihre Arbeit gut macht“ und nicht „Hoppla, wir haben der Person das Projekt anvertraut, aber er hat es übernommen und alles vermasselt “.
Die Situation ist auch plastisch in dem Sinne, dass Sie vielleicht ein Subsystem unterstützen, aber etwas von einem anderen System übernehmen müssen - diese Grenzen sind also durchlässig. Normalerweise werden solche Dinge zuerst aktiv mit Menschen besprochen und erst dann erledigt, aber der Punkt ist, dass es eine solche Praxis gibt und es keine festen Regeln wie „Sie können nur diese Datei berühren“ gibt.
Tatsächlich gehen wir hier noch einmal auf das in Teil 1 angesprochene Lizenzierungsthema ein und heben eines der Prinzipien hervor, nach denen Git entworfen wurde: "Jeder hat seinen eigenen Baum, und technisch gesehen ist kein Baum etwas Besonderes."
Da so viele andere Projekte verwendet Tools wie CVS oder SVN - grundsätzlich einige Leute haben sich besondere und nutzen Sie den „Besitz“ , die mit diesem Status kommt. In der BSD-Welt wird dieses Phänomen als "Festschreibungsbit" bezeichnet: Es ist ein Bit, dessen Eigentümer das Recht hat, Code in das zentrale Repository (oder zumindest in einige Teile davon) festzuschreiben.
Ich habe dieses Modell immer gehasst, weil es unweigerlich die Politik beeinflusst und eine "Clique" in der Entwicklergemeinschaft erzeugt, in der einige Leute privilegiert werden und ihnen standardmäßig vertraut wird. Das Problem ist nicht einmal, dass sie "standardmäßig vertrauen", sondern nur auf der anderen Seite der Medaille: Sie vertrauen niemandem , anderen Menschen , und sie erweisen sich per Definition als Außenseiter, die eine durchlaufen müssen der "Wachen", um die Arbeit zu erledigen. "
Auch dies ist in Git nicht der Fall. Jeder ist gleich. Jeder kann einen Zweig klonen, seine eigene Entwicklung beginnen, und wenn er gute Arbeit leistet, kann sein Zweig beim Zusammenführen zum Hauptzweig zurückkehren, und wenn es ihm sehr gut geht, wird ihm Unterstützung anvertraut, und er ist derjenige die anfangen, für das Zusammenführen des Codes in den Bäumen verantwortlich zu sein, für die sie verantwortlich sind;).
Daher besteht keine Notwendigkeit, Personen besondere Privilegien wie eine "Bestätigung" zu verleihen. Dies bedeutet auch, dass keine Festschreibungsrichtlinie entsteht und niemand "standardmäßig vertrauen" muss. Wenn sich herausstellte, dass jemand einen schlechten Job gemacht hat oder die Person häufiger einfach das Interesse an dem Projekt verlor und den Job interessanter fand, wird ihre Arbeit beim Zusammenführen nicht in den Hauptzweig gelangen und sie wird nicht verwirrt die Füße anderer, die neue, frische Ideen anbieten können.
JA: Waren Sie jemals von den neuen Funktionen von Git beeindruckt und haben Sie sie in Ihre Workflows integriert? Können Sie die Funktionen nennen, die Ihrer Meinung nach in Git noch fehlen?
LT: Natürlich waren es vor allem meine Wünsche nach Funktionalität, die erfüllt wurden, so dass ich selten über neue Funktionen nachdenken musste.
Git hat sich im Laufe der Jahre definitiv verbessert, und einige dieser Verbesserungen haben sich auch in meinen Workflows niedergeschlagen. Zum Beispiel war Git immer sehr schnell - schließlich war dies eines der Designziele, die ich mir vorgenommen hatte, aber ein Großteil der Arbeit wurde ursprünglich in Shell-Skripten ausgeführt, die um einige grundlegende Hilfsprogramme herum organisiert waren. Im Laufe der Jahre sind die meisten dieser Shell-Skripte verschwunden, was bedeutet, dass ich Andrew Mortons Patch-Kits noch schneller anwenden kann als ursprünglich. Dies ist sehr ermutigend, da es die Geschwindigkeit war, mit Patches zu arbeiten, die ich als einen der ersten Benchmarks bei Leistungstests verwendet habe.
Für mich war Git immer gut, aber mit der Zeit wurde es immer besser.
Von Bedeutung Die Verbesserungen hängen damit zusammen, wie viel komfortabler es für "normale Benutzer" wurde, mit Git zu arbeiten. Vor allem aufgrund der Tatsache, dass die Leute herausgefunden haben, wie der Taskflow in Git funktioniert, und sich gerade erst daran gewöhnt haben (es unterscheidet sich sehr von CVS und anderen Analoga, an die die Leute früher gewöhnt waren), aber Git selbst ist viel angenehmer geworden benutzen.
Cloud-Server von Macleod sind schnell und sicher.
Registrieren Sie sich über den obigen Link oder indem Sie auf das Banner klicken und erhalten Sie 10% Rabatt für den ersten Monat der Anmietung eines Servers einer beliebigen Konfiguration!
