Journal Tom Lord abandonne GNU Arch

Posté par  (site web personnel) .
Étiquettes : aucune
0
16
août
2005
Tom Lord, mainteneur de GNU Arch, un programme de gestion de sources, a décidé d'abandonner le poste de mainteneur de GNU Arch.

Pour ma part, je pense que Tom Lord a été un frein pour le projet. Il s'est souvent dispersé dans des projets aux objectifs mal définis (forth, son wiki etc...). Il a pris en hôtage GNU Arch à plusieurs reprises, en refusant sa prise en main par d'autres mainteneurs volontaires et soucieux de l'avenir du projet. Il a aussi souvent laissé de coté des patchs importants.

Enfin, Tom Lord est un personnage à part entière, il n'est pas plus méchant que la moyenne, c'est juste qu'il a son caractère :-)

Le post sur la mailing list:
http://article.gmane.org/gmane.comp.version-control.arch.devel/1516(...)

Même ce mail de départ est quelque peu empreint de sujets polémiques... ahhhhh jusqu'au bout... :-)

Il est quand même plutôt fair play en souhaitant faire de bazaar la nouvelle branche GNU de arch. En effet, suite aux problèmes d'évolution de GNU Arch, Canonical (la boite derriere la Ubuntu) avait choisi de forker GNU Arch pour maintenir son pool de packages. L'objectif de bazaar était de refondre l'UI plutôt touffue de GNU Arch pour en faire quelque de plus simple. Cet objectif a ensuite évolué pour toucher à des choses plus profondes et plus primordiales.

