Voilà de quoi atténuer la mauvaise réputation de Bitorrent, si des fournisseurs de contenu légal investisse la plateforme. En plus c'est bon pour la planète.
Il n'y a a aucune "comparaison", juste des faits que les intéressés ne contestent pas.
Mais bon que chacun balaye devant sa porte. Ce n'est pas comme si Renault n'avait pas été nationalisé en représailles pour avoir collaboré ou que Total n'était pas conciliant envers la junte birmane.
Bref, ne dit on pas que le capitalisme est amoral.
M$ n'est pas un plus vilain canard qu'un autre.
Oui IBM, c'est aussi la boîte qui file 3 missions au 4 coins de la France la même semaine lorsqu'elle veut se débarrasser d'un collaborateur.
IBM c'est la boîte qui s'est mise à faire libre que lorsqu'ils se sont fait shooter par M$ avec leur OS/2.
IBM c'est la boîte qui vend Clearcase la peau des couilles et veut surtout pas que RSM s'intègre correctement avec SVN pour pas perdre de marché.
IBM c'est la boite qui a sorti Jazz en promettant qu'il serait opensource et qui a finalement inventé un nouveau concept: l'open commercial. Ca fait "open" ca auprès des daicideurs. Vous testez pour nous et on vous vend le produit. Le beurre et l'argent du beurre.
IBM c'est aussi la boite qui a vendu des calculateurs aux nazis pendant la seconde guerre mondiale, ...
Faut arrêter d'idéaliser aussi !
Bref IBM c'est une boite comme une autre dans un système capitaliste.
Au hasard, craindre de brancher par crainte que ton refactoring eclipse ne pète tout lorsque tu réintègres dans le tronc et perdre au business loto lorsque tu entends "intégration continue" lors du prochain"ScrumMeeting" http://subversion.tigris.org/issues/show_bug.cgi?id=898
Tout ça plutôt que d'utiliser 1 branche par patch.
Oui et je vois la série du grand éditeur en question en 3e position, ce qui n'est pas vraiment rassurant.
L'auteur aurait pu faire preuve d'imagination en choisissant un autre titre comme je sais pas, par exemple [troll inside] Git for Dummies[/troll inside]
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Cette remarque est valable aussi pour un passage à Pylons.
Pour le reste, il n'y a donc aucune raison objective à ce fork.
Je trouve ca dommage pour l'avenir de CherryPy car plus aucun framework haut niveau sérieux ne s'appuie dessus.
Par ailleurs, tu sembles indiquer que la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort puisqu'on se pose la question de l'intégration de CherryPy3 à la branche 1.x et non 2.x.
Ca casse un peu le mythe non ?
Dans ce cas, autant prendre un bon framework tout-en-un ala Django.
C'est une vraie question pas une tentative de troll.
Les performances semblent être du côté de Git. Quoique pour gérer nos
30 fichiers cela ne devrait pas être trop pénalisant
...
- pas encore tester les IHMs (plugins Eclipse, TortoiseXXX). Je pense pourtant que la différence se fera dessus en ce qui nous concerne, notamment le support Windows.
Le support de Git pour Windows est encore balbutiant.
Jusqu'à peu, il fallait impérativement Cygwin
Aujourd'hui un port natif existe: http://code.google.com/p/msysgit/
mais il n'est pas encore réputé stable.
Enfin, au niveau des performances, attends toi à un décalage avec Linux
Les branches faciles priori à gérer pour Git. 3 ou 4 méthodes différentes pour Mercurial qui était pourtant censé être plus simple.
Détrompes toi, avec Mercurial, il faut juste intégrer le fait que plusieurs heads peuvent coexister dans une archive et qu'il faut les résoudre.
L'avantage c'est que tu n'es justement pas obligé de brancher lorsque tes besoin sont simples. (1 seul effort de developpement)
Tu clones, tu modifies, tu commites.
Tu pull, tu merges, tu commites
Les branches ne sont en fait qu'une étiquette que tu colles pour éviter de merger toutes les heads de ton archive lorsque tu as effectivement besoin de gestion parallèle.
Les branches s'apparentent à des "faisceaux" ou sous-graphes de commit
Avec Git la branche est une notion stricte. Une branche ne peut pas avoir 2 heads.
Git semble être la référence actuelle des SCM distribués. Autant travailler avec la référence.
Un conseil, ne fais pas la même remarque à propos de Windows et Linux ici ;-)
Pour savoir quel outil choisir vous devez connaitre leurs différences
Avec un DVCS, les branches sont incontournables.
Les branches sont les propriétés exclusives de chaque développeur.
Lorsque tu clones ou que tu te synchronises une archive, tu récupères les branches des autres mais tu ne dois pas travailler dans leurs branches car ces outils ne gèrent pas la concurrence d'accès à une branche. Tu dois donc forcément te créer une branche (ou un fork avec Mercurial) pour travailler puis merger le travail des autres dans ta propre branche. Chaque développeur est donc propriétaire d'une branche et la version de réference correspond à celle d'un unique intégrateur. C'est pourquoi on parle de modèle user-centric par rapport à repository-centric. Dans la pratique il est possible de pusher dans la branche des autres mais c'est avec le risque d 'avoir 2 versions différentes au lieu d'une seule HEAD.
Les outils centralisés gèrent la concurrence au niveau d'une branche au moment du commit. Il n'y a tjs qu'un HEAD mais il faut merger dans son worspace pour commiter si des versions intermédaires ont été commtées depuis le dernier update.
Le modèle DVCS ne prend pas en charge le schéma de concurrence pessimiste (lock/modify/unlock) et si ton projet comporte beaucoup de type de fichiers non mergeables (modèles UML fragmentés, artworks, XML, ...) ou que les développeurs préfèrent cette approche, les DVCS ne sont pas une bonne idée.
De même, l'intégration continue est plus complexe avec les DVCS puisque chacun bosse dans sa branche et qu'un integrateur est nécessaire.
C'est possible de le faire mais plus complexe.
Autre différence les DVCS ne suppportent pas les partial checkout. On ne peut pas extraire de sou-partie d'un projet mais ca n'est pas un problème puisque le checkout est très rapide (en local)
Les DVCS sont aussi très appréciables pour leur performances (Tout est en local et seules les synchro d'archives nécessitent des comms).
Il est aussi possible de commiter plusieurs change request en étant déconnecté.
Enfin leur gestion des branches est à des lieues de ce qu'est et ne sera pas SVN avant un moment.
SVN ne supporte pas le "true rename" et c'est repoussé sans arrêt.
La mémoire de merge n'est pas encore au point. http://subversion.tigris.org/issues/show_bug.cgi?id=898 http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Quel developpeur Eclipse n'appréhende pas le refactoring dans une branche
qui pourrira toutes les autre branches au moment du merge.
Il n'a souvent pas d'autre choix que de refaire le refactoring à la main dans chaque branche. On comprend que ca dissuade de brancher trop souvent.
Ceci est une époque révolue avec les DVCS qui sont basés sur des DAGs
Bref si pour vous les schéma de lock et l'intégration continue priment, gardez SVN sinon sautez le pas , d'autant que ca peut se faire en douceur car tous les DVCS savent se connecter à un depôt SVN.
A ma connaissance Bazaaar est le seul outils libre a supporter ces 2 modes nativement mais au prix d'une certaine lenteur par rapport à ces concurrents DVCS
J'étais un peu à la bourre et c'est pas super clair.
En résumé, l'oeuvre originale est en CC-BY-SA-NC-ND et est produite par un auteur unique.
Une exception a été donnée pour la dériver avec la même licence.
Mais cette fois-ci l'oeuvre est collective et donc dérivée en permanence par des forks.
Pour être cohérent, il aurait fallu CC-BY-SA-NC.
Mais là ca cassait la licence originale (SA)
Ca me parait un non-sens mais comme je l'ai dit je ne suis pas spécialiste en licence.
Il n'est donc pas surprenant qu'il ait fait le choix de NC-ND.
En donnant l'autorisation aux traducteurs, ceci ont reproduit la licence
qui est rendue caduque pour ce dérivé par l'ouverture à tout le monde.
Pour relire ou corriger je suis obligé de "dériver".
Il aurait fallu que les traducteurs demande à passer en NC mais ceci aurait cassé la licence originale.
Encore une démonstration de l'inapplicabilité des CC lorsqu'on fait des exceptions.
Ici, il semblerait que l'original tout comme la traduction soient le fruit d'une collaboration.
Ils sont hébergés sur GitHub, l'usine à fork par excellence, alors ca me parait quelques peu étrange comme choix.
Si quelqu'un veut rajouter un chapitre, reformuler un paragraphe, il n'a pas d'autre choix que de se soumettre à l'approbation du cercle des auteurs.
Ca me parait scabreux. Quand peut-t'on considérer qu'il y a dérivation d'une oeuvre collective si chacun peut se joindre à la communauté ?
Autant j'arrive à comprendre ce choix pour des oeuvres personnelles, autant pour des oeuvres collectives j'ai du mal à saisir l'intérêt.
Bref ca fait un peu genre:
Viendez mettre la main à la pâte mais c'est nous qui décidons ce qui est bien ou pas.
Honnêtement je trouve ce choix assez curieux mais je ne m'y connais pas assez en licence CC pour être affirmatif.
C'est vrai, mais je crois que le remarque sous-jacente était:
Est-ce vraiment utile de se lancer dans la traduction d'un bouquin technique en francais alors que l'audience comprend l'anglais.
Et là j'ai envie de répondre:
- Que la lecture d'un ouvrage en anglais reste malgré tout moins aisée et qu'une version francaise est souvent plus agréable et plus rapide pour une prise en main (Je parle de mon cas personnel)
- Qu'avec des remarques de ce style, les maisons d'édition spécialisées auraient déjà mis la clé sous la porte depuis longtemps.
- Que ceux qui font ce genre de remarques feraient mieux d'aller troller sur slashdot :O)
Certes mais les personnes vraiment concernées savent de quoi il en retourne.
Je salue cette initiative mais ce qui m'aurait personnellement plus intéressé est une présentation du projet de traduction en lui même (avancement de la traduction, processus de traduction, git, dockbook, ...)
et surtout comment participer à la traduction et à la relecture.
Toutes ces informations sont disponibles mais nécessitent quelques recherche que le lecteur pressé ne fera pas.
Ca aurait été bien de faire un how-to traducteur mais je n'ai peut-être pas bien cherché.
Enfin une question, pourquoi Git plutôt qu'un wiki ?
Autant je comprend l'auteur de l'original qui souhaite avoir une certaine maitrise sur son oeuvre autant pour la traduction je m'interroge.
[^] # Re: Bravo, en voilà de l'oecuménisme
Posté par nomorepost . En réponse à la dépêche L'INRIA créé un centre de recherche sur les logiciels libres. Évalué à 2.
Une solution de streaming P2P libre
http://www.numerama.com/magazine/14157-goalbit-une-solution-(...)
Voilà de quoi atténuer la mauvaise réputation de Bitorrent, si des fournisseurs de contenu légal investisse la plateforme. En plus c'est bon pour la planète.
[^] # Re: il est ou le blog de icaza ?
Posté par nomorepost . En réponse au journal La réponse de Miguel de Icaza à Richard Stallman. Évalué à 3.
[^] # Re: il est ou le blog de icaza ?
Posté par nomorepost . En réponse au journal La réponse de Miguel de Icaza à Richard Stallman. Évalué à 3.
Relis bien la définition
http://fr.wikipedia.org/wiki/Loi_de_Godwin
Il n'y a a aucune "comparaison", juste des faits que les intéressés ne contestent pas.
Mais bon que chacun balaye devant sa porte. Ce n'est pas comme si Renault n'avait pas été nationalisé en représailles pour avoir collaboré ou que Total n'était pas conciliant envers la junte birmane.
Bref, ne dit on pas que le capitalisme est amoral.
M$ n'est pas un plus vilain canard qu'un autre.
[^] # Re: Bravo, en voilà de l'oecuménisme
Posté par nomorepost . En réponse à la dépêche L'INRIA créé un centre de recherche sur les logiciels libres. Évalué à 2.
Je crois plutôt que ca illustrait le fait que M$ et LL ne sont pas toujours antagonistes, non ?
# Bravo, en voilà de l'oecuménisme
Posté par nomorepost . En réponse à la dépêche L'INRIA créé un centre de recherche sur les logiciels libres. Évalué à 6.
http://www.inria.fr/inria/crcmicrosoft/crcmicrosoft_presenta(...)
# Délectation ou luxure ?
Posté par nomorepost . En réponse au journal La guerre des trolls aura bien lieu. Évalué à 4.
Tu devrais poster plus souvent !
[^] # Re: il est ou le blog de icaza ?
Posté par nomorepost . En réponse au journal La réponse de Miguel de Icaza à Richard Stallman. Évalué à 6.
IBM c'est la boîte qui s'est mise à faire libre que lorsqu'ils se sont fait shooter par M$ avec leur OS/2.
IBM c'est la boîte qui vend Clearcase la peau des couilles et veut surtout pas que RSM s'intègre correctement avec SVN pour pas perdre de marché.
IBM c'est la boite qui a sorti Jazz en promettant qu'il serait opensource et qui a finalement inventé un nouveau concept: l'open commercial. Ca fait "open" ca auprès des daicideurs. Vous testez pour nous et on vous vend le produit. Le beurre et l'argent du beurre.
IBM c'est aussi la boite qui a vendu des calculateurs aux nazis pendant la seconde guerre mondiale, ...
Faut arrêter d'idéaliser aussi !
Bref IBM c'est une boite comme une autre dans un système capitaliste.
[^] # Re: Plein de branches
Posté par nomorepost . En réponse à la dépêche Turbogears 1.1 le même mais en mieux.. Évalué à 2.
C'est nettement plus alléchant que ton premier argument.
[^] # Re: Git c'est bon menjézan !
Posté par nomorepost . En réponse au journal Tutorial GIT. Évalué à 8.
http://subversion.tigris.org/issues/show_bug.cgi?id=898
Tout ça plutôt que d'utiliser 1 branche par patch.
Ou de ne pas faire de merges cycliques entre
2 branches de peur de passer ton temps à virer des svn:mergeinfo.
http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Ou bien de faire une overdose de caféine à chaque fois que tu lances 1 merge
sur un serveur distant
http://linuxfr.org/forums/12/27748.html
Ou encore être obligé de flageller les zouaves qui ont encore commité sous /tags
Ou bien râler après ce naze d'admin qui t'as pas encore créé ton repository alors que tes presta se tournent les pouces depuis une quinzaine
...
[^] # Re: lawsuit in a nutshell
Posté par nomorepost . En réponse au journal Tutorial GIT. Évalué à 3.
L'auteur aurait pu faire preuve d'imagination en choisissant un autre titre comme je sais pas, par exemple [troll inside] Git for Dummies[/troll inside]
[^] # Re: Plein de branches
Posté par nomorepost . En réponse à la dépêche Turbogears 1.1 le même mais en mieux.. Évalué à 6.
Premièrement, le passage de CherryPy 2 (utilisé dans TG 1.0/1.1) à CherryPy 3 est impossible sans casser la compatibilité.
Cette remarque est valable aussi pour un passage à Pylons.
Pour le reste, il n'y a donc aucune raison objective à ce fork.
Je trouve ca dommage pour l'avenir de CherryPy car plus aucun framework haut niveau sérieux ne s'appuie dessus.
Par ailleurs, tu sembles indiquer que la force de TG est l'interchangeabilité des composantes. Il semble que le couplage TG2.0/Pylons soit fort puisqu'on se pose la question de l'intégration de CherryPy3 à la branche 1.x et non 2.x.
Ca casse un peu le mythe non ?
Dans ce cas, autant prendre un bon framework tout-en-un ala Django.
C'est une vraie question pas une tentative de troll.
# lawsuit in a nutshell
Posté par nomorepost . En réponse au journal Tutorial GIT. Évalué à 2.
[^] # Re: Plein de branches
Posté par nomorepost . En réponse à la dépêche Turbogears 1.1 le même mais en mieux.. Évalué à 3.
CherryPy est pourtant un bon framework.
[^] # Re: Merci
Posté par nomorepost . En réponse au message Quel SCM ?. Évalué à 3.
Les performances semblent être du côté de Git. Quoique pour gérer nos
30 fichiers cela ne devrait pas être trop pénalisant
...
- pas encore tester les IHMs (plugins Eclipse, TortoiseXXX). Je pense pourtant que la différence se fera dessus en ce qui nous concerne, notamment le support Windows.
Le support de Git pour Windows est encore balbutiant.
Jusqu'à peu, il fallait impérativement Cygwin
Aujourd'hui un port natif existe:
http://code.google.com/p/msysgit/
mais il n'est pas encore réputé stable.
Enfin, au niveau des performances, attends toi à un décalage avec Linux
Les branches faciles priori à gérer pour Git. 3 ou 4 méthodes différentes pour Mercurial qui était pourtant censé être plus simple.
Détrompes toi, avec Mercurial, il faut juste intégrer le fait que plusieurs heads peuvent coexister dans une archive et qu'il faut les résoudre.
L'avantage c'est que tu n'es justement pas obligé de brancher lorsque tes besoin sont simples. (1 seul effort de developpement)
Tu clones, tu modifies, tu commites.
Tu pull, tu merges, tu commites
Les branches ne sont en fait qu'une étiquette que tu colles pour éviter de merger toutes les heads de ton archive lorsque tu as effectivement besoin de gestion parallèle.
Les branches s'apparentent à des "faisceaux" ou sous-graphes de commit
Avec Git la branche est une notion stricte. Une branche ne peut pas avoir 2 heads.
Git semble être la référence actuelle des SCM distribués. Autant travailler avec la référence.
Un conseil, ne fais pas la même remarque à propos de Windows et Linux ici ;-)
# DVCS vs VCS
Posté par nomorepost . En réponse au message Quel SCM ?. Évalué à 5.
Avec un DVCS, les branches sont incontournables.
Les branches sont les propriétés exclusives de chaque développeur.
Lorsque tu clones ou que tu te synchronises une archive, tu récupères les branches des autres mais tu ne dois pas travailler dans leurs branches car ces outils ne gèrent pas la concurrence d'accès à une branche. Tu dois donc forcément te créer une branche (ou un fork avec Mercurial) pour travailler puis merger le travail des autres dans ta propre branche. Chaque développeur est donc propriétaire d'une branche et la version de réference correspond à celle d'un unique intégrateur. C'est pourquoi on parle de modèle user-centric par rapport à repository-centric. Dans la pratique il est possible de pusher dans la branche des autres mais c'est avec le risque d 'avoir 2 versions différentes au lieu d'une seule HEAD.
Les outils centralisés gèrent la concurrence au niveau d'une branche au moment du commit. Il n'y a tjs qu'un HEAD mais il faut merger dans son worspace pour commiter si des versions intermédaires ont été commtées depuis le dernier update.
Le modèle DVCS ne prend pas en charge le schéma de concurrence pessimiste (lock/modify/unlock) et si ton projet comporte beaucoup de type de fichiers non mergeables (modèles UML fragmentés, artworks, XML, ...) ou que les développeurs préfèrent cette approche, les DVCS ne sont pas une bonne idée.
De même, l'intégration continue est plus complexe avec les DVCS puisque chacun bosse dans sa branche et qu'un integrateur est nécessaire.
C'est possible de le faire mais plus complexe.
Autre différence les DVCS ne suppportent pas les partial checkout. On ne peut pas extraire de sou-partie d'un projet mais ca n'est pas un problème puisque le checkout est très rapide (en local)
Les DVCS sont aussi très appréciables pour leur performances (Tout est en local et seules les synchro d'archives nécessitent des comms).
Il est aussi possible de commiter plusieurs change request en étant déconnecté.
Enfin leur gestion des branches est à des lieues de ce qu'est et ne sera pas SVN avant un moment.
SVN ne supporte pas le "true rename" et c'est repoussé sans arrêt.
La mémoire de merge n'est pas encore au point.
http://subversion.tigris.org/issues/show_bug.cgi?id=898
http://blogs.open.collab.net/svn/2008/07/subversion-merg.htm(...)
Quel developpeur Eclipse n'appréhende pas le refactoring dans une branche
qui pourrira toutes les autre branches au moment du merge.
Il n'a souvent pas d'autre choix que de refaire le refactoring à la main dans chaque branche. On comprend que ca dissuade de brancher trop souvent.
Ceci est une époque révolue avec les DVCS qui sont basés sur des DAGs
Bref si pour vous les schéma de lock et l'intégration continue priment, gardez SVN sinon sautez le pas , d'autant que ca peut se faire en douceur car tous les DVCS savent se connecter à un depôt SVN.
A ma connaissance Bazaaar est le seul outils libre a supporter ces 2 modes nativement mais au prix d'une certaine lenteur par rapport à ces concurrents DVCS
Good Luck
[^] # Re: Question Licence
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 2.
J'étais un peu à la bourre et c'est pas super clair.
En résumé, l'oeuvre originale est en CC-BY-SA-NC-ND et est produite par un auteur unique.
Une exception a été donnée pour la dériver avec la même licence.
Mais cette fois-ci l'oeuvre est collective et donc dérivée en permanence par des forks.
Pour être cohérent, il aurait fallu CC-BY-SA-NC.
Mais là ca cassait la licence originale (SA)
Ca me parait un non-sens mais comme je l'ai dit je ne suis pas spécialiste en licence.
C'est mieux là ?
[^] # Re: Lire l'anglais
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 2.
[^] # Re: Question Licence
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 3.
L'auteur de l'original est seul
http://github.com/sonatype/maven-guide-en/network
Il n'est donc pas surprenant qu'il ait fait le choix de NC-ND.
En donnant l'autorisation aux traducteurs, ceci ont reproduit la licence
qui est rendue caduque pour ce dérivé par l'ouverture à tout le monde.
Pour relire ou corriger je suis obligé de "dériver".
Il aurait fallu que les traducteurs demande à passer en NC mais ceci aurait cassé la licence originale.
Encore une démonstration de l'inapplicabilité des CC lorsqu'on fait des exceptions.
Ceux qui suivent peuvent confirmer ?
[^] # Re: Question Licence
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 4.
Ici, il semblerait que l'original tout comme la traduction soient le fruit d'une collaboration.
Ils sont hébergés sur GitHub, l'usine à fork par excellence, alors ca me parait quelques peu étrange comme choix.
Si quelqu'un veut rajouter un chapitre, reformuler un paragraphe, il n'a pas d'autre choix que de se soumettre à l'approbation du cercle des auteurs.
Ca me parait scabreux. Quand peut-t'on considérer qu'il y a dérivation d'une oeuvre collective si chacun peut se joindre à la communauté ?
Autant j'arrive à comprendre ce choix pour des oeuvres personnelles, autant pour des oeuvres collectives j'ai du mal à saisir l'intérêt.
Bref ca fait un peu genre:
Viendez mettre la main à la pâte mais c'est nous qui décidons ce qui est bien ou pas.
Honnêtement je trouve ce choix assez curieux mais je ne m'y connais pas assez en licence CC pour être affirmatif.
[^] # Re: Lire l'anglais
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 5.
Est-ce vraiment utile de se lancer dans la traduction d'un bouquin technique en francais alors que l'audience comprend l'anglais.
Et là j'ai envie de répondre:
- Que la lecture d'un ouvrage en anglais reste malgré tout moins aisée et qu'une version francaise est souvent plus agréable et plus rapide pour une prise en main (Je parle de mon cas personnel)
- Qu'avec des remarques de ce style, les maisons d'édition spécialisées auraient déjà mis la clé sous la porte depuis longtemps.
- Que ceux qui font ce genre de remarques feraient mieux d'aller troller sur slashdot :O)
# Question Licence
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 6.
[^] # Re: oui mais...
Posté par nomorepost . En réponse à la dépêche Première relecture publique de la traduction de Maven - The definitive guide. Évalué à 3.
Je salue cette initiative mais ce qui m'aurait personnellement plus intéressé est une présentation du projet de traduction en lui même (avancement de la traduction, processus de traduction, git, dockbook, ...)
et surtout comment participer à la traduction et à la relecture.
Toutes ces informations sont disponibles mais nécessitent quelques recherche que le lecteur pressé ne fera pas.
Alors voici quelques liens:
Le projet original:
http://github.com/sonatype/maven-guide-en
Pour la relecture:
La version online
http://maven-guide-fr.erwan-alliaume.com/site/reference/publ(...)
et le lien pour poster vos commentaires
http://github.com/ehsavoie/maven-guide-fr/issues
Pour la traduction:
L'utilisation des termes récurrents est une bonne idée pour apporter de la cohérence
http://wiki.github.com/ehsavoie/maven-guide-fr/termes-rcurre(...)
Pour l'avancement du projet:
http://wiki.github.com/ehsavoie/maven-guide-fr/qui-fait-quoi
Ca aurait été bien de faire un how-to traducteur mais je n'ai peut-être pas bien cherché.
Enfin une question, pourquoi Git plutôt qu'un wiki ?
Autant je comprend l'auteur de l'original qui souhaite avoir une certaine maitrise sur son oeuvre autant pour la traduction je m'interroge.
[^] # Re: C'est bizarre ....
Posté par nomorepost . En réponse au journal Expressions clichées. Évalué à 3.
# Mauvais titre
Posté par nomorepost . En réponse au journal Bouteille à la mer. Évalué à 3.
"La (bonne) mère prend de la bouteille"
[^] # Re: C'est bizarre ....
Posté par nomorepost . En réponse au journal Expressions clichées. Évalué à 2.