Logiciel : Nouvelle version de Bazaar, le DVCS de Canonical
Posté par TeXitoi (Jabber id, page perso, ). Modéré le 20 mars 2008.
C'est la première version depuis que Bazaar est devenu un projet GNU le 26 février.
![[en]](../images/en.png)
Bazaar (709 hits)-
ChangeLog de la version 1.3 (190 hits)
-
Bazaar devient un projet GNU (206 hits)
> Lire la dépêche (54 commentaires, moyenne: 3,4).
Vous avez demandé le commentaire #915526.
Run by 
Cette page a été générée par Templeet en 0.1104s (dont 0.0091 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Emacs et bzr
A noter qu'Emacs est en train de migrer vers bzr.
http://thread.gmane.org/gmane.emacs.devel/90798/focus=91834
Et ça s'est un peu fighté sur les mailing-lists de Bazaar et Emacs à partir du moment où les gens ont comparé les performances de bzr avec celles de git (par exemple, "bzr log" met 1 minute avant de commencer à afficher le log sur une machine moderne).
Bon troll, c'est bientôt vendredi ;-).
[^]Re: Emacs et bzr
plus d'info sur http://lwn.net/Articles/272853/
Apparemment Bazaar a été choisi par rms car c'est un projet GNU, pas parce que c'est celui qui répond le mieux au cahier des charges...
[^]Re: Emacs et bzr
Je crois qu'il est temps de changer GNU/RMS par un bot plus performant.
http://linuxfr.org/board <-- des moules, du sang, de la violence
[^]Re: Emacs et bzr
Pour résumer ce qu'a dit RMS à ce sujet:
GNU est un projet d'un système d'exploitation libre et visant une certaine cohéance. Il est donc normal qu'un projet GNU choisisse des outils faisant partie du projet GNU, lorsque plusieurs alternatives libres et matures existent.
Le fait qu'au niveau des performances / de la popularité, bzr ne fasse pas course en tête ne doit pas influer sur le choix.
(d'ailleurs faire des comparaison exaustive des différents gestionnaires de version prendrait des semaines/années)
Cela doit au contraire pousser à adopter ce logiciel pour l'améliorer et le diffuser auprès des autres projets GNU.
pour citer RMS:
GNU is not just a label. GNU is an operating system project.
Therefore, it is our policy that GNU package maintainers
should support other GNU packages when there is a good
opportunity to do so.
This is our policy. You don't have to like it.
"ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time
[^]Re: Emacs et bzr
Faudrait insister un peu plus sur "project" hein... parce que bon pour le moment, c'est pas trop operating leur système...
(en plus sérieux, ça montre bien la différence entre Torvalds et autres Open Sources qui choisissent la solution sur des critères technologiques et RMS et autres GPL qui choisissent sur des critères politiques)
[+] [^]Re: Emacs et bzr
Oui en même temps, l'élitisme c'est sympa, mais c'est pas grâce à lui que les humains ont évolués (d'un point de vue physique autant que d'un point de vue moral).
Je rappelle que dans l'évolution naturelle c'est pas l'élitisme qui prime, et dans la société, l'élitisme a plutôt tendance à pourrir le monde qu'a l'améliorer.
Après nous sommes dans un sous monde (les logiciels "libres" dans le monde réel), donc c'est normal que ça pose moins de problème de faire de l'élitisme, mais je suis sur qu'à faire trop d'élitisme ça finit toujours mal (NON ! VOUS N'AUREZ PAS MON POINT GODWIN !)
[^]Re: Emacs et bzr
Je comprend pas trop ce laïus sur l'élitisme alors que le logiciel libre repose entièrement sur la philosophie hacker, ou la méritocratie gouverne.
Or si la méritocratie n'est pas un système élitiste, je mange mon chapeau.
[^]Re: Emacs et bzr
Ben, le système élitiste, c’est l’aristocratie : étymologiquement « gouvernement des meilleurs » en grec…
[^]Re: Emacs et bzr
Tu peux dire que la méritocratie est une aristocratie si ca te chante. Mais tu risques de ne pas être très bien compris. Le mot aristocratie a un peu dévié de son sens étymologique.
[^]Re: Emacs et bzr
Bon, faut que j’arrête avec les points de suspension, personne ne comprend qu’ils indiquent qu’il faut creuser. Alors je développe :
Or si la méritocratie n'est pas un système élitiste, je mange mon chapeau.
Qu’entend-t-on par méritocratie ? Que ceux qui le méritent sont ceux qui décident. Où est l’élite ? Dans la définition du mérite. Ici, ceux qui participent techniquement (dans le code) le plus, ou le mieux, ou depuis le début… C’est assez vague, hein. Enfin, bref, les « méritants » sont désignés (définis, déterminés, émergent, rétrospectivement justifiés…) par leurs capacités de codage. Donc, en résumant, l’élite des codeurs. Mouaif, ça « résume » à tout va mais on finit bien sur une prise de décision par une élite.
En français, un gouvernement par une élite, c’est une aristocratie. Alors, effectivement, le mot a plusieurs sens, notamment celui de désigner l’ensemble des aristocrates, la noblesse. En fait, c’est simplement que, à la base (Platon…), ceux qui forment l’élite dans une aristocratie, ce sont les « plus honnêtes » des citoyens. Ça a fini par faire une classe, les nobles, et on sait comment ça a fini en France : on leur coupe la tête et on en fait d’autres, tous les 50 ans… Pouf pouf, je m’égare.
Or donc, l’aristocratie, c’est une classe particulière, les « meilleurs », qui décide. Ça ne définit pas comment sont désignés les meilleurs.
Donc, oui, une « méritocratie » est un nouveau mot pour dire « aristocratie ». Un nouveau mot censé éloigner certaines connotations (à la lanterne !). Mais il n’empêche qu’il en a le sens et les inconvénients : créer une classe de dirigeants, créer des questionnements sur le mode de désignation des « meilleurs ».
C’était ça mon propos : oui, la méritocratie est un élitisme, et non, l’appeler méritocratie n’empêche pas tous les problèmes qui viennent avec un élitisme.
Remarquons que l’on peut aussi fouiller dans les autres formes de gouvernement et les comparer à cette méritocratie :
C’est aussi une forme d’oligarchie : ils ne sont pas nombreux.
C’est parfois une synarchie : ils se partagent les tâches.
Une gérontocratie : par les anciens (ont l’expérience).
Une dictature, une tyrannie ou une monarchie…
D’aucuns crieraient même parfois à la théocratie…
En tout cas, appliquée aux logiciels libres, c’est une technocratie : par les techniciens du domaine, pas par des gestionnaires qui ne connaissent rien au domaine.
Aïe, il y en a qui vont pas être contents, notamment les plus anarcho-communistes anti-mondialistes : on part d’un joli monde de bisounours où tout le monde est égal, puis certains sont « plus égaux que les autres », et on finit en, oh, quelle horreur, technocratie, vous savez, comme à Bruxelles…
[^]Re: Emacs et bzr
La différence de taille c'est que le programmeur méritocrate n'a de pouvoir que sur ce qu'il fait alors que l'aristocrate a un pouvoir sur ce qui ne le concerne pas.
En d'autres termes, il ne faut pas confondre avoir de l'autorité et être autoritaire...
En d'autres termes informatique ça veut dire que tu peux forker.
Pour ce qui est de l'égalité c'est pareil, il ne faut pas confondre les gens sont égaux et les gens ont des droits égaux quand bien même ils seraient différents...
Qu'on retrouve également dans les logiciels libres, chacun à également le droit d'utiliser un même logiciel suivant ces préférences et non celle du développeur.
L'anarchobizounours t'embrasse ;-)
[^]Re: Emacs et bzr
Pas vraiment, le fork en lui même ne donne aucun pouvoir dans un sens : essaye de forker Linux, tu auras du mal à avoir autant de pouvoir qu'un Torvalds ... sauf à avoir les épaules pour rerentrer dans le système, ou a déjà avoir le pouvoir d'un IBM ou d'un Microsoft ...
[^]Re: Emacs et bzr
Sauf qu'il n'y a pas que le fork :). Si c'est l'affaire de quelques patchs refusés, tu peux très bien les appliquer à la main, sans maintenir un fork complet.
C'est d'ailleurs ce que font certaines distributions.
[^]Re: Emacs et bzr
Heh bien je me suis un peu emmêlé les pinceaux dans mes idées il semblerait :]
Ce que je voulais faire ressortir, c'est que c'est pas parce que bzr n'est pas le *meilleur* à un moment donné qui faut le jeter (et RMS aussi :).
Mon avis est que si des gens (ici RMS) trouvent que bzr a des principes intéressant, alors ils peuvent l'adopter dans le projet GNU et l'ameliorer pour qu'il devienne le meilleur.
Et même si le logiciel libre repose sur la méritocratie, ça veut pas dire que :
1) ce sera toujours le cas
2) c'est la meilleur manière de faire
J'espère avoir mieux faire entendre mes idées :)
[^]Re: Emacs et bzr
Oui mais non :)
Tu as raison de dire que si bzr n'est pas la meilleur solution actuelle, rien n'empêche qu'elle pourra être améliorée. Mais en fait, si bzn peut être amélioré, c'est qu'il peut devenir meilleur, voire la meilleure solution entre git ou mercurial.
Donc on décale le problème en un choix de "qu'est ce qui est le mieux aujourd'hui" a qu'est ce qui est le mieux pour "aujourd'hui et demain". C'est une excellente approche, mais je ne suis pas sûr que ce soit l'idée qu'RMS a derrière la tête.
Tout ceci pour retourner le trucs en répondant que "Le logiciel libre repose sur la méritocratie, ça veut dire que :"
"1) ce sera toujours le cas" parce que le hacker ne supporte pas l'idée d'utiliser un outil moins bon que l'existant, donc soit il l'utilise soit il développe un équivalent - ce qui est déjà en train de se passer avec bzr, en passant.
"2) c'est la meilleure manière de faire" parce que selon le point 1, il n'y a pas d'alternative, c'est la seule manière de faire pour le vrai hacker :)
[^]Re: Emacs et bzr
Je rappelle que dans l'évolution naturelle c'est pas l'élitisme qui prime, et dans la société, l'élitisme a plutôt tendance à pourrir le monde qu'a l'améliorer.
Ouais, d'ailleurs, la démocratie a amené Sarkozy. Ça c'est un progrès intéressant \o/
[ Répondre ] Ce commentaire est-il impertinent ou utile ?
[^]Re: Emacs et bzr
pourquoi scinder le monde en deux ? C'est parce que c'est à la mode ? Torvalds comme tu dis est plutôt "Open Source", ça ne l'a pas empêché de mettre Linux sous GPL. Et je suis persuadé qu'en cherchant un peu, on peut trouver l'inverse.
On peut très bien choisir la GPL et des critères technologiques ou alors la BSD et les critères politiques (les entreprises le font par exemple, elles choisissent des logiciels BSD quand ça les arrange même si ce n'est pas techniquement le meilleur logiciel derrière).
[^]Re: Emacs et bzr
(petite perte de mon commentaire suite à une erreur mysql...)
En gros j'ai pris Torvalds et RMS pour imager simplement ma pensée. Evidemment tout ne peut pas se résumer en 2 groupes, mais ça indique tout de même deux modes de pensés différents.
En fait j'aurais du opposer libre selon l'Open Source et libre selon la FSF, ça serait peut-être plus correct (non pas dans la définition du libre, mais dans les buts de cette liberté et leurs critères)
Ce que je trouve idiot c'est que bzr soit choisit pour sur des critères politiques alors que des solutions _tout autant libre_ existent et semblent plus efficaces.
[^]Re: Emacs et bzr
Bof, je trouve pas ça idiot.
Si tu lis l'article sur LWN, le résumé c'est :
1) il faut choisir un DVCS libre pour continuer le développement d'Emacs.
2) il y a trois choix possibles en gros : bzr, git, mercurial.
3) au départ, une étude doit être faite, mais le gars qui doit s'en charger est pris, et une étude ça prend du temps.
4) RMS prédit le résultat de l'étude : chacun a des avantages et des inconvénients. Tel dvcs est mieux pour ça, tel autre pour ça, etc. Au final, il y aura toujours un petit groupe pour défendre son logiciel favori. En gros, le consensus est impossible à obtenir ou va demander un temps fou. Et surtout, les 3 permettront de développer Emacs sereinement.
5) Plutôt que de troller techniquement pendant des semaines, bzr est choisi grâce au critère politique.
[^]Re: Emacs et bzr
D'autant plus que choisir bzr, git ou hg n'est pas non plus un choix grave, car ils ont tout trois un jeu de plugins qui s'enrichit de jour en jour et des models compatibles ce qui laisse penser que dans le futur on aura une interoperabilité totale entre les trois et que chaque développeur pourra choisir l'outil qui lui plait le mieux sans que ca gene les autres.
[^]Re: Emacs et bzr
L'article de LWN ne reflète pas l'ambiance de la ML. Stallman n'écoute pas l'opinion des développeurs et choisi pour eux l'outil qu'ils devront utiliser. Certains sont vraiment vexés, car cette procédure donne l'impression qu'on est juste une force de travail pour un projet qu'on ne maîtrise pas un brin. Donc,
1) ok; 2) y'a Darcs en haskell aussi; 3) l'étude a déjà été faite pour d'autres projets similaires, les fonctionnalités présentées sont équivalentes; 4) Ça c'est une belle démonstration de refus de débat qui est assez caractéristique à RMS. Car s'ils font la même chose, le temps nécessaire pour le faire va de 1 à 1000. En 1 c'est GIT, au milieu y'a HG, et en 1000 c'est Bzr.
Et en 5) , c'est juste pour clouer le bec à ceux qui veulent le débat.
On se demanderait presque si GIT n'aurait pas été évincé car son auteur est L.T.
paul
[^]Re: Emacs et bzr
C'est deja amusant qu'il ait fini pas accepter de passer à un autre gestionnaire de version que CVS.
Au debut quand ESR a suggeré de changer de gestionnaire de version, d'avoir un bug tracker, et de poster les commits sur un chan IRC, la réponse de RMS a été qu'il n'utilise pas de browser web donc pas de bug tracker, qu'il n'est pas toujours connecté donc pas d'IRC.
http://thread.gmane.org/gmane.emacs.devel/85669
J'ai bien aimé aussi ce message :
http://lists.gnu.org/archive/html/emacs-devel/2008-02/msg024(...)
[^]Re: Emacs et bzr
Il serait possible d'avoir la source pour cette histoire de 1 à 1000. Je veux bien le croire, mais ca me semble beaucoup, quand même.
[^]Re: Emacs et bzr
http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)
Il semble y avoir effectivement des rapports supérieurs à 1 pour 10 000 sur certaines commandes. C'est, par exemple, le cas pour log sur les 10 ou 100 dernières révisions :
Last 100 revisions:
$ time git log -100 >/dev/null
real 0m0.011s
$ time bzr log -l100 >/dev/null
real 2m10.270s
Last 10 revisions:
$ time git log -10 >/dev/null
real 0m0.007s
$ time bzr log -l10 >/dev/null
real 2m9.163s
[^]Re: Emacs et bzr
L'auteur a rectifié par la suite :
http://article.gmane.org/gmane.comp.version-control.bazaar-n(...)
> Last 100 revisions:
>
> $ time git log -100 >/dev/null
> real 0m0.011s
>
> $ time bzr log -l100 >/dev/null
> real 2m10.270s
git: 0m0.009s
bzr: 0m26.562s
> Last 10 revisions:
>
> $ time git log -10 >/dev/null
> real 0m0.007s
>
> $ time bzr log -l10 >/dev/null
> real 2m9.163s
git: 0m0.005s
bzr: 0m25.519s
Ceci dit ça ne change pas le fait que le résultat est instantané ou pas.
[^]Re: Emacs et bzr
En même temps, il est paradoxal que RMS choisisse un DVCS maintenue par une société qu'il critique pour maintenir une distribution non-libre.
http://thomas.apestaart.org/gallery/main.php?g2_itemId=14498
[^]Re: Emacs et bzr
troll poilu...
Windows has no users. It has hostages.
[+] [^]Re: Emacs et bzr
<troll mode="combat">
Peut-on en déduire que Hurd va passer sous Bazaar ?
</troll>
:-)
:-)
C'est vendredi...
Ok, je sors --->[]
[^]Re: Emacs et bzr
C'est en tout cas ce que RMS semble implicitement recommander.
(que tout les projet GNU utilise le dvcs GNU, si ils doivent en utiliser un)
"ça dépend du type de workload, si tu est CPU-bound ça va mieux qu'en memory-bound, où les access patterns et la corrélation des paquets peut avoir des effets non linéaires sur le wallclock time
[^]Re: Emacs et bzr
Sauf que RMS a semblé oublier que les développeurs d'emacs ne sont pas forcément férus de GNU. Ils veulent pouvoir hacker emacs dans de bonnes conditions, avec un logiciel libre.
Quand aux comparaisons des gestionnaires, ça ne prend pas des années lorsqu'on se limite aux critères primordiaux. Et ceux qui sont sur la ML ont vu les tests conduits sur les dépôts emacs git et bzr, c'est des chiffres, et c'est très clair. Moi qui n'ai pas un super-calculateur en guise d'ordinateur, j'aurais apprécié qu'entre deux systèmes qui présentent un facteur 1000 de différence de rapidité, le choix soit aussi technique.
paul
[^]Re: Emacs et bzr
ben c'est à dire que en même temps on ne peut pas être développeur emacs - ni même utilisateur emacs - sans sentir la présence du bonhomme pas loin derrière. ou lui tout court. sans être obligé de finir féru de GNU et de RMS, en résumé.
Windows has no users. It has hostages.
[^]Re: Emacs et bzr
Est-ce que Python est un projet GNU ?
Parce qu'un logiciel GNU qui dépend d'un pas GNU, ça risque de pas le faire.
[^]Re: Emacs et bzr
Ah ouai.. dans le même genre que le Kernel Linux ? :)
"I wonder where I'll go now. The net is vast and infinite."
[^]Re: Emacs et bzr
Il y a un projet GNU pour remplacer le noyau Linux. The Hurd, ça s'appelle.
http://www.gnu.org/software/hurd/hurd.html
[^]Re: Emacs et bzr
Oui et j'espère que bzr ne suivra pas le même chemin que hurd.
[^]Re: Emacs et bzr
En même temps c'est pas comme si emacs ce n'était pas le bazar
~~~~~~> [] (ouf y'a du vent aujourd'hui)