El Titi a écrit 3948 commentaires

  • [^] # Re: encore une bonne aubaine...

    Posté par  . En réponse à la dépêche Connaissez-vous les bitcoins ?. Évalué à 2.

  • [^] # Re: Nouveautés ???

    Posté par  . En réponse à la dépêche Papyrus nouveau est arrivé. Évalué à 5.

    Au fait, le "changement de technologie" correspond-t'il au passage sous uml2/emf d'eclipse plutôt qu'une surcouche adaptée de gmf ?
  • # Nouveautés ???

    Posté par  . En réponse à la dépêche Papyrus nouveau est arrivé. Évalué à 7.

    Je ne voudrais pas paraître désobligeant, mais j'aurais apprécié quelquechose de plus étoffé pour présenter le projet.

    Je ne vois aucune release notes qui nous présente les nouveautés depuis que le projet a intégré Eclipse. Et même en cherchant sur le site je n'ai pas trouvé.
    La présentation ne fonctionne pas
    http://www.slideshare.net/rfaudou/papyrus-eclipse-con-2010-v(...)

    J'aurais également apprécié quelque nouvelles sur le statut du projet (Il était question d'un merge avec Topcased un temps, je crois)
    Un sybillyn "Papyrus représente un projet très actif." me laisse un peu sur ma faim.

    Qu'en est-il de la modélisation en équipe (fragmentation, merge de modèles, ...) qui me parait essentielle pour pratiquer "l'ingénierie des modèles" autrement que seul dans son labo ?

    Bref, ca plus les références aux outils de transfo, ca me laisse un léger goût de publi-reportage dans la bouche.
  • [^] # Re: rahhhh

    Posté par  . En réponse à la dépêche gcp: un outil de copie à la cp. Évalué à 2.

    Oui, vaut mieux tirer avec la Rigaux qu'avec la grosse Bertha.
  • [^] # Re: rahhhh

    Posté par  . En réponse à la dépêche gcp: un outil de copie à la cp. Évalué à 10.


    Franchement, y a des claques qui se perdent.


    Je ne te le fais pas dire.
    Le gars, il publie un hack dans un journal pour en faire profiter tout le monde alors qu'il a fait ca pour lui, il utilise ce qu'il connaît, qu'il affectionne et qui va à l'essentiel.
    Il donne un peu de son temps pour produire un truc qui marche.
    On l'encourage à poster une news parce que ca serait sympa.

    Et là évidemment y'a des bozos qui débarquent pour le tâcler en lui disant qu'il faut qu'il refasse tout ça en assembleur parce que voilà Python c'est naze. Et pis faudrait qu'il fasse ca à plein temps et gratos en plus (libre pardon, mais je suis sûr que tu vas te précipiter sur Paypal une fois qu'il a aura tout réécrit) parce qu'un hack comme ca c'est une injure aux utilisateurs rois de DLFP.

    Alors oui y'a des claques qui se perdent
    Et là, j'ai envie de dire t'as qu'à sortir tes petits doigts boudinés et le faire toi-même le fork en C, le code est en GPL.
  • [^] # Re: Sympa, mais...

    Posté par  . En réponse à la dépêche Faire part de naissance de LibreOffice. Évalué à 7.

    Eviv Bulgroz !
  • [^] # Re: Espoir.

    Posté par  . En réponse à la dépêche Faire part de naissance de LibreOffice. Évalué à 10.

    J'en ai les mains toutes mouettes.
  • [^] # Re: Et sinon

    Posté par  . En réponse au journal gcp: un outil de copie à la cp. Évalué à 1.

    Ouais, la GPL c'est nul. Vive la LGPL !
  • [^] # Re: LibreOffice vaincra !

    Posté par  . En réponse à la dépêche Faire part de naissance de LibreOffice. Évalué à 4.

    Bonne question, je me demandais comment il était si simple de forker un projet lorsqu'on ne détient pas le copyright.

    Avec Linux le passage GPLv2 vers v3 est impossible car il faut que tous les auteurs soient d'accord.
    Si le projet passe en GPLv3, on retombe dans le même pb, si on refuse une cession de copyright à une unique entité. Tout passage à une autre licence ou version devient compliqué.

    Est-ce qu'avec une LGPL on fait ce qu'on veut ? (A priori c'est l'intérêt de cette licence)

    Un spécialiste es licences pour corriger ?
  • [^] # Re: rsync

    Posté par  . En réponse au journal gcp: un outil de copie à la cp. Évalué à 3.

    Je crois que l'idée est de faire des petits utilitaires simples et de les proposer à qui veut bien.

    Parcher rsync ca nécessite de se mettre au C, de s'impliquer dans un projet qui n'a pas la même vocation (par ex le renommage de fichiers pour éviter l'écrasement n'est pas trivial en utilisant un outil de synchro)
    Sinon, faire un backend à un programme qui ne propose pas d'API n'est pas forcément du goût de tout le monde (pas du mien en tout cas)
    http://www.mail-archive.com/rsync@lists.samba.org/msg18288.h(...)
  • [^] # Re: Python ?

    Posté par  . En réponse au journal gcp: un outil de copie à la cp. Évalué à 3.

    Est-ce que tu as moyen de détecter simplement que 2 partitions ne sont pas sur le même disque ?
    Parce que sinon ton optimisation ne marche pas toujours.
  • [^] # Re: Dépêche

    Posté par  . En réponse au journal gcp: un outil de copie à la cp. Évalué à 7.

    Ultracopier ayant eu son heure de gloire sur DLFP:
    http://linuxfr.org//2010/01/24/26384.html

    ca parait être une bonne idée.

    Et pour vous mâcher le travail

    j'ai «profité» de la perte de ma boîte de vitesse et de me retrouver coincé à Broome (Nord-Ouest de l'Australie... mais ne vous inquiétez pas, je
    ...
    Mais à noter que je ne pourrai pas bosser dessus avant au moins 2 mois.
    Et je finis avec un petit lien vers mes autres projets en cours:
    -lm (list movies): dont j'ai parlé ici: https://linuxfr.org/~Goffi/29966.html , et ...

    Un journal soigné et du bon boulot en tout cas.

    Ca serait pas mal de créer une catégorie "coup de coeur" pour les petits projets qui se lancent.
  • # Typos &Co

    Posté par  . En réponse à la dépêche Sortie de la bêta de Fedora 14 Laughlin. Évalué à 2.


    https://bugzilla.redhat.com">notre système de suivi d'anomalies.

    avec comme url
    https://linuxfr.org/submit/%3Ca%20href=



    et mêmes les plus ancienne

    même est un adverbe ici
    http://francite.net/education/cyberprof/page111.html



    les bindings Python développés par Nokia sous licence LGPL. L'environnement GNUStep est également introduit.
  • [^] # Re: Et la phrase historique de Dati

    Posté par  . En réponse au journal Les journalistes et les chiffres. Évalué à 1.

    Autres temps, autres moeurs.

    Dans une autre vie, les lapsus te servaient visiblement d'argumentaire:
    http://linuxfr.org/comments/822108.html#822108
    http://linuxfr.org/~euroxers/23509.html
  • [^] # Re: Et la phrase historique de Dati

    Posté par  . En réponse au journal Les journalistes et les chiffres. Évalué à 3.

    En même temps elle est excusable, l'inflation aussi fait gonfler ... les prix.
  • [^] # Re: Et la phrase historique de Dati

    Posté par  . En réponse au journal Les journalistes et les chiffres. Évalué à 2.

  • [^] # Re: La montagne, ça vous perd

    Posté par  . En réponse à la dépêche syj: site de partage d'itinéraire. Évalué à 4.

    Oui, quand est-ce qu'on pourra utiliser librement les données qui ont été collectées grâce à nos impôts ?
  • [^] # Re: Bonne idée

    Posté par  . En réponse à la dépêche syj: site de partage d'itinéraire. Évalué à 4.

    C'est balo, hein ?
    Non, mais c'est ballot
    http://fr.wiktionary.org/wiki/c%E2%80%99est_ballot
  • [^] # Re: staging area

    Posté par  . En réponse au journal Git malgré moi. Évalué à 2.

    Simplement parce que le branching avec SVN est bloated. Une usine à gaz a été créé pour pallier les défauts d'architecture que j'ai exposé un peu plus loin.
    Cette belle idée au départ de pouvoir brancher à plat directement dans l'arborescence couplée avec cette notion de révisions qui simule des "liens symboliques" et qui pointe que sur les fichiers modifiés depuis la dernière révision était séduisante. (branche et tags en O(n)). L'équipe SVN s'était dit qu'ils s'occuperaient des branches plus tard (mémoire de merge, rename tracking, pas de merge cycliques, ... par exemple) et dans les faits c'est tout qui est à revoir. (pour le rename tracking il faut des identifiants d'objet alors qu'on a que des révsions ou un DAG+notion de branche pour être efficace). Leur modèle se complique (mergeinfo qu'il faut supprimer à la main, révisions à indiquer explicitement parce la mémoire de merge est défaillante, option reintegrate pour traiter les branches de patch, ...) Ils sont dans une impasse ... Ca explique pourquoi on trouve ca dans la section advanced.

    http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)

    Du coup on conseille de bosser dans une branche et on promeut l'intégration continue puisqu'on ne sait traiter que ça.
  • [^] # Re: staging area

    Posté par  . En réponse au journal Git malgré moi. Évalué à 3.

    Désolé, j'ai rien compris à ce que tu voulais expliquer.
  • [^] # Re: Les DVCS encouragent le travail collaboratif

    Posté par  . En réponse au journal Git malgré moi. Évalué à 3.


    L'outillage de merge plus puissant de git/hg & cie facilite encore la vie des développeurs.


    Je ne suis pas certain que la puissance des merges découle de la nature centralisée ou non des VCS.

    SVN ne gère pas les merges correctement simplement parce qu'il ne sait pas faire la différence entre une branche et une recopie ce qui mène à plein de cas tordus.
    Ajoute à ca que le stockage correspond à une séquence linéaire de révisions. Pour un merge, ceci oblige à parcourir toutes les révisions une par une même celles qui ne concernent pas les fichiers des arbos à merger.

    Clearcase ou Perforce, bien que centralisés, prennent très bien en charge les merges même si le stockage s'effectue au niveau des répertoires et des fichiers. Ce sont des objets avec un identifiant et un historique unique. Les merge 3 ways sont sûrs et les merge d'arborescences sont relativement aussi même s'ils sont bien plus lents car il necessite de descndre recursivement dans l'arboresence et de traiter les fichiers/répertoires un par un.

    La puissance des DVCS type git, hg ou monotone vient du fait qu'ils stockent les révisions qui se succèdent ou qui forkent sous forme de graphes (DAGs) et que les branches sont des objets de première classe. Il est donc aisé de déterminer quelles révisions sont concernées par un merge.
    Cette évolution est intervenue plus tard dans l'histoire des VCS, mais on pourrait très bien imaginer qu'un nouvel outil centralisé adopte une architecture identique. Seulement, à quoi servirait de créer un nouveau VCS centralisé sur cette base alors que les DVCS sont supérieurs sur tant d'autres aspects et qu'ils proposent toutes les fonctionnalités des VCS (à l'exception du verrou pessimiste).
  • [^] # Re: Git malgré moi

    Posté par  . En réponse au journal Git malgré moi. Évalué à 1.

    Pour en remettre une couche sur le rename tracking voici une description
    du problème:
    http://subversion.tigris.org/issues/show_bug.cgi?id=898

    Etant donné que SVN utilise svn cp pour brancher et ne fait sémantiquement pas la différence entre une branche et une simple copie d'arbo ce problème n'est pas près d'être résolu. Les branches sont des objets à part entières dans Git

    Quelque commentaires:



    """
    Moving to 1.4, since, while cmpilato has started this work on the fs-atomic-
    renames branch, it won't be merged before 1.3.
    ...
    Post-1.6 issue sweep. Since 1.7 is already shaping up to be a large release,
    move to 1.8-consider.
    ...
    Seems like this thing is going to be pushed out indefinitely.
    """


    Ce bug a été ouvert en 2002 et il est reporté aux calendes grecques.
    Nous en sommes à la 1.6.12.
    Bonne chance les gars
  • [^] # Re: staging area

    Posté par  . En réponse au journal Git malgré moi. Évalué à 2.

    Je ne suis pas sûr de bien comprendre, mais connais-tu les changelists ?
    http://svnbook.red-bean.com/en/1.5/svn.advanced.changelists.(...)

    Ceci permet de regrouper les changements à commiter.
    Le mécanisme n'est pas aussi puissant que la mise en place de branches dédiées (inhérent aux DVCS) qui permet de commiter les changements de manière unitaire puis de reporter ceux que l'on souhaite sur le tronc (cherry-picking). D'ailleurs, si quelqu'un a déjà pu utiliser le cherry-picking correctement avec SVN, je suis preneur pour un retour d'expérience.
  • [^] # Re: Git malgré moi

    Posté par  . En réponse au journal Git malgré moi. Évalué à 3.

    J'ai l'impression que votre différence d'appréciation provient de votre perspective.
    Celle de rewind est technique alors que la tienne est plus d'ordre organisationnel.

    Je m'explique:
    Avec SVN, l'approche basique consiste à travailler dans une branche unique partagée.
    Comme il n'y a a pas de clone du dépôt, chaque développeur prend en charge une demande de changement, la réalise et la remet dès qu'elle est traitée.
    Au pire, il doit effectuer un merge avant de remettre mais il reste proche du développement principal.

    Avec un DVCS (Bazaar et svk exceptés car il supportent les 2 modes), chaque développeur dispose de sa propre branche et il n'est pas possible de bosser sur une branche partagée (Avec Git et Hg, il me semble qu'il existe des mécanismes qui permettent de commiter et pusher dans la même transaction en contactant le dépôt principal mais ce n'est pas le workflow de base).
    En revanche, il est naturel de prendre en charge plusieurs demandes à la suite et de le commiter dans sa propre branche en local sans être obligé de les reporter directement sur la branche principale.
    De ce fait, puisque plusieurs changesets peuvent s'enchaîner sans réel besoin de les reporter sur le tronc, le développeur peut être tenté de s'isoler, ce qui occasionnera inévitablement un travail plus important à moment de l'intégration.

    Pour appliquer cette stratégie avec SVN, il est nécessaire de créer explicitement une branche par développeur. Mais ceci n'est pas automatique et surtout, le fait que SVN ne supporte pas le rename tracking décourage fortement cette pratique dès qu'on fait un peu de refactoring (renommage de package par exemple). Le merge n'est pas automatique et il faut relancer le refactoring à la main dans la branche principale.

    En revanche, d'un point de vue organisationnel les DVCS sont plus ouverts aux contributions en ce sens qu'ils n'obligent pas à se faire reconnaitre pour participer sur un projet.
    Avec SVN, il faut accorder des droits en écriture sur le repository pour accueillir de nouveaux participants (hormis l'échange de diff/patch qui contourne le VCS) . Cet accès permet au contributeur d'accéder directement à la branche principale avec les risques qui s'ensuivent et un accès limité à une branche dédiée est plus complexe à mettre en oeuvre.
    Avec un DVCS il suffit de cloner le repository et on peut commencer à bosser dans sa propre branche. Les développeurs du projet n'ont qu'à puller les changements dans leur propre dépôt local, merger les patchs qui les intéressent et remonter dans le dépôt principal sans besoin d'octroyer de droits sur ce dépôt. Ce n'est que lorsque le contributeur a fait ses preuves qu'il obtient ce privilège de pusher directement sur le dépôt central.

    Ce workflow est plus complexe mais plus souple.
    C'est la raison pour laquelle je considère que les DVCS se prêtent mieux aux projets communautaires alors que SVN de par sa simplicité et sa gestion centralisée des droits se prête mieux au monde l'entreprise.

    Voilà je crains avoir encore plus délayé que toi.
  • [^] # Re: Mon ressentit

    Posté par  . En réponse au journal Git malgré moi. Évalué à 4.


    Ça permet de savoir qui fait quoi, qui bosse sur quoi, qui va faire de grosses modifs, etc.

    Ce n'est pas le rôle du VCS mais du bugtracker ou de la forge de faciliter cette communication.
    S'il est centralisé, on sait qui a pris quoi, à quoi est dédiée telle branche.

    J'entends souvent l'objection que tu évoques à savoir ce risque d'isolation qui fait que SVN colle si bien à l'intégration continue i.e à l'usage d'un branche unique.

    Et pourtant la CI n'est pas l'apanage des outils centralisés.
    Je te conseille cet excellent papier de Martin Fowler sur le sujet
    http://martinfowler.com/bliki/FeatureBranch.html

    En revanche, ce qui est sûr c'est qu'un outil comme SVN qui est incapable de supporter le "rename tracking" correctement (renommer un fichier différemment entre 2 branches perd l'historique de ce fichier lors du prochain merge entre ces 2 branches) ne peut supporter que l'integration continue et les branching par patch (une branche par patch que l'on tue une foi integrée).
    Pas de salut pour les autres branching patterns (1 branche par developpeur , une par lot de fonctionnalité en vue d'un développement parallèle de plusieurs équipes avec une phase d'intégration avant la livraison, ...)

    De là à dire que la mode de la CI n'existe que parce que SVN est déficient à la base, il n'y a qu'un pas.