rewind a écrit 3412 commentaires

Confondre l'outil et son utilisation potentiellement malveillante, c'est digne de l'HADOPI qui confond P2P et contrefaçon...

Certaines grosses conférences se mettent aussi à publier directement elle-même leurs proceedings en version électronique et sous licence CC, donc sans passer par un éditeur OA. Par exemple, STACS (eux utilisent CC-BY-ND) : ils expliquent le pourquoi du comment dans la faq [1]. Si d'autres grosses conf suivent ce mouvement, on n'aura plus aucun souci d'éditeur rapaces et d'OA avec corrélation négative (critique que je trouve tout à fait justifiée).

[1] http://www.stacs-conf.org/faq.html

C'est vrai, quand on est la 5è puissance économique mondiale, c'est qu'on n'a pas d'argent... En tout cas, pas pour nous autres, les pékins moyens. Y'a bien que la droite pour oser faire croire que la France est un pays du Tiers Monde...

"mutualiser certaines ressources", "rediriger vers d'autres developpements", "innover aussi bien au niveau technique que services"

Je te parle de projet social, tu me parles de rationalisation économique. Tu raisonnes comme la société Mandriva, je raisonne comme le projet Debian. Je crois que le débat pourrait durer éternellement. Je comprends très bien ce que tu me dis, mais je continue à croire que tes arguments ne s'appliquent pas à un projet purement communautaire tel que Mageia.

1) la majorité de cette communauté travaille déjà sur son temps libre, parce que, comme je le disais, il n'y a pas que les devs, il y a tout le reste autour et ça représente beaucoup de monde. Il suffit de voir les grandes listes de personnes qui s'inscrivent sur les tâches à faire. Toutes ne sont pas d'anciens employés de mandriva.
2) les anciens employés de mandriva sont pour la plupart des ingénieurs d'un excellent niveau qui n'auront aucun mal à retrouver du travail, et même peut-être que certains seront embauchés pour justement continuer à travailler sur Mageia. En tout cas, moi, si j'étais recruteur, j'embaucherais direct.
3) tu oublies que dans Debian, il n'y a aucun salarié direct et pourtant, ça fonctionne depuis plus de 10 ans. Mageia a adopté le même genre de fonctionnement, ils n'ont aucune raison d'échouer là où d'autres ont très bien réussi.

Tu fais fausse route à mon avis. Réduire la question de la pérennité d'une distribution à des questions financières, c'est bien un raisonnement de financier, et c'est justement ça qui a conduit mandriva à sa perte. Là, on a une bande de joyeux lurons qui se foutent bien des aspects financiers puisque, comme ils le disent dans la page sur leurs valeurs, ils veulent s'amuser. Ils ne vendent rien, ils n'achètent rien. Ils ont juste besoin de quelques serveurs pour faire tourner leurs services mais c'est vraiment rien comparé au reste. Et le reste, le plus important, c'est la communauté, c'est les heures de temps libre consacré à ce projet, c'est l'envie, c'est la reconnaissance d'un travail bien fait, etc. Bref, tout ce que la société mandriva a oublié en cours de chemin.

Les dev Mageia ne font pas cette distrib pour qu'elle remplace Ubuntu ou qu'elle soit installée sur tous les desktop, ils la font pour se faire plaisir et avoir un truc qu'ils aiment utiliser et perfectionner et comme ils ne sont pas seuls à aimer faire ça, qu'ils sont rejoints par beaucoup beaucoup de monde, ça va forcément marcher.

Ne perdons pas de vue que Mageia devient (de mon point de vue) la deuxième (ou troisième pour ne froisser personne) distribution majeure purement communautaire, et qu'étant donné l'histoire de la grosse distribution purement communautaire, on peut penser que ça va durer un sacré moment.

Ce que je trouve remarquable, c'est que Mandriva (l'entreprise) n'ait pas réussi à faire tout ce que Mageia a accompli en quelques semaines (et c'est proprement hallucinant) alors que tous les gens étaient là et disponibles pour le faire... Donnez les entreprises à des financiers qu'ils disaient...

Ou dans une mine au Chili...

Si seulement nous avions un rapport de 1 à 5 entre un ouvrier et son patron ou même de 1 à 40 (entre le paysan et le patron), ça serait le rêve... Mais on en est très très loin, les rapports actuels sont plutôt de l'ordre de 1 à 200 et plus. Alors, si le salaire du patron qui gagne 9 euros par rapports au paysan qui gagne 0.25 euros te choquent, je te conseille de militer pour le salaire maximum. Parce que ce sont bien ces patrons qui gagnent des centaines de fois plus que leurs salariés qui pèsent dans la différence entre salaire médian et salaire moyen...

