C'est annoncé ici par Guido van Rossum: http://lwn.net/Articles/326201/
Quelque part c'est assez naturel de choisir un DVCS écrit en python pour le projet python (même si il ne cite pas cette raison pour justifier son choix).
Et je le trouve vachement bien écrit.
C'est agréable à lire, clair et précis.
Certains chapitres sont d'ailleurs d'une lecture intéressante pour comprendre quelles peuvent être les problématiques du versionnement.
par exemple : http://hgbook.red-bean.com/read/collaborating-with-other-peo(...)
Dans ma boite, on va aussi migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.
- plus propre d'un point de vue commandes (pas 144 scripts differents avec des dépendances dans tout les sens) et presque aussi simple que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
- une très bonne documentation (bien que celle de Git semble s'améliorer)
- et surtout un bon support sur toutes les plateformes (ce qui est important pour nous puisqu'on fait des applis multi plateformes basées sur Mozilla)
Au niveau fonctionnalités, les deux se valent je trouve, et de toute façon, je ne pense pas qu'on va utiliser les fonctionnalités super avancées de ces outils. D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il semble plus lent que Git sur certaines opérations).
Le seul inconvénient qu'on lui trouve : le site est moche par rapport à celui de git :-)
Le site de Git aussi était moche avant. http://git-scm.com/ n'exsite que depuis peu. Et hop, le même est en préparation pour Mercurial : http://hg-scm.org/
Je suis passé de bazaar à mercurial il n'y a pas très longtemps, il me semble tout simplement que mercurial est ce que bazaar cherchait à devenir en vain... Simple et rapide, il suffit d'essayer.
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
Je rappelle que Bazaar est un projet GNU et que donc les transferts de copyrights se font vers la FSF
Extrait du "Bazaar Copyright Assignement" (http://bazaar-vcs.org/CopyrightAssignment)
You have received good and valuable consideration, and you agree to
assign and do assign to Canonical, Ltd. ("Canonical") your ownership of
copyright in the Assigned Contributions, for the full duration thereof,
and for any renewals or extensions thereof. To any extent that this
assignment is ineffective, you grant to Canonical a nonexclusive,
royalty-free, and perpetual right to use, modify, and distribute the
Assigned Contributions as it wishes.
Mais sans même aller sur le site de Bazaar, on pouvait se douter que Matt Mackall, contributeur émérite au logiciel libre n'allait pas raconter des cracks qui plus est sur une mailing-list publique.
Le fait que Canonical se laisse la possibilité de faire du propriétaire avec bzr, ce n'est pas du FUD, c'est dit explicitement dans la page en question :
6. Canonical will make the Assigned Contributions available under a "Free
Software Licence", according to the definition of that term published by the
Free Software Foundation. Such a licence will, at minimum, permit
people receiving the software, without payment of a royalty to Canonical, to
use, modify and redistribute under the same licence. Canonical may also make
the Assigned Contributions available under other license terms.
Si c'était juste pour les changements de licences libres, la première partie suffisait.
Maintenant, non, Canonical n'est pas la seule boite à faire ça. L'existence de StarOffice n'empêche pas OpenOffice d'exister et d'être libre, au contraire. Ce qui me dérange avec Canonical, c'est le discours ambigüe de Mark Shuttleworth sur le logiciel libre. Dans le discours, il a monté Canonical pour des raisons ethiques, il veut du bien à Debian, contribuer en upstream ... et dans les faits, il héberge sa boite dans un paradis fiscal, freine plutôt le développement de Debian qu'autre chose, beaucoup de gens se plaignent du peu de contributions en upstream. Quand c'est une boite qui annonce clairement qu'ils sont là pour faire de la thune, à la limite, les choses sont claires, mais j'ai du mal à être à l'aise avec une boite qui utilise explicitement les arguments ethiques pour attirer du monde (cf. l'appel de Mark Shuttleworth aux développeurs de SuSE « Abandonnez les maichants, venez plutôt chez nous, c'est nous les gentils » par exemple), avec une position aussi ambigüe.
I wrote Mercurial to be Free with a capital 'F' as a reaction to the
object lesson of Bitkeeper.
Ca laisse sous entendre que la même chose peut se passer avec bzr que Bitkeeper alors que non. Le fork est toujours possible.
Ceci est du FUD
Par ailleurs, je n'ai que la parole de Matt pour confirmer que MS a fait des propositions indécentes (encore qu'elles se justifient du point de vue des extension de licences). Ses allégations ne sont confirmées nulle part ailleurs sur le net (mais je n'ai peut être pas bien cherché).
C'est donc encore un point qui ne peut être vérifié et qui tend à instaurer de la crainte de l'incertitude et du doute sur les intentions de Canonical.
Concernant le point que tu cites ca permet à Canonical de proposer des version étendues proprio. On peut faire la même chose avec une BSD.
La différence c'est que les concurrents ne peuvent pas le faire, ca me parait pas absurde. Les doubles licences GPL/proprio de QT et MySQL n'avaient pas d'autre objectifs. Mais ce qui reste c'est que les développeurs libres peuvent toujours conserver un noyau libre et que le risque Bitkeeper n'existe donc pas.
Il n'y a rien d'autre à ajouter. Le reste de ton post c'est du subjectif
Ses allégations ne sont confirmées nulle part ailleurs sur le net
Elles ne sont pas infirmées non plus par qui que ce soit, bien que ce soit un post public par le fondateur du projet Mercurial, bref pas un troll de passage.
Soit dit en passant, on n'a pas besoin de la remarque de Matt Mackall pour avoir de sérieux doutes sur les « intentions de Canonical », la politique de Canonical suffit (Launchpad, marketing communautaire agressif, etc.).
La différence c'est que les concurrents ne peuvent pas le faire, ca me parait pas absurde.
Là ça tient du troll. Le problème c'est que les autres contributeurs non plus ne peuvent pas le faire. Bref, alors que tout contributeur devrait être sur un pied d'égalité juridiquement (c'est le principe fondamental de la GPL et du copyleft), Canonical détourne le principe à son profit et aux dépens de tous les autres auteurs.
Là ça tient du troll. Le problème c'est que les autres contributeurs non plus ne peuvent pas le faire. Bref, alors que tout contributeur devrait être sur un pied d'égalité juridiquement (c'est le principe fondamental de la GPL et du copyleft), Canonical détourne le principe à son profit et aux dépens de tous les autres auteurs.
Je ne t'ai jamais vu reprocher la mêm chose à Trolltech et MySQL AB en leur temps.
Cela veut dire que les licences GPL ne servent à rien et que en fait bazaar n'est pas libre?
Si c'est le cas je suppose que tu ranges dans les projets du "mal": OpenOffice.org(copyright SUN), gcc, emacs, gnash ... (copyright FSF) et multitudes d'autres projet.
Cela veut dire que les licences GPL ne servent à rien et que en fait bazaar n'est pas libre?
Cela veut dire que la GPL s'applique à tout le monde sauf à Canonical, qui peut changer la licence du projet du jour au lendemain si ça lui chante, au grand dam des contributeurs.
Anyway, je suppose que tu le savais déjà et que tu ne fais que troller.
Comme Sun peut le faire pour OpenOffice.org, la FSF peut le faire pour tous les projets FSF etc. De plus cela ne peut pas changer la licence des versions jusqu'au jour du changement donc c'est du FUD ce que tu dis. Il peut se passer un truc comme il s'est passé pour XFree86 et alors? Le projet a subit un fork et c'est le fork qui a gagné comme par hasard. Donc si jamais Canonical veut jouer au changement de licence un fork aura lieu et la version Canonical sera morte (si le projet est populaire naturellement sinon on s'en fout un peu). Donc le coup du transfert de copyright c'est juste un prétexte point barre mais autant le dire de façon clair et net.
De plus cela ne peut pas changer la licence des versions jusqu'au jour du changement
??? Bien sûr que si, ça peut. Canonical peut packager des offres propriétaires autour d'anciennes versions de Bazaar si ça lui chante. Il a le droit d'apposer une nouvelle licence comme bon lui semble.
Il peut se passer un truc comme il s'est passé pour XFree86 et alors? Le projet a subit un fork et c'est le fork qui a gagné comme par hasard.
"Et alors ?" Et alors, il vaut mieux un projet où l'on n'a pas à forker pour avancer en bonne coopération. Les années perdues par XFree86 dans les bisbilles juridico-personnelles à la noix n'ont pas été très constructives, il me semble. Et je pense que peu de contributeurs se disent que ce n'était pas grave, qu'ils n'ont pas perdu leur temps et leur énergie dans ces idioties.
Maintenant, vu ton enthousiasme à troller comme un malade, je comprends que pour toi ce ne serait pas forcément du temps perdu...
Donc le coup du transfert de copyright c'est juste un prétexte point barre
N'importe quoi. Que Matt Mackall, qui a lancé Mercurial sous licence GPL, n'ait pas envie de céder son copyright à une boîte commerciale qui veut se réserver le droit de sortir des versions propriétaires de son code, je n'appelle pas ça un prétexte.
T'oublies de répondre par rapport au transfert de licence pour OpenOffice.org et ceux à la FSF. Quitte à jouer au Don Quichotte fait le complètement. Pourquoi faire deux poids deux mesure? Par rapport à ta réponse tu continues à fudder.
??? Bien sûr que si, ça peut. Canonical peut packager des offres propriétaires autour d'anciennes versions de Bazaar si ça lui chante. Il a le droit d'apposer une nouvelle licence comme bon lui semble.
N'impotenawak.
Repackager une version ancienne ne remet pas en cause ladite version sur le plan de la GPL
Quel que soit la version repackagée, tu peux toujours la modifier sous les conditions de la GPL et forker. Les 4 libertés sont donc bien garanties.
Ou alors il y a une sérieuse faille dans la GPL et il faut d'urgence ajouter une clause qui lui interdit d'apposer des licences proprio à un logiciel sous GPL.
Ouah et donc si Canonical passe la version n en proprio les versions n-1 .... 0 passent aussi. On ne peut plus forker.
Sans compter le tollé que ca provoquerait. On imagine tout a fait Canonical se mettre à dos toute la communauté.
Dsl mais bazaar n'est pas bitkeeper contrairement à ce qu'affirme Matt
Bitkeeper n'a jamais été libre et il n'a jamais été possible de le forker.
Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
> Dsl mais bazaar n'est pas bitkeeper contrairement à ce qu'affirme Matt
Matt Mackall a discuté avec les p'tits gars de Canonical et Mark S.
La raison qui lui a été donnée pour le don du copyright à Canonical était que Canonical se réservait le droit de pouvoir créer des extensions propriétaires. Après qu'ils utilisent ou non ce droit, c'est une autre histoire, mais Matt Mackall avait le droit et de bonnes raisons de refuser ce deal. Si on se replace dans le contexte de l'époque, et qu'on tient compte du fait que Matt Mackall est un développeur noyau de premier rang, on peut comprendre sa décision.
Au lieu d'accuser Matt Mackall de FUD, tu peux te demander pourquoi ça n'a pas provoqué de réaction de la part de Mark S. et de Canonical ? C'est peut-être que le monsieur disait la vérité.
> Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
À l'origine, Bazaar était un fork d'un projet GNU avant d'être réécrit et qu'ils continuent d'y participer.
Après si Canonical joue au con, ils pourront toujours repartir de la dernière version libre et il existe peut-être une poison pill comme avec Qt.
Et au passage, la parole de Matt Mackall (dont la modération est reconnue de la communauté libriste) a nettement plus de valeur que celle d'un menteur et d'un vantard tel que Mark S.
À l'origine, Bazaar était un fork d'un projet GNU avant d'être réécrit et qu'ils continuent d'y participer.
Après si Canonical joue au con, ils pourront toujours repartir de la dernière version libre et il existe peut-être une poison pill comme avec Qt.
On est d'accord , il n'y a donc aucun aucun risque pour la liberté avec un grand "L" en ce qui concerne bzr et ceux qui sous-entendent qu'un effet bitkeeper pourrait se produire mentent dans le but de d'instaurer le doute
> il n'y a donc aucun aucun risque pour la liberté avec un grand "L" en ce qui concerne bzr et ceux qui sous-entendent qu'un effet bitkeeper pourrait se produire mentent dans le but de d'instaurer le doute
T'es bouché ou quoi ? Matt Mackall dit qu'après l'histoire de BitKeeper, il refusait de "donner" son travail à une société qui entretient le flou (Launchpad, possibilité de créer des extensions propriétaires, communication agressive etc ...) sur ses intentions.
Si demain, Canonical décide de propriétariser Launchpad et de changer (pour la n-ième fois) le format du dépôt, tout les projets utilisant Launchpad se retrouveraient dans une situation délicate comme l'était Linux avec le retrait de la licence BitKeeper par BitMover.
Après, tu peux toujours forker Bazaar ou changer de DVCS mais c'est chiant à faire, du moins si tu ne veux pas perdre l'historique.
Matt Mackall en a rien à foutre de semer le doute, il ne fait que rapporter ce qui s'est passé lors de la réunion avec Canonical et il explique pourquoi il a refusé.
Si Matt Mackall avait menti ou sous-entendu quoique ce soit, Canonical ou Mark S. auraient tout de suite répondu mais ils ne l'ont pas fait.
De plus, Mercurial n'a pas besoin de ça pour s'affirmer face à Bazaar, ça fait longtemps que Mercurial et Bazaar ne jouent plus dans la même cour, le concurrent de Mercurial s'appelle Git et non pas bazaar.
En l'occurrence, rien n'empêche un projet d'héberger une copie complète de son dépôt si la paranoïa le gagne.
Si dans un élan suicidaire Canonical décidait de propriétariser son dépot, une copie du dépôt serait toujours disponible avec une version de bzr GPL.
Le cout est donc nul à l'hébergement près (un dd ca doit le faire pour un projet non ?)
Avec Bitkeeper c'était différent.
Il n'a jamais été libre. Donc le changement de DVCS était obligatoire et les DVCS libres n'étaient pas à la hauteur, ce qui a engendré des contretemps (developpement de GIT, remontée des sources ). Je n'ai pas eu connaissance que l'historique était perdu car j'imagine que Linus avait toujours sa licence mais je ne connais pas les détails.
De plus, Mercurial n'a pas besoin de ça pour s'affirmer face à Bazaar, ça fait longtemps que Mercurial et Bazaar ne jouent plus dans la même cour, le concurrent de Mercurial s'appelle Git et non
pas bazaar.
Ah ! enfin, on revient aux choses sérieuses. Des critères objectifs pour décider des mérites des projets.
Ca tombe bien je pense la même chose que toi sur ce point donc pas la peine d'appuyer sur l'intox . Le mérite technique, seul, suffisait.
On imagine tout a fait Canonical se mettre à dos toute la communauté.
La vacuité de cet argument me sidère. Pour reprendre l'analogie de ton pote du dessus, « on imagine tout à fait XFree86 se mettre à dos toute la communauté ». Ah, tiens, justement...
Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
Je ne savais pas que la FSF détenait le pouvoir absolu de dire le Vrai et le Faux. Merci pour cet argument d'autorité.
que "la raison" c'est que les commandes de Mercurial soient très proche de celles de svn. La deuxième c'est que il y avait quelques personnes complètement opposées à Git (je n'ai pas lu les débats mais d'après le message de GvR cela semble plus être de la religion qu'autre chose). Après que Mercurial soit en python ce n'est clairement pas plus mal pour le projet. Je pense que bazaar va vivre sous perfusions de Canonical et le jour ou une interface launchpad mercurial ou git sera fait cela signifiera la mort du projet.
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
article très intéressant qui montre pourquoi bazaar ne pouvait pas être choisit (trop lent) par contre entre git et mercurial c'est du pareil au même. Le choix et GvR le dit lui même a été subjectif entre les deux. Ils sont aussi bon intrinsèquement parlant l'un que l'autre après c'est plus une question de gout.
Guido souligne d'ailleurs dans son post que tout choix est subjectif. De même que l'ajout ou non d'une fonctionnalité donnée à Python. Il lui arrive de prendre des décisions qui vont à l'encontre de la majorité, en se fiant à son instinct. Vu que ca a mené python à un endroit pas trop mal aujourd'hui, je continue à lui faire confiance.
NOUVELLE DE DERNIÈRE MINUTE : Guido se retire du projet Python ! C'est Barry Warsaw qui reprend le flambeau. Une des décisions de Barry est d'utiliser Bzr plutôt qu'Hg ! http://www.python.org/dev/peps/pep-0401/
Barry s'explique : « Recognized that the selection of Hg as the DVCS of choice was clear proof of the onset of the BDEVIL's insanity, and reverting this decision to switch to Bzr instead, the only true choice. ». Je le trouve un peu dur quand même.
Quand il y a des liens dans un commentaire auquel on répond, il vaut mieux lire ces liens avant de poster.
Parce que là, c'est quand même gros comme poisson:
Recognized that the != inequality operator in Python 3.0 was a horrible, finger pain inducing mistake, the FLUFL reinstates the <> diamond operator as the sole spelling. [...]
Recognized that the disappointing adoption curve of Python 3.0 signals its abject failure, all work on Python 3.1 and subsequent Python 3.x versions is hereby terminated. [...]
Recognized that C is a 20th century language with almost universal rejection by programmers under the age of 30, the CPython implementation will terminate [...]
Je commençais à en avoir marre de ces projets qui passent à Git: Git c'est à la mode et puis c'est Dieu lui-même qui l'a codé ...
Cette fois-ci c'est Mercurial qui gagne et pas pour n'importe quel projet à la gomme mais Python lui-même !
Je ne cesse de m'émerveiller devant la puissance, l'efficacité et la simplicité de Mercurial.
J'ai le sentiment que ceux qui choisissent Mercurial le font après une étude approfondie, rationnel et pragmatique (comme Java, OpenSolaris et Mozilla).
Pour Git j'ai parfois le sentiment que c'est le choix des développeurs ou des admins les plus influents qui l'emporte.
Pour ce qui est de Bazaar j'ai vraiment l'impression qu'il y a une tentative de buzz de Canonical en ce moment, que ça a failli prendre mais qu'au final seuls Mercurial et Git vont survivre. Si vous suivez le planète Gnome vous avez sûrement vu passer pas mal de post pour vanter Bazaar, comme ça soudainement, comme un cheveu sur la soupe, alors que sur les planet Fedora, Gentoo ou Archlinux rien, que dalle. C'était assez bizzare ...
Git est populaire, c'est un fait. Tu peux aimer ou pas, mais essayer de faire croire que c'est juste des vilains qui forcent les gentils à utiliser Git alors que Mercurial est mieux, c'est du FUD de bas de gamme.
Oh ce troll fantastique !
Java choisi après une étude approfondie, rationnelle et pragmatique, fallait la faire celle là, jolie :)
Et un mardi en plus, chapeau !
Mercurial c'est bon, j'avais pas mal cherché à un moment un truc à utiliser de façon personnelle et mon choix s'est arrêté sur Mercurial : prise en main rapide et efficace, ça marche, c'est bien.
Git m'avait un peu rebuté, il est plus « rugueux », faut en vouloir un peu plus pour rentrer dedans. Ma flemme étant l'une de mes meilleure conseillère, Mercurial a vaincu.
c'est rigolo moi après test c'est git que j'ai choisi. Il faut avouer que je ne me suis jamais servi de svn et que j'ai donc trouvé assez abscons les commandes de mercurial... Comme quoi les goûts et les couleurs :)
> Oh ce troll fantastique !
> Java choisi après une étude approfondie, rationnelle et pragmatique, fallait la faire celle là, jolie :)
Loupé, le monsieur te dit que les projets Java, OpenSolaris et Mozilla, ont fait le choix pragmatique et réfléchi d'utiliser Mercurial pour gérer leur source.
'Faut baisser la sensibilité de ton trollomètre, il s'affole pour un rien...
KDE va migrer vers git un de ces quatre. L'argument le plus déterminant semble être les fonctionnalités avancées de git, comme le cherry picking, les annotations, ou des histoires de conversion de repository beaucoup mieux supportées par git que par mercurial.
KDE a un historique de décisions basés sur des arguments techniques vraiment travaillés. Il y a eu plusieurs propositions pour tenter de faire avec mercurial ce qui est fait avec git mais sans succès. Il semble que KDE a des besoins vraiment spécifiques en terme de repository.
Et clairement, git est beaucoup plus populaire chez les développeurs. Dommage (de mon point de vue).
Aller, je fonce dedans : moi un truc qui me manque beaucoup, c'est le rebase de git. Je trouve ça indispensable. Je viens de voir qu'il a été ajouté très récemment, et encore, juste comme "extension" à mercurial. Dommage, je trouve ça tellement important ...
# Juste un mot sur mercurial
Posté par blobmaster . Évalué à 9.
http://www.selenic.com/mercurial/wiki/index.cgi/MercurialBoo(...)
Et je le trouve vachement bien écrit.
C'est agréable à lire, clair et précis.
Certains chapitres sont d'ailleurs d'une lecture intéressante pour comprendre quelles peuvent être les problématiques du versionnement.
par exemple :
http://hgbook.red-bean.com/read/collaborating-with-other-peo(...)
A mon avis, un must.
[^] # Re: Juste un mot sur mercurial
Posté par GeneralZod . Évalué à 6.
Mercurial c'est bon, mangez-en !
[^] # Re: Juste un mot sur mercurial
Posté par wilk . Évalué à 3.
http://www.selenic.com/mercurial/wiki/index.cgi/TranslatingM(...)
# Choisir Mercurial
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 7.
Dans ma boite, on va aussi migrer vers Mercurial. On a pas mal recherché et discuté des différents avantages et inconvénients entre git et mercurial, et hg nous semble plus approprié pour nos besoins.
- plus propre d'un point de vue commandes (pas 144 scripts differents avec des dépendances dans tout les sens) et presque aussi simple que subversion. Cela nous fera gagner du temps pour s'approprier l'outil.
- une très bonne documentation (bien que celle de Git semble s'améliorer)
- et surtout un bon support sur toutes les plateformes (ce qui est important pour nous puisqu'on fait des applis multi plateformes basées sur Mozilla)
Au niveau fonctionnalités, les deux se valent je trouve, et de toute façon, je ne pense pas qu'on va utiliser les fonctionnalités super avancées de ces outils. D'un point de vue performance, on n'a pas des projets de plusieurs dizaines de millions de lignes de code, aussi je ne pense pas que Mercurial va nous pénaliser (bien qu'il semble plus lent que Git sur certaines opérations).
Le seul inconvénient qu'on lui trouve : le site est moche par rapport à celui de git :-)
Un bon comparatif (sans troll et assez objectif je trouve) qui a fini par nous convaincre : http://importantshock.wordpress.com/2008/08/07/git-vs-mercur(...)
à lire.
[^] # Re: Choisir Mercurial
Posté par Fabien Penso (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: Choisir Mercurial
Posté par GeneralZod . Évalué à 4.
[^] # Re: Choisir Mercurial
Posté par TNorth . Évalué à 2.
[^] # Re: Choisir Mercurial
Posté par Ririsoft . Évalué à 2.
Voir http://www.selenic.com/mercurial/wiki/index.cgi/MercurialHos(...)
[^] # Re: Choisir Mercurial
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
# mercurial après bazaar
Posté par wilk . Évalué à 5.
[^] # Re: mercurial après bazaar
Posté par wilk . Évalué à 3.
http://article.gmane.org/gmane.comp.version-control.mercuria(...)
Sur un éventuel rapprochement de codes entre mercurial et bazaar, il aurait fallu que le copyright soit transféré à cannonical, ce que le développeur de mercurial a refusé, la naissance de mercurial faisant suite à "la leçon Bitkeeper".
[^] # Re: mercurial après bazaar
Posté par Xavier Maillard . Évalué à -1.
Je rappelle que Bazaar est un projet GNU et que donc les transferts de copyrights se font vers la FSF
[^] # Re: mercurial après bazaar
Posté par GeneralZod . Évalué à 6.
You have received good and valuable consideration, and you agree to
assign and do assign to Canonical, Ltd. ("Canonical") your ownership of
copyright in the Assigned Contributions, for the full duration thereof,
and for any renewals or extensions thereof. To any extent that this
assignment is ineffective, you grant to Canonical a nonexclusive,
royalty-free, and perpetual right to use, modify, and distribute the
Assigned Contributions as it wishes.
Mais sans même aller sur le site de Bazaar, on pouvait se douter que Matt Mackall, contributeur émérite au logiciel libre n'allait pas raconter des cracks qui plus est sur une mailing-list publique.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 0.
Il paraitrait que ca simplifie l'ajout de nouvelle licences.
Mais comme d'hab venant de Canonical, c'est choquant et bien entendu c'est forcément pour permettre des extensions proprio.
C'est vrai que ca met en péril le logiciel proprement dit.
Ils n'ont pas renoncé à leur copyright
https://lists.ubuntu.com/archives/bazaar-announce/2008-Febru(...)
mais ca n'a pas l'air d'effrayer la FSF.
Bien sûr le commentaire de Matt n'a absolument rien à voir avec du FUD.
D'ailleurs, c'est marrant en cherchant un peu on a du mal à trouver d'autres témoignages qui abonderaient dans son sens.
Bon y'a un autre contributeur de Mercurial qui a posté dessus
http://www.selenic.com/pipermail/mercurial/2006-May/008165.h(...)
http://www.serpentine.com/blog/2006/06/01/joint-mercurial-ba(...)
Il y est question de collaboration et pas de merge, mais on va croire Matt sur parole hein. Personne n'est dupe !
Et d'ailleurs tous les devs de LL sont des chevaliers blancs.
Si on se fie juste à un commentaire pour préferer mercurial sur Bzr nul doute qu'en restant cohérent on préféra Windows à Linux.
[^] # Re: mercurial après bazaar
Posté par Antoine . Évalué à 1.
[^] # Re: mercurial après bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 4.
6. Canonical will make the Assigned Contributions available under a "Free
Software Licence", according to the definition of that term published by the
Free Software Foundation. Such a licence will, at minimum, permit
people receiving the software, without payment of a royalty to Canonical, to
use, modify and redistribute under the same licence. Canonical may also make
the Assigned Contributions available under other license terms.
Si c'était juste pour les changements de licences libres, la première partie suffisait.
Maintenant, non, Canonical n'est pas la seule boite à faire ça. L'existence de StarOffice n'empêche pas OpenOffice d'exister et d'être libre, au contraire. Ce qui me dérange avec Canonical, c'est le discours ambigüe de Mark Shuttleworth sur le logiciel libre. Dans le discours, il a monté Canonical pour des raisons ethiques, il veut du bien à Debian, contribuer en upstream ... et dans les faits, il héberge sa boite dans un paradis fiscal, freine plutôt le développement de Debian qu'autre chose, beaucoup de gens se plaignent du peu de contributions en upstream. Quand c'est une boite qui annonce clairement qu'ils sont là pour faire de la thune, à la limite, les choses sont claires, mais j'ai du mal à être à l'aise avec une boite qui utilise explicitement les arguments ethiques pour attirer du monde (cf. l'appel de Mark Shuttleworth aux développeurs de SuSE « Abandonnez les maichants, venez plutôt chez nous, c'est nous les gentils » par exemple), avec une position aussi ambigüe.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 1.
I wrote Mercurial to be Free with a capital 'F' as a reaction to the
object lesson of Bitkeeper.
Ca laisse sous entendre que la même chose peut se passer avec bzr que Bitkeeper alors que non. Le fork est toujours possible.
Ceci est du FUD
Par ailleurs, je n'ai que la parole de Matt pour confirmer que MS a fait des propositions indécentes (encore qu'elles se justifient du point de vue des extension de licences). Ses allégations ne sont confirmées nulle part ailleurs sur le net (mais je n'ai peut être pas bien cherché).
C'est donc encore un point qui ne peut être vérifié et qui tend à instaurer de la crainte de l'incertitude et du doute sur les intentions de Canonical.
Concernant le point que tu cites ca permet à Canonical de proposer des version étendues proprio. On peut faire la même chose avec une BSD.
La différence c'est que les concurrents ne peuvent pas le faire, ca me parait pas absurde. Les doubles licences GPL/proprio de QT et MySQL n'avaient pas d'autre objectifs. Mais ce qui reste c'est que les développeurs libres peuvent toujours conserver un noyau libre et que le risque Bitkeeper n'existe donc pas.
Il n'y a rien d'autre à ajouter. Le reste de ton post c'est du subjectif
[^] # Re: mercurial après bazaar
Posté par Antoine . Évalué à 2.
Elles ne sont pas infirmées non plus par qui que ce soit, bien que ce soit un post public par le fondateur du projet Mercurial, bref pas un troll de passage.
Soit dit en passant, on n'a pas besoin de la remarque de Matt Mackall pour avoir de sérieux doutes sur les « intentions de Canonical », la politique de Canonical suffit (Launchpad, marketing communautaire agressif, etc.).
La différence c'est que les concurrents ne peuvent pas le faire, ca me parait pas absurde.
Là ça tient du troll. Le problème c'est que les autres contributeurs non plus ne peuvent pas le faire. Bref, alors que tout contributeur devrait être sur un pied d'égalité juridiquement (c'est le principe fondamental de la GPL et du copyleft), Canonical détourne le principe à son profit et aux dépens de tous les autres auteurs.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 2.
Là ça tient du troll. Le problème c'est que les autres contributeurs non plus ne peuvent pas le faire. Bref, alors que tout contributeur devrait être sur un pied d'égalité juridiquement (c'est le principe fondamental de la GPL et du copyleft), Canonical détourne le principe à son profit et aux dépens de tous les autres auteurs.
Je ne t'ai jamais vu reprocher la mêm chose à Trolltech et MySQL AB en leur temps.
[^] # Re: mercurial après bazaar
Posté par Anonyme . Évalué à 1.
Licenses: GNU GPL v2, GNU GPL v3
Cela veut dire que les licences GPL ne servent à rien et que en fait bazaar n'est pas libre?
Si c'est le cas je suppose que tu ranges dans les projets du "mal": OpenOffice.org(copyright SUN), gcc, emacs, gnash ... (copyright FSF) et multitudes d'autres projet.
[^] # Re: mercurial après bazaar
Posté par Antoine . Évalué à 0.
Cela veut dire que la GPL s'applique à tout le monde sauf à Canonical, qui peut changer la licence du projet du jour au lendemain si ça lui chante, au grand dam des contributeurs.
Anyway, je suppose que tu le savais déjà et que tu ne fais que troller.
[^] # Re: mercurial après bazaar
Posté par Anonyme . Évalué à 2.
[^] # Re: mercurial après bazaar
Posté par Antoine . Évalué à 4.
??? Bien sûr que si, ça peut. Canonical peut packager des offres propriétaires autour d'anciennes versions de Bazaar si ça lui chante. Il a le droit d'apposer une nouvelle licence comme bon lui semble.
Il peut se passer un truc comme il s'est passé pour XFree86 et alors? Le projet a subit un fork et c'est le fork qui a gagné comme par hasard.
"Et alors ?" Et alors, il vaut mieux un projet où l'on n'a pas à forker pour avancer en bonne coopération. Les années perdues par XFree86 dans les bisbilles juridico-personnelles à la noix n'ont pas été très constructives, il me semble. Et je pense que peu de contributeurs se disent que ce n'était pas grave, qu'ils n'ont pas perdu leur temps et leur énergie dans ces idioties.
Maintenant, vu ton enthousiasme à troller comme un malade, je comprends que pour toi ce ne serait pas forcément du temps perdu...
Donc le coup du transfert de copyright c'est juste un prétexte point barre
N'importe quoi. Que Matt Mackall, qui a lancé Mercurial sous licence GPL, n'ait pas envie de céder son copyright à une boîte commerciale qui veut se réserver le droit de sortir des versions propriétaires de son code, je n'appelle pas ça un prétexte.
[^] # Re: mercurial après bazaar
Posté par Anonyme . Évalué à 1.
Bazaar est un logiciel libre.
ps: je n'aime pas bazaar.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 3.
??? Bien sûr que si, ça peut. Canonical peut packager des offres propriétaires autour d'anciennes versions de Bazaar si ça lui chante. Il a le droit d'apposer une nouvelle licence comme bon lui semble.
N'impotenawak.
Repackager une version ancienne ne remet pas en cause ladite version sur le plan de la GPL
Quel que soit la version repackagée, tu peux toujours la modifier sous les conditions de la GPL et forker. Les 4 libertés sont donc bien garanties.
Ou alors il y a une sérieuse faille dans la GPL et il faut d'urgence ajouter une clause qui lui interdit d'apposer des licences proprio à un logiciel sous GPL.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 2.
Sans compter le tollé que ca provoquerait. On imagine tout a fait Canonical se mettre à dos toute la communauté.
Dsl mais bazaar n'est pas bitkeeper contrairement à ce qu'affirme Matt
Bitkeeper n'a jamais été libre et il n'a jamais été possible de le forker.
Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
Il s'agit bien purement et simplement de FUD
[^] # Re: mercurial après bazaar
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Ouais, et après ça, c'est les autres qui FUDent ...
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 1.
corrigé ici
http://linuxfr.org/comments/1020988.html#1020988
[^] # Re: mercurial après bazaar
Posté par GeneralZod . Évalué à 2.
Matt Mackall a discuté avec les p'tits gars de Canonical et Mark S.
La raison qui lui a été donnée pour le don du copyright à Canonical était que Canonical se réservait le droit de pouvoir créer des extensions propriétaires. Après qu'ils utilisent ou non ce droit, c'est une autre histoire, mais Matt Mackall avait le droit et de bonnes raisons de refuser ce deal. Si on se replace dans le contexte de l'époque, et qu'on tient compte du fait que Matt Mackall est un développeur noyau de premier rang, on peut comprendre sa décision.
Au lieu d'accuser Matt Mackall de FUD, tu peux te demander pourquoi ça n'a pas provoqué de réaction de la part de Mark S. et de Canonical ? C'est peut-être que le monsieur disait la vérité.
> Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
À l'origine, Bazaar était un fork d'un projet GNU avant d'être réécrit et qu'ils continuent d'y participer.
Après si Canonical joue au con, ils pourront toujours repartir de la dernière version libre et il existe peut-être une poison pill comme avec Qt.
Et au passage, la parole de Matt Mackall (dont la modération est reconnue de la communauté libriste) a nettement plus de valeur que celle d'un menteur et d'un vantard tel que Mark S.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 2.
À l'origine, Bazaar était un fork d'un projet GNU avant d'être réécrit et qu'ils continuent d'y participer.
Après si Canonical joue au con, ils pourront toujours repartir de la dernière version libre et il existe peut-être une poison pill comme avec Qt.
On est d'accord , il n'y a donc aucun aucun risque pour la liberté avec un grand "L" en ce qui concerne bzr et ceux qui sous-entendent qu'un effet bitkeeper pourrait se produire mentent dans le but de d'instaurer le doute
CQFD, Merci et slts
[^] # Re: mercurial après bazaar
Posté par GeneralZod . Évalué à 3.
T'es bouché ou quoi ? Matt Mackall dit qu'après l'histoire de BitKeeper, il refusait de "donner" son travail à une société qui entretient le flou (Launchpad, possibilité de créer des extensions propriétaires, communication agressive etc ...) sur ses intentions.
Si demain, Canonical décide de propriétariser Launchpad et de changer (pour la n-ième fois) le format du dépôt, tout les projets utilisant Launchpad se retrouveraient dans une situation délicate comme l'était Linux avec le retrait de la licence BitKeeper par BitMover.
Après, tu peux toujours forker Bazaar ou changer de DVCS mais c'est chiant à faire, du moins si tu ne veux pas perdre l'historique.
Matt Mackall en a rien à foutre de semer le doute, il ne fait que rapporter ce qui s'est passé lors de la réunion avec Canonical et il explique pourquoi il a refusé.
Si Matt Mackall avait menti ou sous-entendu quoique ce soit, Canonical ou Mark S. auraient tout de suite répondu mais ils ne l'ont pas fait.
De plus, Mercurial n'a pas besoin de ça pour s'affirmer face à Bazaar, ça fait longtemps que Mercurial et Bazaar ne jouent plus dans la même cour, le concurrent de Mercurial s'appelle Git et non pas bazaar.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 1.
En l'occurrence, rien n'empêche un projet d'héberger une copie complète de son dépôt si la paranoïa le gagne.
Si dans un élan suicidaire Canonical décidait de propriétariser son dépot, une copie du dépôt serait toujours disponible avec une version de bzr GPL.
Le cout est donc nul à l'hébergement près (un dd ca doit le faire pour un projet non ?)
Avec Bitkeeper c'était différent.
Il n'a jamais été libre. Donc le changement de DVCS était obligatoire et les DVCS libres n'étaient pas à la hauteur, ce qui a engendré des contretemps (developpement de GIT, remontée des sources ). Je n'ai pas eu connaissance que l'historique était perdu car j'imagine que Linus avait toujours sa licence mais je ne connais pas les détails.
De plus, Mercurial n'a pas besoin de ça pour s'affirmer face à Bazaar, ça fait longtemps que Mercurial et Bazaar ne jouent plus dans la même cour, le concurrent de Mercurial s'appelle Git et non
pas bazaar.
Ah ! enfin, on revient aux choses sérieuses. Des critères objectifs pour décider des mérites des projets.
Ca tombe bien je pense la même chose que toi sur ce point donc pas la peine d'appuyer sur l'intox . Le mérite technique, seul, suffisait.
[^] # Re: mercurial après bazaar
Posté par Antoine . Évalué à 3.
La vacuité de cet argument me sidère. Pour reprendre l'analogie de ton pote du dessus, « on imagine tout à fait XFree86 se mettre à dos toute la communauté ». Ah, tiens, justement...
Encore une fois si ca avait été un pb penses tu réellement que la FSF l'aurait accepté en tant que projet GNU
Je ne savais pas que la FSF détenait le pouvoir absolu de dire le Vrai et le Faux. Merci pour cet argument d'autorité.
[^] # Re: mercurial après bazaar
Posté par Bozo_le_clown . Évalué à 1.
Je ne savais pas que la FSF détenait le pouvoir absolu de dire le Vrai et le Faux. Merci pour cet argument d'autorité.
En tout cas je leur fais plus confiance qu'à un posteur anonyme de DLFP pour déceler un piège sur des licences.
# dommage
Posté par Anonyme . Évalué à 2.
[^] # Re: dommage
Posté par wilk . Évalué à 3.
http://www.python.org/dev/peps/pep-0374/
En particulier en fin de document : Barrier to Entry où il indique que le temps et l'effort à faire pour faire un checkout de python est déterminant. S'il est trop long ou trop difficile ça risque de dissuader un contributeur potentiel. Ensuite un bench, sans parler du fait qu'il faut un outil particulièrement à jour dans le cas de bazaar.
Ce qui pourrait sauver bazaar c'est qu'il puisse communiquer en natif avec les deux autres.
[^] # Re: dommage
Posté par Anonyme . Évalué à 2.
[^] # Re: dommage
Posté par Philippe F (site web personnel) . Évalué à 2.
En plus, j'adore mercurial.
[^] # Re: dommage
Posté par Victor STINNER (site web personnel) . Évalué à 2.
http://feedproxy.google.com/~r/CoderWhoSaysPy/~3/djIyKRcH1TM(...)
NOUVELLE DE DERNIÈRE MINUTE : Guido se retire du projet Python ! C'est Barry Warsaw qui reprend le flambeau. Une des décisions de Barry est d'utiliser Bzr plutôt qu'Hg ! http://www.python.org/dev/peps/pep-0401/
Barry s'explique : « Recognized that the selection of Hg as the DVCS of choice was clear proof of the onset of the BDEVIL's insanity, and reverting this decision to switch to Bzr instead, the only true choice. ». Je le trouve un peu dur quand même.
[^] # Re: dommage
Posté par jiyuu . Évalué à 1.
Le problème quand on poste une info un 1er avril, c'est qu'on sait pas si c'est une connerie ou pas...
/me part à la recherche de plus amples informations...
[^] # Re: dommage
Posté par jiyuu . Évalué à 1.
Quand il y a des liens dans un commentaire auquel on répond, il vaut mieux lire ces liens avant de poster.
Parce que là, c'est quand même gros comme poisson:
Recognized that the != inequality operator in Python 3.0 was a horrible, finger pain inducing mistake, the FLUFL reinstates the <> diamond operator as the sole spelling. [...]
Recognized that the disappointing adoption curve of Python 3.0 signals its abject failure, all work on Python 3.1 and subsequent Python 3.x versions is hereby terminated. [...]
Recognized that C is a 20th century language with almost universal rejection by programmers under the age of 30, the CPython implementation will terminate [...]
# ça me fait plaisir !
Posté par Ririsoft . Évalué à 5.
Cette fois-ci c'est Mercurial qui gagne et pas pour n'importe quel projet à la gomme mais Python lui-même !
Je ne cesse de m'émerveiller devant la puissance, l'efficacité et la simplicité de Mercurial.
J'ai le sentiment que ceux qui choisissent Mercurial le font après une étude approfondie, rationnel et pragmatique (comme Java, OpenSolaris et Mozilla).
Pour Git j'ai parfois le sentiment que c'est le choix des développeurs ou des admins les plus influents qui l'emporte.
Pour ce qui est de Bazaar j'ai vraiment l'impression qu'il y a une tentative de buzz de Canonical en ce moment, que ça a failli prendre mais qu'au final seuls Mercurial et Git vont survivre. Si vous suivez le planète Gnome vous avez sûrement vu passer pas mal de post pour vanter Bazaar, comme ça soudainement, comme un cheveu sur la soupe, alors que sur les planet Fedora, Gentoo ou Archlinux rien, que dalle. C'était assez bizzare ...
Bref ! Bon vent à Python et Mercurial !
[^] # Re: ça me fait plaisir !
Posté par Matthieu Moy (site web personnel) . Évalué à 9.
Regarde par exemple le sondage qu'a fait GNOME avant de migrer :
http://blogs.gnome.org/newren/2009/01/03/gnome-dvcs-survey-r(...)
Git est populaire, c'est un fait. Tu peux aimer ou pas, mais essayer de faire croire que c'est juste des vilains qui forcent les gentils à utiliser Git alors que Mercurial est mieux, c'est du FUD de bas de gamme.
[^] # Re: ça me fait plaisir !
Posté par Yth (Mastodon) . Évalué à 0.
Java choisi après une étude approfondie, rationnelle et pragmatique, fallait la faire celle là, jolie :)
Et un mardi en plus, chapeau !
Mercurial c'est bon, j'avais pas mal cherché à un moment un truc à utiliser de façon personnelle et mon choix s'est arrêté sur Mercurial : prise en main rapide et efficace, ça marche, c'est bien.
Git m'avait un peu rebuté, il est plus « rugueux », faut en vouloir un peu plus pour rentrer dedans. Ma flemme étant l'une de mes meilleure conseillère, Mercurial a vaincu.
Yth.
[^] # Re: ça me fait plaisir !
Posté par Anonyme . Évalué à 4.
[^] # Re: ça me fait plaisir !
Posté par qstone . Évalué à 5.
> Java choisi après une étude approfondie, rationnelle et pragmatique, fallait la faire celle là, jolie :)
Loupé, le monsieur te dit que les projets Java, OpenSolaris et Mozilla, ont fait le choix pragmatique et réfléchi d'utiliser Mercurial pour gérer leur source.
'Faut baisser la sensibilité de ton trollomètre, il s'affole pour un rien...
[^] # Re: ça me fait plaisir !
Posté par Philippe F (site web personnel) . Évalué à 1.
KDE a un historique de décisions basés sur des arguments techniques vraiment travaillés. Il y a eu plusieurs propositions pour tenter de faire avec mercurial ce qui est fait avec git mais sans succès. Il semble que KDE a des besoins vraiment spécifiques en terme de repository.
Et clairement, git est beaucoup plus populaire chez les développeurs. Dommage (de mon point de vue).
[^] # Re: ça me fait plaisir !
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
[^] # Re: ça me fait plaisir !
Posté par Philippe F (site web personnel) . Évalué à 1.
http://mail.kde.org/pipermail/kde-scm-interest/
[^] # Re: ça me fait plaisir !
Posté par benoar . Évalué à 2.
# Mercurial et Python
Posté par vida18 . Évalué à 0.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.