Le développement du noyau continue autour de Git

Posté par  (site web personnel) . Modéré par Nÿco.
0
21
avr.
2005
Noyau
Suite à l'annonce de l'arrêt de la version gratuite de BitKeeper, Linus Torvalds et quelques autres développeurs ont travaillé sur un nouveau système pour gérer le développement du noyau, appelé Git.

Ce week-end, deux développeurs du noyau ont réussi chacun de leur côté à importer la totalité de l'historique du noyau dans Git, l'un à partir de CVS, l'autre à partir de BitKeeper. Ces trois ans d'historique représentaient 3.2 Go de données une fois importées dans Git, ce qui pour Linus Torvalds est tout à fait raisonnable et conforme à ses prédictions.

Toutefois, Linus a proposé de ne pas importer tout l'historique dans Git, mais de repartir de zéro. Cette proposition n'a pas rencontré d'opposition et le développement du noyau a donc repris en utilisant Git. Depuis, plusieurs dizaines de patches ont été intégrés, aboutissant à la sortie de la version 2.6.12-rc3 du noyau. Cette version est la première utilisant le nouveau système de gestion des sources Git.

Par ailleurs, Tony Luck a annoncé qu'il avait rédigé un guide pour les débutants de Git et des développeurs ont annoncé l'existence de deux interfaces Web pour Git : gitweb et wit.

Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.