> Gedit étant un éditeur de texte offrant bien plus de confort que les très mauvais emacs, vim, eclipse, geany, kwrite…

Ouf tout va bien, j'utilise Kate :P

Merci beaucoup pour ces précisions. Je pense qu'avec tous les nouveaux fans supplémentaires que tu viens de te faire, tu ne vas avoir aucun mal à trouver des relecteurs (et vive l'Art Libre !). Mais vraiment, remets les en ligne, de les avoir évoqué m'a redonné envie de les lire :)

Quand j'ai commencé à lire le résumé, ça m'a tout de suite rappelé plein de souvenirs. Parce que je me souviens avoir lu ce bouquin à l'époque où il s'appelait Elfe Noir Démon Rouge (et il me semble qu'il n'était pas encore fini à l'époque, qu'il était en cours d'écriture sur un blog). Il était accompagné d'autres nouvelles ("Délirium l'ange du chaos", "L'énième prophétie") dont je garde un excellent souvenir. Du coup, en voyant ça, je me pose plein de questions. Parce qu'à l'époque, l'auteur (avec qui j'avais échangé quelques mails) s'appelait Frédéric (mais avait le même nom de famille) et écrivait sous le pseudo Neryel (on en trouve des traces sur web archive). Je suppose que tu as un lien avec lui... En tout cas, je suis content de voir que ça existe toujours et que ça évolue, même si je regrette la disparition de ces premières nouvelles.

Ça me rassure de voir que le comportement que je décris peut arriver dans certains cas (heureusement, pas tous). J'espère que ça réussira à convaincre ceux qui m'affirment que non, non, non c'est toujours mieux avec git que, ben pas forcément.

>> ce qui te gène c'est la possibilité de pouvoir faire un pull d'un dépot différent de celui où on fait un push car ça faciliterais le maintient d'une version alternative du logiciel ?

En quelque sorte, oui.

>> D'une manière générale, je pense qu'il est mauvais de croire qu'un problème « social » peut être résolu par la technique. Ça me semble illusoire et ça peut toujours être contrecarré.

Et pourtant, avec notre OS préféré (que ce soit BSD ou Linux d'ailleurs), nous sommes entourés de mesures techniques qui règlent des problèmes sociaux. Ne serait-ce que l'existence de droits, et du compte root, "pour pas que les utilisateurs normaux fassent n'importe quoi", alors que c'est juste pour empêcher qu'ils puissent faire n'importe quoi, qu'ils en aient la possibilité. Et oui, ça peut être contourné et même des gens s'y emploient à longueur de journée. N'empêche que ça marche bien la plupart du temps.

Alors, je vais commencer par te dire comme à Matthieu Moy : on se calme, pas la peine d'être aussi agressif. Je sais que vous êtes deux aficionados de git, mais là, je vous trouve tous les deux assez agressifs. Surtout que je dis que je vais essayer de m'y mettre à git, donc pas la peine de me parler de "fermer des fonctionnalités" blabla.

Bref, pour répondre à ta première question, je vais t'en poser une autre : tu as des exemples concrets de programme en C avec des memory leaks ?

Tout d'abord, on se calme hein, pas la peine d'être aussi agressif.

Ensuite, dans la phrase que tu cites, il y a exactement ce que je décris dans mon texte initial : avec un VCS, le gars qui fait des modifs est obligé de discuter avec upstream, il est obligé de s'intégrer socialement avec le projet, il est obligé de collaborer s'il veut que ses modifs soient intégrées, parce qu'il est relativement difficile de maintenir un patch en dehors de la "branche principale" (parce que justement, ce n'est pas fait pour ça). Alors qu'un DVCS, tu peux avoir ton fork sur ton site, sans en parler à upstream. Ce que ça change (puisque c'est ta question), c'est que dans un cas, tu as une obligation technique de collaborer, dans l'autre cas, tu as une permission technique de ne pas collaborer. Et ma thèse, c'est que ça peut engendrer des comportements idoines, en ce sens qu'avec un DVCS, tu peux faire ton égoiste dans ton coin, chose impossible avec un VCS. Et j'insiste bien sur "peux", parce qu'effectivement, on peut faire autrement aussi et ça se passe bien dans la plupart des cas (heureusement).