Enfin, bonne chance à Tom Lord pour ces futurs projets.

  • # mercurial

    Posté par  . Évalué à 4.

    J''ai téléchargé bazaar-ng et ai été surpris de voir que le format de stockage est un peu simpliste : chaque révision de chaque fichier est stockée intégralement, dans un fichier différent. Cela empêche de profiter de la très forte redondance qui existe entre versions successives d'un même fichier.

    J'ai ensuite découvert Mercurial, un autre système de gestion de versions distribué qui bénéficie d'un format de stockage et de transmission réseau beaucoup plus efficace. A titre d'exemple, trois mois d'historique de la branche de Linus du noyau 2.6 ne prennent que 200 Mo (pour environ 5000 changesets), et quelques minutes à télécharger avec un ADSL 1024.
    Mercurial est très intéressant car, comme Bazaar-ng, il est écrit en Python, il dispose d'à peu près les mêmes fonctions, et il est beaucoup plus performant.

    La page d'accueil de Mercurial :
    http://www.selenic.com/mercurial/(...)
    Comparaison Mercurial / git / BitKeeper :
    http://www.selenic.com/hg/?cmd=file;filenode=b0166ba7a8977756db92a8(...)
    Naviguer dans le miroir sous Mercurial de Linux 2.6 (branche Linus) :
    http://www.kernel.org/hg/linux-2.6/(...)
    Cloner cette branche dans un repository local :
    $ hg clone http://www.kernel.org/hg/linux-2.6/(...) hg-linux

    • [^] # Re: mercurial

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

      Pub honteuse: concernant Mercurial, voir mes précédents journaux.
      http://linuxfr.org/~GomGom/18736.html(...)
      http://linuxfr.org/~GomGom/18881.html(...)

    • [^] # Re: mercurial

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

      Pour le format de stockage de bazaar-ng, c'est en principe temporaire. Normalement, l'API interne pour accéder aux fichiers d'une révision donnée est suffisament bien faite pour qu'un changement du format d'archive ne casse pas le reste du code. Il faut garder en tête que bazaar-ng n'est qu'un projet très jeune et encore en développement, mais AMA très prometteur.

      Ceci dit, il y a pas mal de gens aussi qui considèrent que le format d'archive avec toutes les révisions d'un fichier stockées intégralement est une bonne chose. C'est ce que fait git, et ce que fait GNU Arch 2.0 (qui a mon avis n'a aucun avenir, mais bon ...). Quand l'archive est locale (c'est souvent le cas pour de la gestion de version distribuée), accéder à la revision n d'un fichier est quasi immédiat.

      Moi, j'aime bien le système de bazaar (et de tla) avec une archive "delta-compressée", qui contient le strict minimum, et une "revision library", sorte de cache local, qui contient toutes les revisions. Du coup, je sais ou sont les données importantes qu'il faut répliquer et sauvegarder régulièrement, et c'est très économe en bande passante.

      • [^] # Re: mercurial

        Posté par  . Évalué à 1.

        Pour le format de stockage de bazaar-ng, c'est en principe temporaire

        Ca me fait penser que j'ai vu ici[1] un debut de rumeur disant qu'il serait possible que Arch utilise le format de stockage de git.

        D'ailleurs il semblerait que certaines personnes (autres que les gens de LKLM) soient interesses par la possibilite d'avoir git comme remplacant a CVS/SVN[1] (et demandent notamment a SourceForge de proposer cette alternative)...

        [1] http://kerneltrap.org/node/5557(...)

        • [^] # Re: mercurial

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

          GNU Arch 2.0 est fortement inspiré de git. Je ne crois pas que le format de stockage soit le même par contre.

          De toutes façons, GNU Arch 2.0 était développé uniquement par Tom, il a fait ça dans son coin, et vraissemblablement, il l'abandonne. Ça n'a pas l'air d'avoir beaucoup d'avenir, ...

      • [^] # Re: mercurial

        Posté par  . Évalué à 2.

        Ceci dit, il y a pas mal de gens aussi qui considèrent que le format d'archive avec toutes les révisions d'un fichier stockées intégralement est une bonne chose. C'est ce que fait git, et ce que fait GNU Arch 2.0 (qui a mon avis n'a aucun avenir, mais bon ...). Quand l'archive est locale (c'est souvent le cas pour de la gestion de version distribuée), accéder à la revision n d'un fichier est quasi immédiat.

        On peut aussi générer des checkpoints tous les N révisions histoire de borner le nombre d'opérations nécessaire pour récupérer une révision arbitraire.

        Encore un autre système très simple : stocker les révisions en entier, mais les concaténer par blocs de N et gzipper la concaténation. C'est simple et très efficace, puisque ça exploite naturellement la très grande redondance entre révisions. C'est ce que j'ai fait dans le petit système de versions codé pour SPIP (j'y divise en plus le texte en courts fragments et ce sont les fragments auxquels j'applique cette technique, ce qui diminue la distance entre les parties redondantes).

        • [^] # Re: mercurial

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

          > On peut aussi générer des checkpoints tous les N révisions

          Ce que font tla et bazaar par exemple (cached revision).

          Encore mieux, on peut ajouter des "ponts" entre les revisions. Par exemple, une révision stockée en "full" toutes les 100 révisions, le diff par rapport à la version n-10 toutes les 10 révisions, en plus des diffs pour chaques révisions.

          Ca faisait d'ailleurs partie des multiples projets jamais réalisés de Tom pour tla.

          En fait, c'est à peu près ce que fait un bon système de backup : Un backup full de temps en temps, un incrémental de niveau 1 régulièrement, et un backup incrémental de niveau 2 tous les jours, par exemple.

    • [^] # Re: mercurial

      Posté par  . Évalué à 3.

      Tla (et baz) n'ont pas de rapport avec bazaar-ng.

      Aujourd'hui personne n'utilise encore bazaar-ng (pas plus que tla 2.0) et ce n'est pas un projet fini.

      J'ai également du mal à voir en quoi le fait que bazaar-ng et mercurial soient écrits en python constitue un avantage.

      • [^] # Re: mercurial

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

        > Tla (et baz) n'ont pas de rapport avec bazaar-ng.

        Faut le dire vite.

        L'histoire commence le jour ou les gens de canonical se disent que tla est bien, mais que "it sucks"(tm). Ils décident de créer bazaar, qui est un projet à court terme, pour faire quelque chose qui "sucks less". bazaar-ng (bazaar, next generation), financé par la même boite, est un projet à plus long terme pour faire quelque chose qui "does not suck at all" (désolé pour l'anglais, mais j'avais trouvé les expressions assez représentatives -- dans un post d'Aaron Bentley si mes souvenirs sont bons).

        bazaar-ng est fortement inspiré de bazaar, et de son coté, bazaar intègre petit à petit les concepts de bazaar-ng (et se caractérise lui-même comme "seamless upgrade path to [WWW] bazaar-ng"). A terme, les formats d'archives seront compatibles.

      • [^] # Re: mercurial

        Posté par  . Évalué à 0.

        Aujourd'hui personne n'utilise encore bazaar-ng (pas plus que tla 2.0) et ce n'est pas un projet fini.

        Certes mais il est probable que bazaar-ng est amené à remplacer baz/tla. Et il est soutenu par Canonical, ce qui lui donne un certain potentiel.

        J'ai également du mal à voir en quoi le fait que bazaar-ng et mercurial soient écrits en python constitue un avantage.

        1) Ca évite des tas des bugs potentiels "bas niveau" liés à C/C+, et permet de se concentrer sur l'amélioration des algos. (par rapport à git, Subversion & co)
        2) C'est un langage connu et simple d'abord (contrairement à Haskell, le langage de darcs, par exemple)

        Bref, Python facilite la contribution et l'amélioration du projet.

        • [^] # Re: mercurial

          Posté par  . Évalué à 2.

          Vu le nombre de projets écrits en C/C++ je pense qu'on peut quand même espérer trouver des développeurs qui savent écrire correctement des programmes qui marchent, sont performants et bien écrits dans ces langages (et la gestion mémoire n'y est pas si dramatique et a même ses avantages, ne nous lançons pas dans un bas troll garbage collector).

          Le fait qu'un projet soit codé dans un langage "simple d'abord" n'est pas une avancée en soit, car il est tout de même assez rare que les gens qui apprennent un langage, python, parce qu'il est simple d'abord écrivent le code aussi bien que ceux qui ont l'habitude du C, par exemple.

          Enfin, Tom Lord a réussi à écrire ce qui est pour moi le meilleur SCM du moment sans être financé ni soutenu par une grande équipe de développement (qu'il l'ait refusée ou non), donc le soutien par Canonical, ça m'est quand même relativement égal.

          • [^] # Re: mercurial

            Posté par  . Évalué à 2.

            Le fait qu'un projet soit codé dans un langage "simple d'abord" n'est pas une avancée en soit, car il est tout de même assez rare que les gens qui apprennent un langage, python, parce qu'il est simple d'abord écrivent le code aussi bien que ceux qui ont l'habitude du C, par exemple.

            Non mais des tas de gens apprennent Python alors qu'ils savent *dejà* programmer correctement (y compris en C, assembleur...) et ils se sentent beaucoup plus productifs une fois débarrassés des tâches routinières que l'on passe son temps à refaire en C.

            (la même remarque serait valable à peu de choses près pour Ruby et d'autres langages du même niveau)

  • # Précisions ...

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

    > Pour ma part, je pense que Tom Lord a été un frein pour le projet.

    s/Pour ma part, je pense que //

    > L'objectif de bazaar était de refondre l'UI

    s/L'objectif/Le pretexte/

    ;-).

    En fait, Canonical était dans une situation un peu délicate : Le but final était de faire évoluer GNU Arch, sachant que Tom refusait la plupart des patchs. Ils voulaient AMA éviter un fork agressif, et ont donc appelé ça une "branche" à la place d'un fork. N'empêche qu'un des premiers changements introduits par bazaar, c'est un changement du format d'archive, qui n'est pas franchement une question d'interface utilisateur.

    Pour ce qui est d'éviter le fork agressif, c'est raté:

    http://article.gmane.org/gmane.comp.version-control.arch.devel/1502(...)

    Bon, en tous cas, si il y avait encore des utilisateurs de tla, maintenant, vous n'avez plus d'excuses pour ne pas tester bazaar, c'est vraiment bien. Encore pleins de bonnes choses en préparation pour la future 1.5 !

    • [^] # Re: Précisions ...

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

      >s/Pour ma part, je pense que //

      J'avais pas osé.

    • [^] # Re: Précisions ...

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

      Bon, en tous cas, si il y avait encore des utilisateurs de tla, maintenant, vous n'avez plus d'excuses pour ne pas tester bazaar, c'est vraiment bien. Encore pleins de bonnes choses en préparation pour la future 1.5 !


      Il y a un truc que je n'ai toujours pas compris : est-ce qu'il faut convertir les archives ? Il me semble que non, mais je n'ai rien trouvé sur le wiki l'indiquant clairement. Est-ce que le fait d'utiliser bazaar empêche les autres d'utiliser tla ?

      • [^] # Re: Précisions ...

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

        bazaar sait utiliser les archives tla. Si tu as une archive tla, tu n'as rien a faire pour utiliser bazaar.

        bazaar sait créer des archives au format tla, c'est une option de make-archive.

        tla sait aussi utiliser et créer des archives au format bazaar depuis la version 1.3.2 ou quelque chose comme ça. Tom ne pensait pas en faire le format d'archive par défaut, mais il s'est gouré en appliquant le patch, et c'est donc le format par défaut maintenant.

        Bref, le changement de format d'archive n'est doublement pas un problème.

        • [^] # Re: Précisions ...

          Posté par  . Évalué à 3.

          Tom ne pensait pas en faire le format d'archive par défaut, mais il s'est gouré en appliquant le patch, et c'est donc le format par défaut maintenant.

          Mouarf. Il a l'air en effet assez spécial, ce Tom Lord :))

          • [^] # Re: Précisions ...

            Posté par  . Évalué à 3.

            C'est à cause de l'interface utilisateur déplorable de tla, ce n'est que justice. ;-)

  • # C'est rassurant

    Posté par  . Évalué à 2.

    La page de Tom Lord sur le futur de tla, m'avait fait peur .... Inventer un nouveau langage pour tla me semble délirant. Je trouve dommage que des projets innovant comme tla soit handicapé par des choix peu judicieux, comme ses conventions douteuse sur les noms de fichier, l'absence de gettext. Au moins, avec Python il ne vont pas perdre leurs temps à reprogrammé une classe String.

  • # l'UI ? quelle UI ?

    Posté par  . Évalué à 1.

    Heuh petite question on parle de quelle UI là ? Parce que je serai assez preneur d'une UI simple à tla qui me permettrait de voir quel fichier à changé (tla changes), de pouvoir tracker la révision d'un fichier (??) et faire des diffs par rapport aux révisions précédentes par exemple.

    J'ai essayé octopus qui est très bien, mais sauf si j'ai loupé quelque chose, ça ne permet que de visualiser les patchset. Il y a un autre projet en GTK (archway ?) que j'avais essayé, mais j'avais trouvé qu'au niveau ergonomie c'était pas vraiment ça...

    Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs qui marcherait au dessus d'un back end (cvs, subersion, tla, git, ...)
    L'idée serait de faire l'interface d'un rcs ultime avec des capabilities (est-ce que tu supportes telle opération) et ensuite de montrer une vue du projet en utilisant l'implémentation du vrai rcs.

    A+

    David

    • [^] # Re: l'UI ? quelle UI ?

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

      >Heuh petite question on parle de quelle UI là ?

      L'UI ligne de commande de arch/tla.

      • [^] # Re: l'UI ? quelle UI ?

        Posté par  . Évalué à 0.

        C'est bien ce qu'il me semblait, nous parlons donc d'un CLI ! :-)

        • [^] # Re: l'UI ? quelle UI ?

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

          UI = User Interface.

          C'est pas parce que c'est en ligne de commande que c'est pas destiné aux utilisateurs. Une interface graphique, c'est une GUI.

          • [^] # Re: l'UI ? quelle UI ?

            Posté par  . Évalué à 1.

            C'est exact, mea culpa ! :-) Je fais trop vite l'amalgame UI=GUI. Arretons les amalgames !

    • [^] # Re: l'UI ? quelle UI ?

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

      > je serai assez preneur d'une UI simple à tla

      < pub >
      Si tu n'es pas alergique à Emacs, il y a Xtla ( http://wiki.gnuarch.org/xtla(...) ).
      < /pub >

      Sinon, en mode texte, bazaar 1.5 aura une option --modifying FILE pour tracker l'historique d'un fichier, et fai permet de faire pas mal de choses aussi.

      > Sinon si ça interesse du monde j'aimerai commencer un projet d'UI générique à un système de rcs

      Dans Emacs, il y a un truc qui ressemble à ça: VC. Mais ça ne permet pas grand chose.

      • [^] # Re: l'UI ? quelle UI ?

        Posté par  . Évalué à 1.

        Et bien justement si, je suis assez allergique à emacs (je suis plutot vi !) :-) (tout ca pour reprendre un bon vieux troll)
        J'ai jamais pu me faire à emacs, c'est certainement bien dommage, et oui, je savais que tu t'occupais de xtla (j'avais lu l'annonce ici meme de la 1.0 et j'avais retenu ton pseudo) :-)

        J'aime beaucoup WinCVS pour sa vue à plat, ses filtres, sa possibilité de faire un graphe des révisions pour un fichier et de voir ses diffs. Il y a un outil web (proprio malheureusement) qui permet meme de reconstuire la liste des patchset et d'avoir une vue un peu plus moderne. Je pense donc sérieusement qu'on peut faire quelque chose de sympa.
        Les commandes de base seraient :
        - checkout (tla get)
        - lister les changements (tla changes)
        - faire un diff par rapport à n'importe quel autre révision (tla file-diff étendu ?) au sein d'une branche ou de plusieurs branches
        - lister toutes les révisions d'un fichier (??)
        - comitter un fichier ou un ensemble de fichiers (tla commit --)
        - avoir une vue par patch (ce que fait octopy)
        - avoir des commandes pour faire des move et des delete
        - avoir une commande pour faire un undo/redo (tla undo, tla redo, simulable en cvs)
        - ...

        Bref, cette interface "ultime" peut être assez simple au départ, mais permettre dans un premier temps d'avoir une vue d'un projet cvs/subversion/tla sympa avec des vues synthétiques pertinentes.

        Les opérations en ecriture pourraient être envisagées dans un deuxième temps.

  • # Tant qu'on parle de GNU Arch ...

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

    http://bazaar.canonical.com/BzrFAQ(...)
    As of August 2005 Canonical has decided to focus our ongoing efforts on the Python Bazaar-NG codebase. We're switching our efforts, and our internal projects, onto Bazaar-NG in late 2005. For the moment Bazaar is still the more mature and stable codebase, but that's changing.

Suivre le flux des commentaires

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