Aller plus loin

  • # BK vs git.

    Posté par  (site web personnel) . Évalué à 10.

    Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.

    Oui c'est interessant, mais BK est a des années lumiere de git. Faut pas non plus croire qu'on developpe un outil avec autant de features que BK, comme ça en 3 semaines, meme avec les meilleurs developpeurs du monde.
    • [^] # Re: BK vs git.

      Posté par  . Évalué à 3.

      C'est vrai, mais si une solution libre avait ete recherchee a l'epoque, on pourrait imaginer que la situation actuelle ne serait jamais arrivee (et on ne peut pas dire que Torvalds n'a pas ete prevenu), et que "Git" serait bien plus avance aujourd'hui. L'utilisation d'un logiciel proprio a forcement ralenti le developpement d'un CMS "special kernel" libre puisque le besoin n'existait pas.
      • [^] # Re: BK vs git.

        Posté par  (site web personnel) . Évalué à 8.

        On pourrait aussi imaginer que Linus aurait laisser tomber le développement du noyau, ne tenant plus la charge. On pourrait aussi imaginer que Bill Gates aurait repris le développement pour se changer les idées, après tout c'est facile d'imaginer.

        On peut aussi se dire que l'utilisation d'un logiciel proprio a explicitement motivé plusieurs projets (notamment GNU Arch), et que sans ça on aurait pas eu toute cette palette de nouveaux outils qui arrivent à maturité en ce moment.
      • [^] # Re: BK vs git.

        Posté par  (site web personnel) . Évalué à 5.

        C'est vrai, mais si une solution libre avait ete recherchee a l'epoque, on pourrait imaginer que la situation actuelle ne serait jamais arrivee (et on ne peut pas dire que Torvalds n'a pas ete prevenu), et que "Git" serait bien plus avance aujourd'hui.

        Je ne suis pas d'accord. Linus avait recherché, il y a 3 ans, des solutions mais aucune ne lui convenait. 3 ans apres, il a encore recherché mais la encore aucune solution ne convenait non plus. Ses besoins sont specifiques, et il a donc developpé un outil qui y repondait.
        • [^] # Re: BK vs git.

          Posté par  . Évalué à -1.

          >il a donc developpé un outil qui y repondait

          Non, il a pris un outil proprio qui a ete developpe en fonction de ses besoins, avec une license absolument inacceptable (clause de non-concurrence).
          C'est vrai qu'il y a 3 ans les outils n'etaient pas la. Mais aujourd'hui, ils le sont, puisque "Git" a ete juge acceptable pour la production. Il n'est peut-etre pas au niveau de BK, mais ca m'etonnerait que cela dure longtemps.
          Encore une fois, McVoy a beaucoup a perdre. Il a bien profite de la pub que le developpement du noyau Linux lui a faite, et maintenant il se retrouve avec un concurrent libre sur le marche. Pas une tres bonne manoeuvre, finalement.
          • [^] # Re: BK vs git.

            Posté par  (site web personnel) . Évalué à 3.

            >il a donc developpé un outil qui y repondait

            Non, il a pris un outil proprio qui a ete developpe en fonction de ses besoins


            Il parlait de git... essaye de lire les commentaires en entier avant de t'enflammer!
            • [^] # Re: BK vs git.

              Posté par  . Évalué à 6.

              J'ai fait un contresens, desole.
              Mais ca va justement dans le meme sens. Git n'a pas mis bien longtemps a etre developpe. Ce qui a ete fait aujourd'hui aurait pu etre fait il y a trois ans, quand ceux qui se sont faits traiter "d'integristes" l'avaient mis en garde contre l'adoption de BK.
      • [^] # Re: BK vs git.

        Posté par  (site web personnel) . Évalué à 6.

        > L'utilisation d'un logiciel proprio a forcement ralenti le developpement d'un CMS "special kernel" libre puisque le besoin n'existait pas.

        D'un autre cote, elle a surement permis a Linus de se fixer les idees sur ce qu'il voulait dans un SCM (et pas un CMS, vive les acronymes). Avant bitkeeper, il n'en avait pas trouve qui lui convienne et il n'aurait probablement pu en pondre un aussi vite.

        Linus a aussi eu l'habitude de travailler pendant tres longtemps avec des outils tres simples: patch, diff, et le mail pour stocker les patches en cours. Je soupconne que s'il n'avait pas eu un outil tres sophistique pendant quelques temps, il aurait continue avec sa methode a lui qui marchait tres bien, c'est a dire a la mano. Evidemment, on peut tout supposer mais de mon point de vue, l'utilisation de bitkeeper a engendre git et ce dernier n'aurait pas vu le jour sans cette periode de transition.
    • [^] # Re: BK vs git.

      Posté par  (site web personnel) . Évalué à 5.


      Face au changement de politique de la société BitMover, il est intéressant de constater la vitesse à laquelle l'équipe de développement du noyau a créé un nouvel outil et l'a rendu utilisable pour continuer le travail et sortir de nouvelles versions.

      Oui c'est interessant, mais BK est a des années lumiere de git. Faut pas non plus croire qu'on developpe un outil avec autant de features que BK, comme ça en 3 semaines, meme avec les meilleurs developpeurs du monde.


      Euh je ferais juste une petite remarque : git n'est pas à l'heure actuelle un SCM, alors comparer des choses qui ne peuvent l'être n'a aucun sens. Donc dire : BK vs git est infondé. git est une bonne base pour développer un SCM, voilà tout.

      Cf : http://lwn.net/Articles/130865/(...)

      Bonne journée,
  • # A pas mesurés

    Posté par  . Évalué à 5.

    Depuis l'article de Kerneltrap:
    He then successfully received a merge from arm maintainer Russell King [interview], with a comment stating, "first ever true git merge. Let's see if it actually works." The merge was a simple one as there were no file conflicts, but as a first step it helped to prove the concepts.

    Les progrès se font donc à pas mesurés. Pour le moment, les fusions de branches de dévelloppement n'ont été testés que dans des cas simple, où il n'y a pas de conflit.
    Là où BitKeeper excelle, il me semble, c'est en ce qui concerne la fusion plus problématique de branches entre les développeurs.
    Ne nous entousasmions donc pas trop vite, le plus dure reste à venir... mais c'est clair que vu la vitesse à laquelle progresse git, je ne serais pas étonné qu'ils arrivent à relever le défit bien vite...

    D'ailleurs en passant, sur la même page, on peut voir:
    after a planned merge of the SCSI development branch following the upcoming release of 2.6.12, "Linux will have more advanced Fibre Channel support than any currently available operating system."

    Un beau pied de nez à tous ceux qui ont décrié le nouveau mode de développement du kernel Linux.
    Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
    ... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).
    • [^] # Re: A pas mesurés

      Posté par  . Évalué à 3.

      Un beau pied de nez à tous ceux qui ont décrié le nouveau mode de développement du kernel Linux.
      Il permet bel et bien d'intégrer des avancées technologiques bien plus vite que par le passé.
      ... maintenant, qu'en est-il au niveau stabilité, j'en sais trop rien, mais chez moi, ça marche (TM).


      Il ne me semble pas avoir lu quelqu'un dire que le nouveau mode de développement rendrait plus difficile l'innovation. Par contre, j'ai lu de nombreuses critiques montrant du doigt l'incapacité à sortir de vraies releases stables (ce qui a été amélioré avec l'apparition des releases de correction mineures en W.X.Y.Z).
  • # git, un outil de bas niveau

    Posté par  (site web personnel) . Évalué à 10.

    Avant que tout le monde (enfin, sauf les deux commentaires précédents) n'imagine que Linus a fait mieux que BitKeeper (et Subversion, Arch, Darcs, Monotone, etc.) en deux semaines, voici quelques précisions sur git.

    git est un outil de bas niveau, simple et très performant, qui a pour but de gérer l'évolution du contenu d'une arborescence. Il gère en gros trois types d'objets de manière très rapide, caractérisés par leur somme de contrôle SHA-1 : des blobs (fichiers de base), des arbres (listes de blobs et d'arbres) et des commit (un arbre correspondant à une version donnée, et liste des commits précédents ayant permis d'en arriver là). Il gère par ailleurs un index, afin d'accélerer le travail sur un arbre voulu. Il permet quelques opérations en plus (affichage du contenu d'un blob à un moment donné, fusion simple d'arbres), et c'est tout. On est très loin des autres systèmes en termes de fonctionnalités (mais Linus n'a pas besoin de tout), et très en avance en termes de performance (car Linus en a bien besoin).

    Et voilà et c'est tout et c'est déjà pas mal. C'est suffisant pour bosser (avec plein de scripts autour pour automatiser, je suppose) en attendant que d'autres solutions deviennent plus matures, ou que git lui-même évolue encore plus.

    Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.

    Bref, la gestion de source dans le monde du libre, qui avait déjà pas mal évolué ces dernières années et ces derniers mois, s'est encore pris un coup d'accélérateur grâce à git. Finalement, BitKeeper aura pas mal fait bouger les choses, quitte à être le bâton plus que la carotte. :-)
    • [^] # Re: git, un outil de bas niveau

      Posté par  . Évalué à 2.

      Je suppose que Git est incrémentale? Si oui, comment gère t'il les patchs au sens diff, rcs?

      J'ai lu que Git est une sorte de système de fichier loopback. Quelqu'un a t'il plus d'infos?
      • [^] # Re: git, un outil de bas niveau

        Posté par  (site web personnel) . Évalué à 4.

        git indexe les fichiers par leurs somme de contrôle (leur nom sur le disque est leur somme de contrôle). Donc si un fichier ne change pas, sa somme de contrôle ne change pas, il n'est stocké qu'une seule fois sur le disque. S'il change, les deux versions sont stockées sur le disque.

        Pour créer un diff, il suffit de regarder les deux commit, voir dans les arbres correspondants si le fichier a changé, et si oui, appeler la bonne vieille commande diff avec les deux fichiers à comparer.

        Pour appliquer un diff, il suffit d'extraire la version voulue (a priori la plus récente), d'utiliser patch, et de stocker la nouvelle version créée.

        Quant à savoir ce que c'est qu'un patch au sens rcs ou un système de fichier loopback (à tes souhaits)... Pas la moindre idée.
      • [^] # Re: git, un outil de bas niveau

        Posté par  . Évalué à 3.

        Je suppose que Git est incrémentale?
        perdu, il stocke chaque nouvelle version, c'est pour ca que l'import BK etait aussi gros...
    • [^] # Re: git, un outil de bas niveau

      Posté par  . Évalué à 3.

      Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.

      Le probleme c'est que git n'est pas rellement portable et s'appuie quand meme pas mal sur le VFS du noyau (cache, ...) et de certaines astuces (lire les fichiers dans l'ordre des inodes) qui ne sont pas toujours vraie partout.
    • [^] # Re: git, un outil de bas niveau

      Posté par  . Évalué à 3.

      Le truc intéressant au niveau des performances, c'est que du coup les gestionnaires de version qui n'utilisent pas de base de données (Arch, Darcs) sont très intéressés par se servir de git sous le capot pour le stockage des fichiers, tout en offrant leurs fonctionnalités plus évoluées.

      C'est officiellement annonce pour Arch:
      http://lists.seyza.com/pipermail/gnu-arch-dev/2005-April/001097.htm(...)
      C'est de tres bonne augure pour Git, qui va surement se retrouver propulse.
  • # Torvalds vs Tridgell

    Posté par  . Évalué à 4.

    A ce propos, il y a une serie d'articles sur The Register sur la crise entre Torvalds et Tridgell, Torvalds l'ayant proprement "assassine":
    http://www.theregister.co.uk/2005/04/14/torvalds_attacks_tridgell/(...)
    http://www.theregister.co.uk/2005/04/21/tridgell_bitkeeper_howto/(...)
    et une reponse de Perens a Torvalds qui lui demande de calmer le jeu.
    http://www.theregister.co.uk/2005/04/15/perens_on_torvalds/(...)
    En effet, le "crime" pretendument effectue par Tridgell ne serait en fait qu'une simple analyse de la facon dont BK enregistrait les donnees sur le disque, et en aucun cas une vraie operation de reverse engineering sur le soft lui-meme. En d'autres termes, les reproches seraient plus du FUD qu'autre chose.
    Perens d'ailleurs rappelle a Linus que c'est lui qui a impose un CMS proprio a la communaute sans ecouter les critiques, et que par consequent il a une part de responsabilite dans ce qui s'est passe. D'autant que ce scenario avait justement ete decrit par les detracteurs de la solution BK.
    • [^] # Re: Torvalds vs Tridgell

      Posté par  (site web personnel) . Évalué à 3.

      N'oublions pas aussi que The Register est un site qui n'hésite pas à jouer la carte du senstionnalisme et qu'il est avec Torvalds vs. Tridgell sur un superbe filon.

      Torvalds (qui n'est pas un saint) n'a clairement pas été content de la « faute » de Tridgell et n'a pas mâché ses mots sur le moment. Celui-ci en dit le moins possible, un comportement recommandé par son avocat, et qui dans le contexte me semble raisonnable. Ceci dit, même si je comprends une part de l'énervement de Linus (paf, obligé de laisser tomber le meilleur outil du monde créé exprès pour lui ou presque), je pense comme beaucoup d'autres que c'est surtout l'auteur de BitKeeper, le sanguin et volubile Larry McVoy, qui est à blâmer avec ses licences encore plus débiles que celles de Microsoft, et sa volonté de les appliquer. (Larry McVoy qui n'est par ailleurs pas le dernier des cons, parce que BitKeeper, techniquement parlant, ça a l'air de bien roxer.) Pour ce que j'en sais, Trigdell était dans son bon droit, éthiquement à coup sûr, légalement je l'espère aussi.

      Enfin bref, je pense que globalement cette « affaire BitKeeper » a fait plus de bien (accélération du développement du noyau, accélération des solutions libres concurrentes) que de mal (grinçages de dents des plus libristes, potentielle « affaire Tridgell »).
      • [^] # Re: Torvalds vs Tridgell

        Posté par  . Évalué à 4.

        N'oublions pas aussi que The Register est un site qui n'hésite pas à jouer la carte du senstionnalisme et qu'il est avec Torvalds vs. Tridgell sur un superbe filon.

        Oui. Pour autant les arguments de Perens sont tres clairs et tres pertinents: McVoy pretend que les meta-donnees creees par BK sont soumises a la license de BK, ce qui est aussi absurde que de dire qu'un logiciel compile avec gcc est "contamine" par la GPL. D'autre part, la license de BK interdit qu'on l'utilise pour creer un concurrent de BK. Quand MS fait ca, on crie au scandale. Pourtant, c'est la license d'un logiciel qui a permis le developpement du noyau pendant 2 ans.

        Bref, finalement avec 2 ans de retard, il est arrive ce qui arriva: l'utilisation d'un CMS libre. Si Linus avait decide cela des le depart, Git en aurait probablement beneficie et n'aurait pas ses limitations actuelles. On verra dans deux ans a quoi ressemble Git, et probablement sera aussi bien sinon meilleur que BK. D'ailleurs, McVoy a beaucoup a perdre dans cette histoire: il y a maintenant un conurrent de BK libre qui va surement evoluer tres rapidement.
        • [^] # Re: Torvalds vs Tridgell

          Posté par  (site web personnel) . Évalué à 5.

          Tu dis: "ce qui est aussi absurde que de dire qu'un logiciel compile avec gcc est "contamine" par la GPL"

          En fait, ce n'est pas si absurde que ça, dans le cas de systèmes comme bison, mais aussi automake ou autoconf par exemple, ou une partie du code généré est directement issu de squelettes qui eux sont sous GPL.
          Il y a d'ailleurs explicitement dans les licences de gcc, autoconf et autres une mension pour éviter cette "contamination" du code produit par l'outil.

          http://lists.gnu.org/archive/html/bison-patches/2003-09/msg00005.html

          et l'extrait :

          # Copyright 1992, 1993, 1994, 1995, 1996, 1998, 1999, 2000, 2001, 2002
          # Free Software Foundation, Inc.
          # This configure script is free software; the Free Software Foundation
          # gives unlimited permission to copy, distribute and modify it.

    • [^] # Re: Torvalds vs Tridgell

      Posté par  . Évalué à 6.

      Sur Groklaw (pas vraiment connu pour etre un site a sensations), il y a un article qui rapporte ce que Tridgell a declare avoir fait, a une conference (LCA 2005). Il a ecoute le serveur Bitkeeper et recopie la sortie de la commande clone. Rien a voir avec du reverse-engineering, seulement la facon dont les data sont ecrites sur le disque.
      Ce que Perens reproche, c'est que Tridgell est considere comme un heros quand il ecoute un reseau MS pour developer Samba, mais un salaud quand il fait ca avec BK. Alors que ce n'est pas la different.
  • # Tracabilité

    Posté par  . Évalué à 5.

    > Toutefois, Linus a proposé de ne pas importer tout l'historique dans Git, mais de repartir de zéro.

    J'ai toujours eu un problème avec Linux c'est le manque de tracabilité du code dans le temps. BK à permis d'assurer cela pour la période ou il a été en fonction mais apparement on repart de 0.

    Il est très interessant quand on s'interesse à un sous système ou un bout de code de pouvoir avoir l'historique depuis l'import de celui-ci. Cela permet entre autre de comprendre pourquoi et comment telle ou telle chose à été faite. De vérifier depuis combien de temps une fonctionalité est dispo etc.

    Repartir à chaque fois de 0 me semble abérrant. Et j'espere qu'à partir de Git tout le monde pourra avoir accès à des informations aussi basiques...

    Note: a l'heure qu'il est linux.bkbits.net ne répond pas :-)
    • [^] # Re: Tracabilité

      Posté par  (site web personnel) . Évalué à 7.

      J'ai toujours eu un problème avec Linux c'est le manque de tracabilité du code dans le temps. BK à permis d'assurer cela pour la période ou il a été en fonction mais apparement on repart de 0.

      Houla, faut pas comprendre ça de travers ! C'est pas comme si Linus avait effacé tout l'historique, ou qu'il s'en foutait. Simplement, il trouve (et tous les autres devs trouvent) que mettre 3,2 Go de données dans un système vieux d'à peine quelques semaines, c'est trop lourd. Ça imposerait que chaque personne voulant utiliser git pour envoyer des patches à Linus devrait télécharger ces 3,2 Go. Merci la bande passante et les resources des serveurs ! Ça ne servirait pas à grand chose, car il n'y a pas encore d'outils pour explorer confortablement l'historique.

      Bref, après avoir vérifié que tout l'historique était bien récupérable des dépôts BitKeeper et CVS, et qu'ils pouvaient facilement mettre l'historique dans un git, les développeurs ont décidé de repousser à plus tard la création d'une archive intégrant le tout, et de travailler avec des dépôts pour l'instant plus légers.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.