Primera parte de la entrevista.
Sistema de control de versiones distribuido Git
JA: Linux es solo el primero de sus proyectos en impactar globalmente el mundo del código abierto. En 2005, también creó Git, un sistema de control de versiones distribuido extremadamente popular. Rápidamente movió su árbol de fuentes del kernel de Linux del repositorio propietario de Bitkeeper al Git recién creado, que hizo de código abierto, y ese mismo año transfirió el soporte de Git a Junio Hamano . La historia de estos eventos es fascinante, cuéntanos qué te impulsó a entregar este proyecto tan rápido, y cómo encontraste y escogiste a Junio.
LT: Entonces, la respuesta a esta pregunta tiene dos partes.
Primero, absolutamente no quería crear un nuevo sistema de control de fuentes. Linux se creó porque estaba muy interesado en la interfaz de bajo nivel entre hardware y software; en principio, este trabajo se realizó por amor al tema e interés personal. Al contrario, Git se creó por necesidad: no porque me interesara el control de fuentes, sino porque la mayoría de los sistemas de control de versiones disponibles en ese momento me daban un verdadero disgusto, y el que me parecía el más llevadero y en Al mismo tiempo realmente funcionó muy bien con el modelo de desarrollo de Linux (BitKeeper) que se quebró.
En pocas palabras: he estado trabajando en Linux durante más de 30 años (todavía quedan un par de meses antes del aniversario de la primera versión , pero comencé a trabajar en lo que luego se convirtió en Linux hace más de 30 años), y todo este tiempo lo he estado apoyando. ¿Pero Git? Ni siquiera pensé en cómo mantenerlo a largo plazo. Definitivamente me gusta y, por supuesto, creo que es el mejor sistema de control de fuente disponible, pero no es mi gran amor y pasión, si sabes a qué me refiero.
Así que siempre quise encontrar a alguien que me mantuviera este sistema de control de fuentes; de hecho, estaría feliz de no escribirlo en absoluto.
Este es el contexto.
En cuanto a Junio, de hecho, es uno de los primeros en adentrarse realmente en el desarrollo de Git. Los primeros cambios de él vinieron a mí unos días después de que hice pública la primera (y muy cruda) versión de Git. Por tanto, Junio ha estado involucrado en este proyecto, se podría decir, desde los inicios de Git.
Pero no creas que acabo de entregar el proyecto a la primera persona que conocí. He estado manteniendo Git durante varios meses, y lo que me impulsó a preguntarle a Junio si le gustaría hacerse cargo de este soporte es la sutil sensación de "buen gusto". De hecho, no puedo describirlo con más precisión: la programación se reduce a resolver problemas técnicos, pero el punto es cómolos resuelves, y esta es una de esas cosas que empiezan a reconocerse con el tiempo: hay personas que tienen "buen gusto" y por eso eligen la solución "adecuada".
No quiero fingir que la programación es un arte, porque en realidad la programación es básicamente una buena ingeniería. Creo profundamente en el mantra de Thomas Edison de "uno por ciento de talento y noventa y nueve por ciento de diligencia"; casi todo el objetivo del éxito radica en los pequeños detalles y el trabajo de rutina diaria. Pero, sin embargo, a veces hay que mostrar “inspiración” y ese “buen gusto”, es decir, no solo resolver un problema, sino resolverlo de forma limpia, precisa y, sí, hasta bella.
Junio tiene tan "buen gusto".
Siempre que se trata de Git, recuerdo ser muy claro al respecto: aunque fui pionero en Git y diseñé sus ideas centrales, a menudo obtengo un reconocimiento abrumador por ello. Esto fue hace más de 15 años, y solo estuve realmente inmerso en Git durante el primer año. Junio es ejemplar en el apoyo a Git, y es por él que Git es lo que es hoy.
Por cierto, toda esta historia con "buen gusto" y buscando personas que lo tengan, así como con la capacidad de confiar en estas personas, se aplica no solo a Git, sino no menos a toda la historia de Linux. A diferencia de Git, Linux es un producto que sigo soportando. Estoy activamente comprometido, pero lo que Linux se parece en muchos aspectos a Git es la participación de una gran cantidad de personas en el proyecto. Creo que uno de los logros más notables de Linux es que hay literalmente cientos de colaboradores activos que lo apoyan, y todos ellos, que son responsables de diferentes partes del kernel, tienen este "sentido del gusto" difícil de definir.
JA: ¿Alguna vez delegó el apoyo a alguien y luego se dio cuenta de que esta decisión estaba mal?
LT: La estructura de nuestro trabajo de soporte nunca ha sido tan blanco o negro o tan inflexible como para darnos problemas. De hecho, es poco probable que alguna vez intentemos documentar a fondo el procedimiento de soporte. Sí, tenemos un archivo MAINTAINERS, pero fue creado para que pueda encontrar a las personas adecuadas no es realmente un signo de algún tipo de posesión exclusiva.
Por lo tanto, toda la estructura "quién es dueño de qué" es mayoritariamente plástica y está destinada a la orientación, significa "esta persona es activa y hace bien su trabajo", y no "vaya, le confiamos el proyecto a la persona, pero él lo tomó y arruinó todo ”.
La situación también es plástica en el sentido de que tal vez esté apoyando un subsistema, pero necesita tomar algo de otro sistema, por lo que estos límites son permeables. Por lo general, estas cosas primero se discuten activamente con la gente, y solo luego se hacen, pero el punto es que existe tal práctica y no hay reglas estrictas y rápidas como "solo se puede tocar este archivo".
De hecho, aquí revisamos el tema de las licencias planteado en la Parte 1 y destacamos uno de los principios por los que se diseñó Git, que es "todos tienen su propio árbol y, técnicamente, ningún árbol es especial".
Ya que muchos otros proyectos han utilizado herramientas como CVS o SVN - fundamentalmente algunas personas hacen especial y se convierten en tomar ventaja de la "posesión" que viene con esa condición. En el mundo BSD, este fenómeno se llama "bit de confirmación": es un bit, cuyo propietario tiene derecho a enviar código al repositorio central (o al menos algunas partes de él).
Siempre he odiado este modelo, porque inevitablemente afecta a la política y genera una "camarilla" en la comunidad de desarrolladores, donde algunas personas se vuelven privilegiadas y se confía en ellas por defecto. El problema ni siquiera es que "confían por defecto", sino simplemente en la otra cara de la moneda: no confían en alguien, en otras personas y, por definición, resultan ser extraños que necesitan pasar por de los "guardias" para hacer el trabajo ".
Nuevamente, este no es el caso en Git. Todos son iguales. Todos pueden clonar una rama, comenzar su propio desarrollo, y si hacen un buen trabajo, cuando se fusionan, su rama puede volver a la principal, y si está muy bien, se les confía el apoyo, y son ellos. quienes comienzan a ser responsables de fusionar el código en esos árboles. de los que son responsables;).
Por lo tanto, no es necesario dotar a las personas de privilegios especiales, como "un poco de confirmación". También significa que no surge ninguna política de compromiso, nadie tiene que "confiar de forma predeterminada". Si resultó que alguien hizo un mal trabajo o, más a menudo, la persona simplemente perdió el interés en el proyecto y encontró el trabajo más interesante, su trabajo no entrará en la rama principal al fusionarse y no se confundirán con los pies de otros que pueden ofrecer ideas nuevas y frescas.
JA: ¿Alguna vez te han impresionado las nuevas funciones de Git y las has incorporado a tus flujos de trabajo? ¿Puedes nombrar las características que, en tu opinión, todavía faltan en Git?
LT: por supuesto, en primer lugar, fueron mis deseos de funcionalidad los que quedaron satisfechos, por lo que rara vez tuve que pensar en nuevas características.
Git definitivamente ha mejorado a lo largo de los años, y algunas de estas mejoras también se han reflejado en mis flujos de trabajo. Por ejemplo, Git siempre ha sido muy rápido; después de todo, ese era uno de los objetivos de diseño que me propuse hacer, pero gran parte del trabajo se realizó originalmente en scripts de shell organizados en torno a algunos programas auxiliares básicos. A lo largo de los años, la mayoría de estos scripts de shell han desaparecido, lo que significa que puedo aplicar los kits de parches de Andrew Morton incluso más rápido de lo que lo hice originalmente. Esto es muy alentador, ya que fue la velocidad de trabajar con parches lo que utilicé como uno de los primeros puntos de referencia en las pruebas de rendimiento.
Entonces, para mí, Git siempre ha sido bueno, pero solo mejoró con el tiempo.
Significativo las mejoras están relacionadas con cuánto más cómodo se volvió para los "usuarios habituales" trabajar con Git. En gran parte debido al hecho de que la gente descubrió cómo funciona el flujo de tareas en Git, y simplemente se acostumbró a él (es muy diferente de CVS y otros análogos a los que la gente está acostumbrada antes), pero Git en sí se ha vuelto mucho más agradable de usar.
Los servidores en la nube de Macleod son rápidos y seguros.
Regístrese usando el enlace de arriba o haciendo clic en el banner y obtenga un 10% de descuento durante el primer mes de alquiler de un servidor de cualquier configuración.