Quant à Linux, ce n'est pas un workflow où chacun garde tout dans son coin sur son site, c'est un workflow assez complexe et très hiérarchique où tout est public, au vu et au su de tous. Donc ça ne rentre vraiment pas dans le comportement que je critique. Et d'ailleurs, ceux qui s'y essaient dans le développement de Linux se font taper sur les doigts (comme Google récemment). Ce qui n'est pas imposé par le VCS l'est par la communauté. Il n'y a qu'à voir la procédure d'acception des patchs où un des premiers trucs qui est dit est : en parler sur la LKML, c'est à dire s'intégrer socialement avec le projet, et la boucle est bouclée.

En fait, ce que tu dis, c'est que si on choisit un workflow comparable à Subversion, on n'a aucun problème, ce dont je suis absolument persuadé. Si je continue à utiliser ma comparaison avec le C, c'est comme si tu me disais qu'avec C, on peut bien coder, et je suis tout à fait d'accord. Il n'empêche qu'on peut mal coder en C et on peut utiliser git autrement que dans ce cas.

D'accord, du coup, je ne suis pas trop d'accord avec l'argument de l'auteur qui consiste à dire que c'est mieux. Au final, oui on voit que ça a été développé dans une branche mais bon, est-ce qu'il y a un intérêt supérieur à ça ?

Je reprends alors. D'un côté, tu as SVN qui peut faire des branches et des merges, et qui peut faire des changelists. Mais ces deux fonctionnalités sont considérés comme avancés (dans le svn book, elles sont dans un chapitre très éloigné du début) et personne ne les utilise, soit par peur ("c'est avancé, donc ça doit être dur"), soit par méconnaissance ("je ne lis pas les chapitres sur les utilisations avancés, j'en aurai pas besoin"). De l'autre côté, tu as git, qui peut faire des branches et des merges, et qui a une staging area qui permet plein de choses (dont l'équivalent des changelists). Là, ces deux fonctionnalités sont considérés comme basiques et apparaissent dans tous les turoriels, souvent au tout début pour la staging area. Donc les gens l'utilisent parce qu'ils connaissent ces fonctionnalités et qu'ils considèrent qu'elles font partie des fonctionnalités de base (donc faciles).

Je vais te faire la réponse que j'ai lue quelque part à propos d'un autre sujet : c'est dans la partie advanced topics (autant dire que personne ne le lit, et moi le premier, je n'avais jamais entendu parler de ça, ça n'apparaît dans aucun tutos SVN). Je l'ai lu sur les branches, qui sont considérées comme un fonctionnement normal dans git et comme un truc avancé dans SVN. Ici, la staging area, c'est sur la deuxième page de Git Reference (la première page, c'est git init et git clone, autant dire pas grand chose).

Ça veut dire que les diagrammes sont faux dans le billet du blog ?

C'est bien, tu décris exactement le comportement que je désapprouve dans mon argumentaire : le gars qui forke dans son coin sans rien dire au mainteneur. Les projets qui ouvrent leur dépôt ne sont pas si rares. Si on regarde KDE, qui n'est pas un petit projet, il me semble que les conditions pour avoir un accès au SVN ne sont pas si terrible [1], ça implique seulement de se conformer à une politique de commit, mais le compte SVN en lui-même n'est pas difficile à avoir.

[1] http://developer.kde.org/documentation/other/developer-faq.h(...)

Effectivement, ce modèle est assez complexe. Et personnellement, j'aurais inversé master et develop, c'est-à-dire que je ferais le développement dans master et que j'aurais une branche release. Et là me vient une question, est-ce que dans ce modèle, un tag ne suffirait-il pas ? Quelle est la nécessité d'avoir cette branche spécialement pour la release ? En fait, je me dis qu'un tag suffirait, et s'il y a besoin d'un hotfix, on crée une branche à ce moment là à partir du tag. Ça marche ça ?

Sinon, ça donne des idées d'organisation. Merci beaucoup.

La seule chose que je n'ai pas compris, c'est qu'il utilise --no-ff. Je vois vraiment pas l'intérêt. Est-ce qu'il ne perd pas toutes les micros étapes qu'il a fait dans la branche ? Du coup, quel intérêt de bien découper en micro étape (en plus, il insiste pour bien séparer) si tous les commits sont regroupés en un seul dans sa branche develop et qu'il supprime sa branche feature ? Bref, soit il y a qqch que je n'ai pas bien compris, soit il explique mal, soit il fait un truc idiot.

Merci pour toutes ces indications et pour le lien.

>> (Bon j'ai encore pondu un roman. Désolé pour le paté, j'espère que je n'ai pas noyé les potentielles informations importantes dans le bruit).

Ça m'aurait ennuyé que tu répondes en 140 caractères...

Je connaissais son existence mais là, l'idée, c'est de passer en 100% git, sinon ça va gâcher le plaisir...