Journal Quelques nouvelles de KDE

Posté par .
Tags : aucun
20
22
juil.
2009
Puisque je n'ai pas vu de journal ou de dépêche en parlant, voici quelques nouvelles rapides concernant KDE :

  • La millionième révision dans le SVN a été faite le 20 juillet, un grand bravo à tout le monde ainsi qu'à Kévin Ottens http://lists.kde.org/?l=kde-commits&m=124811211002267&w=2, son auteur. Tout le monde attend maintenant avec impatience la 2²⁰è révision.
  • Il a été décidé lors du Gran Canaria Desktop Summit de migrer KDE vers git, SVN qui a rendu de fiers services ces dernières années n'étant plus assez souple pour le développement actuel de KDE. Afin de débroussailler le terrain, Amarok vient d'effectuer sa migration et se trouve maintenant chez gitorious : http://gitorious.org/amarok/
  • Devant le nombre important de changements depuis la RC2, les développeurs ont préféré faire une RC3, retardant la sortie finale d'une semaine.
  • # Migration SVN vers GIT : l'expérience Gnome

    Posté par (page perso) . Évalué à 7.

    Lors des RMLL 2009, Frédéric Peters a fait un retour sur la terrible expérience de Gnome de migration SVN vers GIT.
    Je vous laisse découvrir cette grande tranche de rigolade...
    http://2009.rmll.info/Migration-a-Git-du-projet-GNOME.html
    • [^] # Re: Migration SVN vers GIT : l'expérience Gnome

      Posté par (page perso) . Évalué à 3.

      Ce qui m'étonne c'est que KDE utilisait SVN depuis quand même assez peu d'années. je me souviens encore d'une petite news que j'avais rédigé au moment de l'annonce de la fin de la migration vers SVN => https://linuxfr.org//2005/05/11/18915.html et c'était il y a à peine 4 ans.
      Si ils se tapent une grosse migration de tout leur source et de tout leur historique tous les 4 ans c'est que la planification à long terme n'a pas été super efficace je pense.
    • [^] # Re: Migration SVN vers GIT : l'expérience Gnome

      Posté par (page perso) . Évalué à 4.

      Content que tu te sois bien amusé, moi aussi :)

      Mais bien que j'aie (un peu) chargé la barque, il ne faudrait pas qu'on retienne juste que ça a été terrible; en fin de compte, aujourd'hui, Git fonctionne pour GNOME aussi bien que Subversion fonctionnait il y a six mois (et le nombre de personnes commitant des « fuck git » ne doit pas être plus élevé que les « fuck svn » d'antan).

      Sinon c'était le matin, juste après le repas du libre, et je me servirai de cette excuse.

      Enfin, et je dois en avoir touché un mot sur la fin de la conférence, le projet KDE a son dépôt Subversion structuré de manière bien différente (un seul énorme dépôt), ce qui pourrait rendre la migration un peu plus bousculante.
    • [^] # Re: Migration SVN vers GIT : l'expérience Gnome

      Posté par . Évalué à 3.

      Sincérement je trouve cette présentation assez biaisée contre git :

      Le début commence par sous entendre qu'il faut apprendre les entrailles de git pour pouvoir l'utiliser, on doit faire pareille avec cvs,svn, ... ? Il me semble que non et dans tous les cas c'est faut pour git.

      La partie sur la transition difficile de git à svn est malhonnête intellectuellement, sincérement une telle migration ne peux se passer sans problèmes c'est une évidence...

      Slide 38->39: allez hop on raille des qualités de git sans justifier ! Oui avec git everythings is local, any work flow et je trouve (personnellement) easy to learn

      Il est possible de ne télécharger qu'un seul fichier d'un module (à traver l'interface web par exemple).

      Slide 43: Il est parfaitement possible de cloner uniquement le module qui l'intéresse

      Et le summum du manque d'objectivité c'est qu'il n'y a que des témoignages relatant les mésaventures de certains suite à la migration. Oui il faut prendre ses marques, trouver les nouvelles url pour cloner et lire 2-3 tutoriaux sur git. J'ai personnellement eu des discussions avec des développeurs gnome qui étaient content d'être passé à git, il n'y a donc pas que des mécontents.

      Voilà je suis juste triste du manque d'objectivité et des critiques infondées, les techniques et effet de manches de nos chers|chère amis politiciens semblent devenir à la mode.

      Celà étant dis git ne plaira pas forcément à tout le monde mais d'un point de vu technique j'ai assisté à assez de discussion avec des personnes autrement plus compétentes que moi pour être convaincu des qualités techniques de git.
      • [^] # Re: Migration SVN vers GIT : l'expérience Gnome

        Posté par . Évalué à 4.

        Lors du Gran Canaria Desktop Summit, les développeurs de KDE ont justement discuté avec ceux de GNOME concernant git. Il ne faut pas croire qu'ils se lancent là-dedans à la légère. C'est d'ailleurs pour ça qu'Amarok joue le rôle d'avant-garde, pour trouver les problèmes et les résoudre avant toute migration massive (une petite liste des choses à faire/résoudre a été commencée http://techbase.kde.org/Projects/MovetoGit ).
        Autre chose à voir aussi, Qt est depuis quelques semaines sur gitorious, du coup certains développeurs s'y sont mis et ont trouvé ça suffisamment convaincant pour envisager une migration, une fois les problèmes résolus. Ils travaillent aussi d'arrache-pied avec gitorious afin de combler les manques ( http://techbase.kde.org/Projects/GitoriousKDE ).
      • [^] # Re: Migration SVN vers GIT : l'expérience Gnome

        Posté par (page perso) . Évalué à 1.


        Sincérement je trouve cette présentation assez biaisée contre git :


        Avant tout les slides ne sont qu'un support, qui n'a guère de valeur hors de la conférence.

        Mais oui, toutes les discussions étaient biaisées, y aller franco permet au moins de ne laisser aucun doute là-dessus, de ne pas être par après accusé d'être dans un cas particulier.

        Aussi, la conférence présente un point vue, assumé subjectif, et de manière appuyée, sur la migration (à laquelle j'ai participé avec pas mal de code, pas mal de suivi, et pas mal de renseignements offerts aux égarés).

        Un des trucs qui peut en ressortir, après une petite heure où les gens ne se sont pas ennuyés, c'est qu'une migration, ça ne s'improvise pas, et qu'il y aura de toute façon des impairs.
  • # Pertinence de Git

    Posté par (page perso) . Évalué à 1.

    Personnellement, je ne suis que très peu convaincu par l'argument du "svn pas assez souple". Je pense juste que les (certains) développeurs KDE sont séduits par les possibilités de Git et qu'ils n'ont pas envie de continuer avec SVN, mais je ne vois pas en quoi subversion ne serait soudainement plus assez souple. Un besoin soudain de faire des tonnes de branches locales à tout va ? Tous les développeurs KDE ont maintenant besoin de bosser dans le train ? :)
    Bref, à mon humble avis (mais je peux me tromper), ils se font juste plaisir...
    • [^] # Re: Pertinence de Git

      Posté par (page perso) . Évalué à 10.

      Bref, à mon humble avis (mais je peux me tromper), ils se font juste plaisir...

      C'est pas le but de contribuer à du logiciel libre, se faire plaisir ? :)
    • [^] # Re: Pertinence de Git

      Posté par (page perso) . Évalué à -2.

      J'avais lu je ne sais plus où que Git était le gestionnaire de source dont l'algorithme qui calculait les différences entre les fichiers prenait le plus de place sur le DD.
      KDE représente plusieurs millions de lignes de codes, ça ne vas pas poser problèmes au bout d'un moment? (voire même la migration vers un autre DVCS? :p)
  • # KDE est trop gros pour le DVCS

    Posté par (page perso) . Évalué à -2.

    Bonjour,

    Un problème relevé dans le PDF donné dans le premier commentaire, tout à la fin du document : avec Git (et aussi bazaar, je ne sais pas pour les autres), on est obligé de tout télécharger, même pour modifier le moindre fichier.

    Pour moi, il est totalement idiot et débile d'utiliser un DCVS pour autre chose qu'un bête éditeur de texte, car je ne veux absolument pas devoir DL tout KDE en toutes ses versions pour modifier un fichier !

    C'est là un gros problème du DVCS, qui n'est pas pris en compte par les américains/français/autres qui ont de bonnes connexions, mais moi par exemple, je suis limité à 1Gio maxi par mois (en belgique, offre light, mais déjà assez chère), et si je dépasse, ça coûte la peau des fesses.

    J'ai téléchargé Launchpad qui utilise Bazaar, et je vois que je ne me trompe pas : le code source fait un peu plus de 100Mio, j'ai eu 350Mio à télécharger !

    Pour KDE, si j'ai besoin des kdelibs et de kdebase, je n'ai pas envie d'avoir tous les artworks, les autres applications, l'i18n de toutes les langues et autre. Je n'ai pas envie de récupérer plusieurs dizaines de Go pour recompiler ma version des kdelibs.

    J'espère qu'ils y pensent tout de même, avec leurs connexions à 20Mbps. Si KDE passe à Git sans garder SVN, je ne sais pas ce que je ferai, mais ce ne sera pas beau à voir :-° . Quelle est cette foutue mode pour les DVCS qui ne font qu'enrichir les FAI ? Un coup du gouvernement ?
    • [^] # Re: KDE est trop gros pour le DVCS

      Posté par . Évalué à 3.

      Ils vont certainement faire comme les autres gros projets utilisant git (je pense à xorg en particulier) : utiliser un répo par sous-projet.
    • [^] # Re: KDE est trop gros pour le DVCS

      Posté par . Évalué à 8.

      git clone --depth 1 devrait te plaire... :)
      • [^] # Re: KDE est trop gros pour le DVCS

        Posté par (page perso) . Évalué à 2.

        Je me disais justement qu'une fonction comme ça devrait être inventée ... ils l'ont fait.

        Magnifique, merci beaucoup. Dommage que ce ne soit pas activé par défaut (il me semble que plus de gens ont juste besoin de consulter la dernière version des sources plutôt que d'aller naviguer dans tout l'historique).

        Il reste néanmoins un détail qui me gène : je veux récupérer uniquement trunk/KDE/kdelibs/kdecore, comment je fais avec git ?
    • [^] # Re: KDE est trop gros pour le DVCS

      Posté par (page perso) . Évalué à 10.

      C'est sûr que le noyau linux pour lequel git à été conçu c'est un petit projet semblable à un éditeur de texte. :)

Suivre le flux des commentaires

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