Comme il te l'a déjà été signalé, si tu as trouvé un bug, je t'invite à faire un rapport de bug. Par contre, la procédure pour Subversion est d'envoyer un rapport du bug, avec idéalement une recette pour le reproduire ("mettre en place un script pre-commit qui echo N lignes et exit 1, tenter un commit par svn://, ca devrait planter"), à dev (AT) subversion.tigris.org. Pas besoin d'être inscrit pour envoyer le mail, et on répond en te mettant en Cc, donc tu ne rateras rien de la conversation.
Si le bug est avéré et non-corrigé (tu n'as pas précisé la version du serveur utilisée d'ailleurs, ni le serveur utilisé (mod_dav_svn, svnserve, svn+ssh ?)), alors il sera soit corrigé à la volée, soit entré dans le bug-tracker s'il est non-trivial.
Dépêche toi, si tu fais un rapport maintenant il est possible de le corriger avant la sortie de Subversion 1.4.0, qui se fera d'ici la fin Juin. Si tu rates la 1.4, il faudra encore attendre 6 mois, ce serait dommage!
Si ca t'embête d'écrire en anglais, envois moi le rapport avec recette de reproduction en français sur mon email DLFP, je le traduirai et ferai suivre (ou je corrigerai le bug moi-même :-)
Voila voila.
Sinon, pour commenter le journal originel, je trouve ca super! J'avais justement besoin d'un tuto du genre pour buildbot, pour mettre en place une archi d'hébergement pour l'école! C'est une excellente initiative que d'écrire ce type de documentation. Je plussoie fortement :-)
Faut vraiment que je lise jusqu'au bout avant de répondre complètment a coté de la plaque. Il y a déjà une VM glulx implémentée par Andrew Plotkin, ainsi qu'une version du compilateur Inform 6 avec un backend produisant du code Glulx. Les deux ont le code source disponible, bien que je n'ai pas consulté la license pour l'instant, puisque je voulais m'auto-casser et me corriger avant que quelqu'un d'autre ne le fasse ;-)
Donc voila, vive glulx (avec tout de même les réserves exprimées ci-dessus), et le premier qui arrive à écrire un translator binaire traduisant du z-code en glulx, ben il gagne toute mon estime :-)
Tout à fait, Glulx est une tentative d'aller dans la bonne direction, et nous l'avions étudié brièvement alors que nous écrivions notre ZMachine avec mon ami.
Ce qui nous inquiète un peu, c'est que cette machine garde encore une structure et un comportement qui n'est pas sans rapeller celle de la ZMachine. Il est vrai qu'elle se défait d'un grand nombre des eccentricités génétiques de la machine d'Infocom, mais elle conserve tout de même cette impression de bancal de la ZMachine.
Ce qui lui manque également, et qui est absolument vital si on veut voir ce nouveau format de VM adopté largement, c'est un émulateur, où un mode d'émulation, pour la ZMachine. Je sais que c'est contraire à l'idée de se défaire de cette machine, mais si on oblige les auteurs d'IF à bazarder Inform et à apprendre un nouveau langage et une nouvelle VM tout d'un coup, c'est sans espoir que cela change. C'est pour cette raison que TADS n'attire que de nouveaux auteurs d'IF, alors que ceux qui ont touché à Inform passent rarement à TADS (et vice versa).
Si on permet aux auteurs Inform de se servir d'une machine Glulx, alors les machines Glulx se développeront assez rapidement, et on pourra espérer voir des anciens développeurs Inform passer à Glulx, petit à petit, tout en sachant qu'ils peuvent toujours faire tourner du z-code dessus en cas de besoin.
Bref, le premier qui écrit une VM Glulx, et un programme Glulx sachant interpréter du z-code (même si ca requiert une étape de compilation supplémentaire, pour traduire le z-code en glulx-code) gagne toute mon estime ;-)
La confiance nait de la liberté. Pour moi, un auteur freeware mérite beaucoup de choses, dont le respect et l'admiration s'il produit quelque chose de vraiment bon, mais il n'aura en guise de confiance qu'un sourire un peu nerveux. Il ne me fait pas confiance avec son code, pourquoi lui ferais-je confiance avec son binaire?
Par contre, +1 pour la liberté de l'IDE, je ne l'avais pas remarquée dans mon élan trollistique ;-). C'est un bon pas, et ca augmente ma confiance en l'intégralité du système, même si j'aimerais bien voire une implémentation des outils en ligne de commande (le coeur de l'application, qui intègre le compilateur inform 6 qui rend l'IDE utile) qui ne soit pas encombrée d'une licence douteuse. Mais ca semble se diriger par là, donc youpie!
Pour le coup, ca me donne limite envie d'implémenter un IDE linux :P
> De toute façon dans tous ces systèmes, on peut créer des jeux sans aucune restriction,
> et les créateurs des systèmes ne vont pas imposer des restrictions par la suite.
D'où provient précisément cette certitude? Je pensais que justement, le logiciel libre se veut garant de cette liberté. Tant qu'un système n'est pas libre, des restrictions peuvent être imposées du jour au lendemain.
En particulier, ce qui m'inquiète un tout petit peu, c'est Inform 7. Parce qu'en parcourant les pages, je vois ce qu'ils ont réussi à faire avec leur système de langage naturel, et je me dis "Ouah, si c'était payant, je serais prêt à l'acheter" (ce qui, pour moi, veut dire que c'est vraiment un bon truc). Et là, je m'arrête, et je me dis que si suffisament de gens disent ca, et le disent autrement que tout bas, ben un beau matin on pourrait se retrouver avec une démo 30 jours, qui aboutit sur "Inform 7 Pro" a 99$. Ca voudra dire quoi ce jour là, les belles phrases sur les intentions nobles de Graham Nelson? Ben ca voudra dire que si on veut créer, faudra payer.
Donc ouais, sur le principe, pour avoir causé un peu a Graham Nelson et aux autres impliqués, je suis d'accord que c'est improbable que des restrictions soient imposées dans les jours qui viennent. Mais je serais moins optimiste à plus long terme, étant donnée la nature humaine et, franchement, l'état d'esprit protectionniste à outrance qu'exprime le modèle freeware à mes yeux.
Couplé au problème que j'ai décrit un peu plus bas, concernant l'utilisation d'une machine virtuelle dont on a qu'une spécification reverse engineerée, bancale et vieillissante, il serait vraiment temps que le libre s'y mette et propose une alternative viable. D'autant plus qu'Inform 7 est une chance de ce coté là, puisqu'une interface d'édition en langage naturel nous donne un petit peu plus de liberté de changer la plateforme d'exécution sousjascente, du moment qu'on fait bien attention à supporter le mode de langage naturel d'Inform (plutot que de devoir supporter la structure infame de la zmachine).
Moi je vais faire le lourd sur un truc qui va vous sembler complètement con (bon, peut-être pas au fond, vu que je m'adresse a un public de geeks). C'est la machine qui fait tourner ces jeux d'aventure.
Je parle de la ZMachine, une machine virtuelle créée par Infocom dans les années 80, qui exécute des "programmes" en ZCode, qui sont en fait des aventures interactives. C'est un concept assez génial, surtout pour l'époque, parce que comme ca, Zork tournait sur Atari, Amiga, PC-386, bref, partout où Infocom avait porté la ZMachine.
Moi, ce qui me fait chier, ben c'est que la ZMachine commence sérieusement à montrer son age. Elle a été conçue par incréments successifs, aboutissant à 8 versions, toutes incompatibles entre elles. Ben oui, les standards ouverts et la compatibilité a l'époque, on s'en cognait: suffisait d'avoir une ZMachine v1 pour tel jeu, une ZMachine v3 pour tel autre... On savait meme pas que c'était des machines différentes!
Sauf qu'un jour, des gens se sont mis à reverse-engineerer le format zcode, pour en déduire finalement une spécification de la ZMachine. Enfin, des ZMachines.
Un ami et moi avons tenté de suivre cette spécification, pour se faire une ZMachine en python (ben quoi, c'est un trip comme un autre). Ben quelle horreur! Rien que la spécification, c'est un parcours du combattant pour la comprendre. Et une fois qu'on l'a comprise, ben on pleure en se demandant comment les concepteurs de la ZMachine ont pu créer un truc aussi horrible!
Bref, en voyant actuellement les spécifications de ce qui forme la base de la majorité des jeux de fiction intéractive de nos jours, j'en viens à me demander si on est pas tous assis au sommet d'un géant aux pieds d'argile.
Donc, tout ca pour me demander: La ZMachine, c'est franchement très bancal comme base (Et par extension, ZCode spa terrible non plus). TADS est un système propriétaire, dont on jouit pour l'instant de l'utilisation gratuite. C'est quand qu'on développe un vrai système d'IF digne du 21e siècle?
Voila, fin du vieux troll. Désolé, mais si vous aviez lutté 4 jours avec un ami (qui travaille chez google, c'est pas le cerveau qui manque) pour comprendre ne serais-ce que le début de la spec I/O d'une ZMachine, ben vous vous demanderiez aussi si un nouveau système ne serait pas à envisager :-)
Je suis entrain de négocier avec Lego pour voir si c'est OK pour le diffuser la maintenant tout de suite. Je suis encore sous NDA pour certains aspects, donc je préfère prendre mes précautions.
Mais je biperai en journal privé avec les keywords "Lego libre linux", ca te va? ;-)
Et puis pour participer, moi chuis pas contre, mais sans le kit, mon code t'apprendras pas grand chose pour l'instant. C'est pas mal de l'infrastructure necéssaire pour causer a la bestiole.
Je suis l'un des 100 membres du Mindstorm Developer Program, j'ai donc un kit de beta-test de la bestiole.
Pour l'instant, on a pas encore les sources du firmware (et ca fait bien chier de faire du reverse engineering), mais j'ai déjà développé une bibliothèque d'interaction avec la brique pour linux/bsd, utilisant Libusb. Avec, on peut flasher des firmwares, et utiliser le moniteur de boot pour débugger des conneries. Une fois qu'on aura un peu plus de specs, il devrait être possible d'uploader un moniteur de débuggage GDB, et là le fun pourra commencer :P
Voila voila. Juste pour dire que les pingouins ne sont pas en reste dans la phase de beta :)
1. Extraire le firmware officiel actuel
2. Calculer sa somme md5
3. Lorsque l'équipement de Free demande un contrôle du firmware, renvoyer la somme de contrôle calculée précédemment
4. Si l'équipement veut envoyer un nouveau firmware, le télécharger, calculer sa somme de contrôle, supprimer le nouveau firmware et utiliser la nouvelle somme de contrôle lors du reboot (toujours sur le meme firmware custom).
À moins d'avoir des composantes de crypto matérielles, dès lors que le firmware est compromis, toutes les sommes de contrôle du monde ne suffiront pas. Même si la validation du firmware se fait par signature numérique, tant qu'il n'y a pas un module TPM qui contrôle la clé et qui interdit la signature à un firmware inconnu, le contrôle peut être plombé.
C'est pas pour des prunes que les normes HDTV sont barbelées de crypto matérielle et de contraintes de sécurité brulées en ROM. Si c'était aussi simple que de faire confiance au truc au bout du cable pour se plier au protocole d'auth...
Bref, sur la v4, s'il n'y a pas de TPM, ou si le protocole ne repose pas sur des composantes matérielles assez spécifiques, ca devrait pouvoir se mascarader sans souci. Pour la fbx HDTV je m'inquiète un peu plus - si elle peut recevoir un flux HDTV, elle doit se conformer à toutes les normes comme HDMI (flux digital chiffré sur le fil), et donc à priori intégrer des mécanismes de DRM beaucoup plus poussés pour empêcher le bricolage du firmware.
My 2 cents. En tout cas, c'est un projet sympa. Je comprends les réticences de Free à l'ouverture du firmware, vu tout ce que ca implique au niveau de son infrastructure (équipement terminal pas reflashable = prévisibilité de l'équipement), mais c'est pas pour autant que je suis d'accord que c'est la bonne solution ;-)
De ces 8, 5 ont fini leur projet. Dans ces 5, 2 ont accompli "le minimum", et les 3 autres des 5 sont devenus développeurs du projet au dela du SoC. Des 8, 5 ont donc fini, et 3 n'ont pas fini.
Je serais un peu plus nuancé, mais globalement je suis d'accord. Ne voyez pas ca comme un bounty auquel vous souscrivez une fois, faites ni plus ni moins qu'une mission, et êtes payés. Enfin vous pouvez, mais c'est une vision assez tristement sordide de tout le machin.
Si possible, voyez plutôt cela comme une chance de vous lancer à fond dans le développement libre pendant 2 mois, avec les 4500$ qui viennent en substitution du salaire du boulot que vous ne faites pas à la place. Et pourquoi s'arrêter aux 2 mois, une fois que c'est fini?
Ce qui est recherché, ce sont des contributions au libre, mais dans l'espoir de vous y attirer pour le libre en lui-même, et non parce que c'est une vulgaire mission comme une autre.
Pour l'expérience perso, dans le projet Subversion 8 personnes ont été sélectionnées. De ces 8, 5 ont fini leur projet, et 3 sont restés à bord et sont maintenant des développeurs plus ou moins actifs dans le projet:
- L'un est développeur des bindings Ruby et "partial committer" de ces derniers (c'est à dire qu'il peut committer directement, mais uniquement dans les bindings Ruby)
- Un autre a obtenu l'accès full-commit, et a été embauché 6 mois plus tard par CollabNet au vu des capacités qu'il a montré pendant les 6 mois ou il développait,
- Le dernier, c'est moi; j'ai obtenu l'accès full-commit à l'issue de mon SoC, je suis actuellement Release Manager du projet, et ma participation et mon implication hors-SoC au projet à grandement contribué à me dénicher un stage qui poutre à développer du libre.
Enfin bref, voilà. En tant que mentors, je pense que la première chose que l'on recherche, ce sont des gens qui nous convainquent qu'ils sont capables de fournir ce qu'ils promettent, mais dans un second temps on sélectionne aussi par rapport à la motivation : avoir des mercenaires dans l'équipe n'est pas super bon pour l'ambiance, on préfère des gens qui font ce qu'ils font parce qu'ils sont passionnés.
C'est amusant, parce que c'est une question qui est revenue 5 fois en 24h sur le canal IRC du SoC. Et là réponse est toujours la même : tu penses à l'envers :-)
Prends le nombre d'heures/semaine que tu accepterais de consacrer à un SoC, multiplie par 2 mois, et propose un projet qui est réalisable dans ce temps.
Mais puisque tu veux des statistiques, je dirais que j'y travaillais entre 30 et 40 heures par semaine, avec d'assez grosses variations (certains jours 12h d'un coup, certaines semaines j'étais en rando et donc rien du tout).
Maintenant, le temps de travail dépend de tes capacités, et dépend également du projet que tu as à faire. Donc, j'en reviens à : tu, ainsi que les autres qui posent cette question, prennent la question à l'envers. Ce n'est pas un CDI avec le temps de travail écrit dans le contrat, c'est une expérience dans laquelle tu dois accomplir l'objectif que tu as toi-même proposé. À toi de voir comment cela se traduit en temps de travail.
Pour les impots, en fait, c'est un problème avec le système fiscal étasunien: si tu es un alien (non-citoyen américain) résident à l'étranger, et que tu te fais payer par une entreprise établie aux USA, tu est automatiquement taxé à hauteur de 30% du montant. Et donc, Google doit retenir 30% de ton paiement et les reverser eux-mêmes à l'IRS, a moins que tu ne puisses produire un formulaire (W8-BEN), qui atteste que tu es citoyen d'un pays qui a un traité fiscal avec les USA, qui te donnent alors droit à un taux d'imposition réduit, voire nul (c'est le cas pour la France, et pour le type de paiement que Google fait).
Alors après je te passe les histoires pour obtenir un ITIN (remplaçant d'un numéro de sécu pour les formulaires, si tu n'as pas droit a un numéro se sécu US), avec besoin de fournir la photocopie certifiée de l'oreille droite et du bras gauche, un autographe de johnny halliday contresigné par dieu en personne.... Et tout ça avec des delais de plusieurs mois par formulaire, ce qui rendait le tout très difficile à faire.
Alors cette année, Google a pu négocier avec l'IRS visiblement: eux ne retiendront rien, mais en contrepartie c'est à toi de te démerder pour prouver à l'IRS qu'ils ne sont pas obligés de venir te chercher avec une batte de baseball, et pour expliquer au gouvernement français qu'ils n'ont pas non plus à te prendre tes sous (ca c'est un peu plus facile).
Sinon, la structure d'accueil, ben... "Chez moi". Je crois qu'il y a un point à clarifier là: le summer of code ne fait absolument pas office de stage, ni de CDI, ni de CDD, ni de rien. C'est un vaste arrangement à l'amiable, avec une bourse versée en contrepartie de ta coopération avec un projet libre.
En tant que tel, faut pas espérer aller s'installer a Mountain View pour l'été, ou quoi que ce soit d'autre. Il n'y a pas de structure d'entreprise, puisque tu ne travailles pas pour une entreprise. Google est simplement celui qui détient les fonds de ta bourse, et te les versera une fois que tes mentors auront donné le feu vert.
Donc, le plus proche sosie du summer of code dans le milieu professionel, ca serait du télétravail. Mais du télétravail pour un projet libre, avec des gens éparpillés dans le monde entier, qui peuvent ou non avoir pignon sur rue. :-)
J'espère que c'est plus clair maintenant. C'est un accord tout ce qu'il y a de plus sympathique à mon humble avis, parce que ca te donne un goût de ce que ca donne de contribuer à un projet libre "comme tout le monde", sans traitement de faveur. Et en plus, le fait de ne pas être contraint à des horaires de bureau, ca fait qu'on est tout à fait libre d'allouer son temps comme il nous plait.
Petit paradoxe néanmoins, malgré le fait que ce ne soit pas un emploi dans le sens commun du terme, finir son summer of code peut compter comme expérience professionelle, au même titre qu'une mission en entreprise si on est un consultant indépendant.
Quand j'ai postulé, j'étais en fin de prépa intégrée dans mon école, donc en gros un niveau bac+2. Et à ce que je sais, il y a eu des candidatures acceptées pour tous les niveaux, de bac+0 à bac+7. Mais sachant que j'avais une éducation déjà bien baignée dans l'informatique bien avant ça, donc ce n'est peut-être pas représentatif.
Au niveau de ton stage, je ne crois pas que ça pose problème avec Google, tant que tu es encore officiellement inscrit comme étudiant auprès de ton IUT au début de la période "active" du SoC. Après, à toi de voir si tu peux tenir le rythme. Perso, j'estime que c'était globalement un travail de 6 à 8h par jour, mais des heures assez relax.
Sinon, pour les projets, un petit point pour ceux qui voudraient postuler : beaucoup d'organismes proposent des sujets, et se proposer pour en prendre un augmente ses chances d'être pris (à moins de proposer quelque chose qui est vraiment incroyablement innovant et utile au projet auquel personne n'a pensé). De plus, si un projet ne colle avec aucune des organisations mentor, on peut se faire mentorer par Google himself, mais inutile de dire qu'ils sont très sélectifs sur les projets retenus, et que proposer quelque chose qui intéresserait Google, c'est mieux (genre, un MMORPG, ils s'en foutent un peu quoi).
Petit retour d'expérience. J'ai fait le Summer of Code 2005, en bossant sur le projet Subversion. C'était vraiment une expérience fantastique, et je ne saurais trop la recommander à tout le monde.
Pour ma part, cela m'a permis de rejoindre le développement d'un projet libre, à une époque de l'année ou j'aurais construit des burgers à longueur de journée pour me faire un peu d'argent de poche.
En ce qui concerne le déroulement, les choses ont été encore simplifiées cette année. Notamment, l'an dernier Google retenait 30% de taxes sur votre paiement, a moins que vous ne puissiez produire les documents qui vont bien auprès de l'IRS, dans un délai très court. Cela a posé un grand nombre de problèmes, ce qui fait que cette année, Google a réussi a obtenir un meilleur deal: Ils ne retiendront rien du montant, et c'est à vous de déclarer la somme aux pays qui vont bien (astuce: la France, ainsi que pas mal d'autres pays d'europe, ont un traité avec les USA qui font que ce type de revenu est taxé à 0%). Bref, l'organisation a tiré les leçons des réussites et echecs de l'an dernier, et revient à la charge avec une machine bien mieux huilée!
Du coté des organisations, je ne peux parler vraiment que pour le projet Subversion, mais l'accueil était très chaleureux, nous étions très libres dans nos mouvements et dans ce que nous proposions, et globalement nous étions totalement intégrés à l'équipe de développement non-SoC. Cela a grandement contribué à ma participation au projet, et ce jusqu'a ce jour, puisque je suis actuellement Release Manager pour le projet.
Et pour conclure sur une petite parenthèse professionelle, pouvoir mettre "J'ai fait partie des 419 sélectionnés pour le Summer of Code, et j'ai fini mon projet" sur son CV est un atout formidable, bien plus que je ne le pensais. Je suis encore en plein dans mes études, mais rien que pour la recherche de stage, le Summer of Code m'a bien aidé, même longtemps après sa conclusion. Malgré sa relative jeunesse, c'est déjà devenu un certain gage de compétence auprès de beaucoup de professionnels.
Bref, le Summer of Code, c'est bon, mangez en! :-) Et sur une note plus perso, le projet Subversion se reprend au jeu cette année, et proposera bientôt une liste de projets de dimension adéquate qui nous intéressent. En raison de diverses circonstances, je risque de ne pas pouvoir candidater en tant qu'étudiant, mais je me ferai un plaisir de vous accueillir en tant que mentor ;-)
Ah, et au fait - Petite correction concernant le texte de la dépêche, par ailleurs excellent: il est bien vrai qu'il n'y a pas besoin d'être une organisation au sens juridique du terme pour devenir organisme mentor du Summer of Code. En revanche, le projet Subversion ne fait plus partie de cette catégorie: les développeurs se sont récemment regroupés et, avec la bénédiction complète de CollabNet (qui détient un copyright sur pas mal du code), ont formé une organisation non-profit, dans le but de pouvoir gérer de l'argent pour l'organisation d'événements, et d'avoir une assise légale plus conséquente pour défendre les trademarks du projet.
En pratique, ca ne change pas grand chose : CollabNet reste un grand contributeur au projet, et c'est son département juridique qui se chargera de défendre Subversion contre les abus (en vertu d'un accord passé entre CollabNet et l'organisation indépendante de Subversion). Néanmoins, c'est une étape dans la vie du projet, puisque nous avons maintenant une existence juridique propre, plutot que d'exister via une entreprise (qui n'a toujours oeuvré que pour le bien du projet, je tiens à le signaler).
Voilà. En rétrospective, ca fait deux gros paragraphes pour corriger une toute petite phrase, vous m'en excuserez - je me suis emporté :-)
Bah, remercions les. Avec des tissus de conneries pareil, l'emprunt temporaire et non-abusif d'une connexion à internet pour relever ses mails à l'arrache, il est à l'abri!
Merci FR2 donc de rassurer mes 4 voisins équipés de points d'accès wifi; merci d'ainsi venir à la défense de mes connexions internet de secours :-)
Oui, et j'aurais pu citer toutes les solutions d'hébergement qui proposent un hébergement sous Subversion (vous avez d'ailleurs oublié berlios.de et opensvn.csie.org). Mon but ici était de souligner quelque chose de tout autre.
Qu'on le veuille ou non, Sourceforge reste un indicateur majeur du libre (rien qu'au nombre de projets), et reste massivement plus grand que les autres. C'est donc une étape significative de l'acceptation de Subversion comme remplaçant de fait de CVS qui est entrain d'être franchie. Et, étant développeur Subversion, ben j'en suis plutot content.
Néanmoins, c'est effectivement vrai que j'ai pas pensé a Gna! et TuxFamily, merci donc d'apporter ces précisions. Si ce n'était pas clair par ma pique de fin de journal, je vous recommande plutot d'aller vous établir dans une autre grange, si vous vous trouvez dans l'éventualité de lancer un projet sous peu.
(Notez qu'il ne parle absolument pas des 100 000 sourceforgiens qui vont débarquer sur #svn avec "Namarchpaaaaaaaa", il aura de la Patience... :-)
Donc, à partir d'aujourd'hui, le cri des geeks c'est "gmail cassé chez vous aussi?", de la même manière que chez les pas geeks le cri c'est "msn cassé chez vous aussi?". Amusant. :-)
Mais bon, je concède que si on a pas laissé de backups de ses mails ailleurs, et qu'on se sert de gmail comme système principal, la mort de gmail c'est plus chiant.
Désolé, mais si, c'est quand même un peu pour lancer un troll, avoue ;-)
Je suis d'accord avec ton évaluation des licences. Simplement, j'ai parlé avec mes mots à moi, et dans mon système de valeurs une licence garantissant la liberté dans la durée et la totalité mérite plus l'apellation 'libre'. Toujours pour moi, la BSD est plus permissive, oui, mais pas plus libre.
Oui, ce ne sont que des nuances de vocabulaire sur lesquelles on pourrait s'entredéchirer pendant des mois. Mais comme je l'ai dit précédemment, c'est dans mon système de valeurs, et c'est totalement personel. À vous d'avoir le votre, peut-être différent du mien. Le mien m'a échappé dans mes formulations et est devenu un troll en lancement potentiel, ben "oups", c'était pas fait exprès.
Donc GPL, BSD, MPL, CCL (CoinCoin Licence), tout l'égout est dans la nature ;-)
En ce qui concerne les marques déposées, la question (à mon avis, IANAL) est de savoir quels recours légaux sont disponibles dans l'éventualité d'une violation. Est-ce qu'une marque déposée aux US peut faire valoir sa marque dans d'autres pays? Est-ce que mettre la contrainte dans la licence ne donne pas plus de poids juridique, puisqu'en cas de violation, les droits qui t'incombaient avant sont révoqués par l'acte même de transgression, plutot que par une décision de tribunal quelques mois plus tard?
Enfin j'en sais rien en fait, et je devrais arrêter d'énoncer des hypothèses qui doivent écorcher les oreilles de nos amis juristes :-)
Bref, voila, mea culpa sur le petit lapsus de conviction personelle, j'espère que ca ne partira pas en troll complet!
En effet, et c'est même une question posée par rapport au stockage de documents OpenOffice.org dans Subversion qui a amené la question de la façon de procéder. Comme dit ailleurs dans ces commentaires, les modules de diff spécialisés selon les types mime sont sur la feuille de route à long terme, mais pas prévu pour dans l'immédiat.
Le résultat, c'est qu'après une demi-douzaine de hacks proposés pour supporter explicitement le format OOo, il a été proposé autre chose, plus simple et offrant un gain pour plus de monde.
Debian a intégré à sa libz un patch ajoutant une option pour produire des fichiers compressés "rsyncable", c'est à dire ayant une empreinte changeante minimale, pour faciliter les rsync rapides. Il a été suggéré à OOo qu'ils intègrent cette modification algorithmique (qui devrait etre portable aux algos zip), ainsi les deltas entre deux versions d'un fichier se verraient grandement réduits. En le faisant à ce niveau là, le gain n'est pas seulement pour les utilisateurs de Subversion, mais pour la totalité des applications qui se causent en diffs.
Je comprends que cette solution puisse sembler être un passage de la patate chaude, mais il faut aussi voir le contexte : dans le cadre de la discussion sur "est-ce qu'il faudrait traiter les fichiers compressés spécialement?", il y a eu énormément de tentatives de pousser les développeurs à introduire un système similaire à Clearcase, ou tous les fichiers sont spéciaux et gérés différemment. Ca s'est terminé en un affront du type "soit on implémente la spécialisation des diffs maintenant, pour tout, soit on fait rien et on attend de pouvoir le faire correctement". C'est ce dernier, en combinaison avec une suggestion au projet OOo, qui a été retenue, et ce au moins jusqu'a ce que le merge tracking soit implémenté.
Donc, euh, voila. Donc l'état actuel, c'est que les fichiers compressés sont traités comme tous les autres (notez tout de même que c'est toujours mieux que CVS, puisqu'il y a un algo de diff binaire assez efficace), ce qui place Subversion à égalité avec beaucoup d'outils concurrents (à l'exception notable des plus gros, plus anciens et plus commerciaux). Et l'état futur, c'est que c'est l'une des montagnes à l'horizon que nous franchirons sur notre chemin :-)
Le fait que l'interface "par défaut" de Subversion refuse d'afficher les diff de fichiers binaires ne signifie pas que c'est impossible. On pourrait très bien imaginer un autre client (Comme TortoiseSVN par exemple) qui ferait pour les fichiers jpg un affichage visuel des différences entre le fichier d'origine et modifié.
Le problème en vient donc à l'impossibilité de spécialiser proprement le comportement pour les fichiers "binaires" (d'ailleurs, qu'est-ce qui est un fichier binaire? Cette question peut aussi être problématique parfois). On en revient donc au comportement proposé pour l'implémentation: pouvoir activer ou désactiver globalement le stockage du text-base pour une copie de travail. On peut imaginer par la suite un mode hybride, ou le non-stockage serait dicté par (au hasard) une propriété rattachée au fichier.
Dans tous les cas, si tu veux nous aider à trouver une définition qui te plaise au problème (et donc à la solution), je t'invite à venir en parler sur dev@subversion.tigris.org (mailing list de développement du projet), pour voir avec les développeurs spécialistes de la bibliothèque de gestion de la copie de travail où ca en est.
Cela est en effet prévu (spécialisation des algos de delta selon le type mime), mais pose encore toute une floppée de problèmes, et l'implémentation est déférrée à "après le merge tracking". C'est une feature prévue et désirée, mais de basse priorité pour l'instant.
Bien sur, si tu te sens l'âme de t'y mettre, je ne pense pas que (sauf excellente raison spécifique d'attendre) ca posera problème. Simplement, les développeurs actuels sont occupés sur d'autres choses.
Ne t'inquiète pas, maintenant que le backend FSFS est stabilisé et que le support du vérouillage est complet (introduit dans svn 1.2), le "merge tracking" est le prochain changement majeur (dans la catégorisation de mon article, ca serait dans la catégorie "über-changements", au dessus de "ameliorations majeures" ;-) prévu pour l'implémentation. Comme dirait l'un des fondateurs du projet "C'est la grosse montagne à l'horizon. Et on est sur le chemin qui y va."
Là encore, pour ceux qui trouvent que c'est lent, on est pas immobiles. Déjà, Collabnet organise d'ici quelques jours une réunion de ses gros clients, pour leur demander ce que eux, en tant que développeurs, entendent par "Gestion des merges" (on dirait peut-être pas, mais on peut implémenter une immense variété de comportements derrière ce nom vague, avec des dizaines d'UI possibles par implémentation). Une fois que nos développeurs de Collabnet (les seuls payés à plein temps pour subversion) ont le feedback des clients, la question sera posée aux utilisateurs de Subversion en général. Après, l'ensemble des résultats sera digéré, une spécification sera pondue, et l'implémentation démarera.
Juste une petite note concernant la procédure : la question est d'abord posée aux clients de Collabnet parce que nous pensons que leurs ingénieurs et chefs de projet sont à même de nous dire précisément et avec un minimum d'ambiguité ce qu'ils veulent, et que d'avoir quelques définitions claires pourrait aider le "grand public" libre à donner des réponses utiles, plutot que des tautologies du type "on veut un suivi des merges!". Ce n'est absolument pas pour favoriser les clients de Collabnet, et je peux vous assurer que les développeurs de Subversion non-employés par collabnet, une majorité dont je fais partie ne se laisseront pas faire (même s'il n'y a jamais eu besoin de se battre - Collabnet à toujours oeuvré dans le respect complet du "code moral" des projets libre).
Donc voilà, c'est en marche, mais je ne cache pas que cela prendra du temps. Et oui, je suis au courant que nombre de systèmes de contrôle de révision implémentent déjà quelque chose, mais nous préférons bien comprendre le problème avant d'implémenter une solution qui ne fait que la moitié de ce qu'on attend d'elle ;-) Mais réalistiquement, je ne pense pas qu'il faille s'y attendre avant subversion 1.6 au plus tôt (estimation powered by pifomètre, désolé). En attendant, l'utilisation de svnmerge et svk est recommandée pour la gestion des merges, ce sont de bons logiciels (et on se privera pas de leur piquer des idées le moment venu ;-)
Dans le spectre des licences, la licence de Subversion est proche de la licence Apache, qui elle est une licence dérivée de BSD. Bref, c'est une licence libérale, approuvée par l'OSI, qui permet de faire à peu près ce qu'on veut avec.
Les restrictions ont été ajoutées par Collabnet, l'entreprise qui a lancé le développement en 2000 (en embauchant Karl Fogel, expert CVS, et en lui disant "Tu vois CVS? Tu vois ce qui te plais pas? Code nous un CVS que tu aimerais utiliser" :). Ayant fait le pari de faire de leur SCM un projet entièrement libre, elle a tout de même ajouté des clauses pour protéger ses marques déposées (Collabnet et Tigris).
Donc, pour résumer, c'est pas aussi libre que la GPL, parce que Collabnet et d'autres veulent une licence type BSD pour pouvoir développer des composants propriétaires (pour Collabnet, c'est notamment les modules d'intégration à leur produit de groupware); mais c'est vraiment libre, d'après l'OSI et les DFSG (Debian Free Software Guidelines). J'ai un doute pour la FSF, donc je vais la fermer au lieu de risquer de dire une connerie. Allez vérifier :P
Le stockage des fichiers en double est un embêtement connu pour certains cas. Pour rappel, une copie de chaque fichier tel qu'il est dans le dépot (nommé text-base) est stockée dans .svn, et ce afin de pouvoir exécuter 'svn diff' (affiche les modifications locales sous forme de diff unifié) sans avoir de connexion au réseau.
Il est prévu à l'avenir de permettre la création d'une copie de travail sans ces text-base, pour avoir une copie de travail moins grosse, au prix de devoir avoir le réseau à disposition même pour les opérations triviales comme 'svn diff' ou 'svn status' (qui devrait demander au serveur pour pouvoir comparer).
L'implémentation de cette fonctionalité était également un projet Summer of Code d'ailleurs, mais la personne qui y a été affectée (qui était déjà un développeur Subversion) a préféré s'atteler à des problèmes plus urgents finalement, et donc ca n'a pas été terminé.
[^] # Re: Bug subversion
Posté par David Anderson . En réponse au journal Développer avec Subversion, Trac et Buildbot. Évalué à 8.
Si le bug est avéré et non-corrigé (tu n'as pas précisé la version du serveur utilisée d'ailleurs, ni le serveur utilisé (mod_dav_svn, svnserve, svn+ssh ?)), alors il sera soit corrigé à la volée, soit entré dans le bug-tracker s'il est non-trivial.
Dépêche toi, si tu fais un rapport maintenant il est possible de le corriger avant la sortie de Subversion 1.4.0, qui se fera d'ici la fin Juin. Si tu rates la 1.4, il faudra encore attendre 6 mois, ce serait dommage!
Si ca t'embête d'écrire en anglais, envois moi le rapport avec recette de reproduction en français sur mon email DLFP, je le traduirai et ferai suivre (ou je corrigerai le bug moi-même :-)
Voila voila.
Sinon, pour commenter le journal originel, je trouve ca super! J'avais justement besoin d'un tuto du genre pour buildbot, pour mettre en place une archi d'hébergement pour l'école! C'est une excellente initiative que d'écrire ce type de documentation. Je plussoie fortement :-)
[^] # Re: Z-code?!
Posté par David Anderson . En réponse au journal Sortie du système de création de jeux d'aventure Inform 7. Évalué à 3.
Donc voila, vive glulx (avec tout de même les réserves exprimées ci-dessus), et le premier qui arrive à écrire un translator binaire traduisant du z-code en glulx, ben il gagne toute mon estime :-)
[^] # Re: Z-code?!
Posté par David Anderson . En réponse au journal Sortie du système de création de jeux d'aventure Inform 7. Évalué à 2.
Ce qui nous inquiète un peu, c'est que cette machine garde encore une structure et un comportement qui n'est pas sans rapeller celle de la ZMachine. Il est vrai qu'elle se défait d'un grand nombre des eccentricités génétiques de la machine d'Infocom, mais elle conserve tout de même cette impression de bancal de la ZMachine.
Ce qui lui manque également, et qui est absolument vital si on veut voir ce nouveau format de VM adopté largement, c'est un émulateur, où un mode d'émulation, pour la ZMachine. Je sais que c'est contraire à l'idée de se défaire de cette machine, mais si on oblige les auteurs d'IF à bazarder Inform et à apprendre un nouveau langage et une nouvelle VM tout d'un coup, c'est sans espoir que cela change. C'est pour cette raison que TADS n'attire que de nouveaux auteurs d'IF, alors que ceux qui ont touché à Inform passent rarement à TADS (et vice versa).
Si on permet aux auteurs Inform de se servir d'une machine Glulx, alors les machines Glulx se développeront assez rapidement, et on pourra espérer voir des anciens développeurs Inform passer à Glulx, petit à petit, tout en sachant qu'ils peuvent toujours faire tourner du z-code dessus en cas de besoin.
Bref, le premier qui écrit une VM Glulx, et un programme Glulx sachant interpréter du z-code (même si ca requiert une étape de compilation supplémentaire, pour traduire le z-code en glulx-code) gagne toute mon estime ;-)
[^] # Re: Libre ?
Posté par David Anderson . En réponse au journal Sortie du système de création de jeux d'aventure Inform 7. Évalué à 2.
Par contre, +1 pour la liberté de l'IDE, je ne l'avais pas remarquée dans mon élan trollistique ;-). C'est un bon pas, et ca augmente ma confiance en l'intégralité du système, même si j'aimerais bien voire une implémentation des outils en ligne de commande (le coeur de l'application, qui intègre le compilateur inform 6 qui rend l'IDE utile) qui ne soit pas encombrée d'une licence douteuse. Mais ca semble se diriger par là, donc youpie!
Pour le coup, ca me donne limite envie d'implémenter un IDE linux :P
[^] # Re: Libre ?
Posté par David Anderson . En réponse au journal Sortie du système de création de jeux d'aventure Inform 7. Évalué à 4.
> et les créateurs des systèmes ne vont pas imposer des restrictions par la suite.
D'où provient précisément cette certitude? Je pensais que justement, le logiciel libre se veut garant de cette liberté. Tant qu'un système n'est pas libre, des restrictions peuvent être imposées du jour au lendemain.
En particulier, ce qui m'inquiète un tout petit peu, c'est Inform 7. Parce qu'en parcourant les pages, je vois ce qu'ils ont réussi à faire avec leur système de langage naturel, et je me dis "Ouah, si c'était payant, je serais prêt à l'acheter" (ce qui, pour moi, veut dire que c'est vraiment un bon truc). Et là, je m'arrête, et je me dis que si suffisament de gens disent ca, et le disent autrement que tout bas, ben un beau matin on pourrait se retrouver avec une démo 30 jours, qui aboutit sur "Inform 7 Pro" a 99$. Ca voudra dire quoi ce jour là, les belles phrases sur les intentions nobles de Graham Nelson? Ben ca voudra dire que si on veut créer, faudra payer.
Donc ouais, sur le principe, pour avoir causé un peu a Graham Nelson et aux autres impliqués, je suis d'accord que c'est improbable que des restrictions soient imposées dans les jours qui viennent. Mais je serais moins optimiste à plus long terme, étant donnée la nature humaine et, franchement, l'état d'esprit protectionniste à outrance qu'exprime le modèle freeware à mes yeux.
Couplé au problème que j'ai décrit un peu plus bas, concernant l'utilisation d'une machine virtuelle dont on a qu'une spécification reverse engineerée, bancale et vieillissante, il serait vraiment temps que le libre s'y mette et propose une alternative viable. D'autant plus qu'Inform 7 est une chance de ce coté là, puisqu'une interface d'édition en langage naturel nous donne un petit peu plus de liberté de changer la plateforme d'exécution sousjascente, du moment qu'on fait bien attention à supporter le mode de langage naturel d'Inform (plutot que de devoir supporter la structure infame de la zmachine).
# Z-code?!
Posté par David Anderson . En réponse au journal Sortie du système de création de jeux d'aventure Inform 7. Évalué à 2.
Je parle de la ZMachine, une machine virtuelle créée par Infocom dans les années 80, qui exécute des "programmes" en ZCode, qui sont en fait des aventures interactives. C'est un concept assez génial, surtout pour l'époque, parce que comme ca, Zork tournait sur Atari, Amiga, PC-386, bref, partout où Infocom avait porté la ZMachine.
Moi, ce qui me fait chier, ben c'est que la ZMachine commence sérieusement à montrer son age. Elle a été conçue par incréments successifs, aboutissant à 8 versions, toutes incompatibles entre elles. Ben oui, les standards ouverts et la compatibilité a l'époque, on s'en cognait: suffisait d'avoir une ZMachine v1 pour tel jeu, une ZMachine v3 pour tel autre... On savait meme pas que c'était des machines différentes!
Sauf qu'un jour, des gens se sont mis à reverse-engineerer le format zcode, pour en déduire finalement une spécification de la ZMachine. Enfin, des ZMachines.
Un ami et moi avons tenté de suivre cette spécification, pour se faire une ZMachine en python (ben quoi, c'est un trip comme un autre). Ben quelle horreur! Rien que la spécification, c'est un parcours du combattant pour la comprendre. Et une fois qu'on l'a comprise, ben on pleure en se demandant comment les concepteurs de la ZMachine ont pu créer un truc aussi horrible!
Bref, en voyant actuellement les spécifications de ce qui forme la base de la majorité des jeux de fiction intéractive de nos jours, j'en viens à me demander si on est pas tous assis au sommet d'un géant aux pieds d'argile.
Donc, tout ca pour me demander: La ZMachine, c'est franchement très bancal comme base (Et par extension, ZCode spa terrible non plus). TADS est un système propriétaire, dont on jouit pour l'instant de l'utilisation gratuite. C'est quand qu'on développe un vrai système d'IF digne du 21e siècle?
Voila, fin du vieux troll. Désolé, mais si vous aviez lutté 4 jours avec un ami (qui travaille chez google, c'est pas le cerveau qui manque) pour comprendre ne serais-ce que le début de la spec I/O d'une ZMachine, ben vous vous demanderiez aussi si un nouveau système ne serait pas à envisager :-)
[^] # Re: Pensées d'un membre MDP
Posté par David Anderson . En réponse au journal Lego, te voila enfin !. Évalué à 2.
Mais je biperai en journal privé avec les keywords "Lego libre linux", ca te va? ;-)
Et puis pour participer, moi chuis pas contre, mais sans le kit, mon code t'apprendras pas grand chose pour l'instant. C'est pas mal de l'infrastructure necéssaire pour causer a la bestiole.
# Pensées d'un membre MDP
Posté par David Anderson . En réponse au journal Lego, te voila enfin !. Évalué à 7.
Pour l'instant, on a pas encore les sources du firmware (et ca fait bien chier de faire du reverse engineering), mais j'ai déjà développé une bibliothèque d'interaction avec la brique pour linux/bsd, utilisant Libusb. Avec, on peut flasher des firmwares, et utiliser le moniteur de boot pour débugger des conneries. Une fois qu'on aura un peu plus de specs, il devrait être possible d'uploader un moniteur de débuggage GDB, et là le fun pourra commencer :P
Voila voila. Juste pour dire que les pingouins ne sont pas en reste dans la phase de beta :)
[^] # Re: Sacré boulot...
Posté par David Anderson . En réponse à la dépêche Modifier le firmware d'une Freebox grâce à OpenFreeBox. Évalué à 10.
2. Calculer sa somme md5
3. Lorsque l'équipement de Free demande un contrôle du firmware, renvoyer la somme de contrôle calculée précédemment
4. Si l'équipement veut envoyer un nouveau firmware, le télécharger, calculer sa somme de contrôle, supprimer le nouveau firmware et utiliser la nouvelle somme de contrôle lors du reboot (toujours sur le meme firmware custom).
À moins d'avoir des composantes de crypto matérielles, dès lors que le firmware est compromis, toutes les sommes de contrôle du monde ne suffiront pas. Même si la validation du firmware se fait par signature numérique, tant qu'il n'y a pas un module TPM qui contrôle la clé et qui interdit la signature à un firmware inconnu, le contrôle peut être plombé.
C'est pas pour des prunes que les normes HDTV sont barbelées de crypto matérielle et de contraintes de sécurité brulées en ROM. Si c'était aussi simple que de faire confiance au truc au bout du cable pour se plier au protocole d'auth...
Bref, sur la v4, s'il n'y a pas de TPM, ou si le protocole ne repose pas sur des composantes matérielles assez spécifiques, ca devrait pouvoir se mascarader sans souci. Pour la fbx HDTV je m'inquiète un peu plus - si elle peut recevoir un flux HDTV, elle doit se conformer à toutes les normes comme HDMI (flux digital chiffré sur le fil), et donc à priori intégrer des mécanismes de DRM beaucoup plus poussés pour empêcher le bricolage du firmware.
My 2 cents. En tout cas, c'est un projet sympa. Je comprends les réticences de Free à l'ouverture du firmware, vu tout ce que ca implique au niveau de son infrastructure (équipement terminal pas reflashable = prévisibilité de l'équipement), mais c'est pas pour autant que je suis d'accord que c'est la bonne solution ;-)
[^] # Re: Une expérience fantastique et valorisante
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 2.
Mieux? :-)
[^] # Re: Une expérience fantastique et valorisante
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 5.
Si possible, voyez plutôt cela comme une chance de vous lancer à fond dans le développement libre pendant 2 mois, avec les 4500$ qui viennent en substitution du salaire du boulot que vous ne faites pas à la place. Et pourquoi s'arrêter aux 2 mois, une fois que c'est fini?
Ce qui est recherché, ce sont des contributions au libre, mais dans l'espoir de vous y attirer pour le libre en lui-même, et non parce que c'est une vulgaire mission comme une autre.
Pour l'expérience perso, dans le projet Subversion 8 personnes ont été sélectionnées. De ces 8, 5 ont fini leur projet, et 3 sont restés à bord et sont maintenant des développeurs plus ou moins actifs dans le projet:
- L'un est développeur des bindings Ruby et "partial committer" de ces derniers (c'est à dire qu'il peut committer directement, mais uniquement dans les bindings Ruby)
- Un autre a obtenu l'accès full-commit, et a été embauché 6 mois plus tard par CollabNet au vu des capacités qu'il a montré pendant les 6 mois ou il développait,
- Le dernier, c'est moi; j'ai obtenu l'accès full-commit à l'issue de mon SoC, je suis actuellement Release Manager du projet, et ma participation et mon implication hors-SoC au projet à grandement contribué à me dénicher un stage qui poutre à développer du libre.
Enfin bref, voilà. En tant que mentors, je pense que la première chose que l'on recherche, ce sont des gens qui nous convainquent qu'ils sont capables de fournir ce qu'ils promettent, mais dans un second temps on sélectionne aussi par rapport à la motivation : avoir des mercenaires dans l'équipe n'est pas super bon pour l'ambiance, on préfère des gens qui font ce qu'ils font parce qu'ils sont passionnés.
[^] # Re: temps
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 9.
Prends le nombre d'heures/semaine que tu accepterais de consacrer à un SoC, multiplie par 2 mois, et propose un projet qui est réalisable dans ce temps.
Mais puisque tu veux des statistiques, je dirais que j'y travaillais entre 30 et 40 heures par semaine, avec d'assez grosses variations (certains jours 12h d'un coup, certaines semaines j'étais en rando et donc rien du tout).
Maintenant, le temps de travail dépend de tes capacités, et dépend également du projet que tu as à faire. Donc, j'en reviens à : tu, ainsi que les autres qui posent cette question, prennent la question à l'envers. Ce n'est pas un CDI avec le temps de travail écrit dans le contrat, c'est une expérience dans laquelle tu dois accomplir l'objectif que tu as toi-même proposé. À toi de voir comment cela se traduit en temps de travail.
[^] # Re: La structure d'accueil
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 10.
Alors après je te passe les histoires pour obtenir un ITIN (remplaçant d'un numéro de sécu pour les formulaires, si tu n'as pas droit a un numéro se sécu US), avec besoin de fournir la photocopie certifiée de l'oreille droite et du bras gauche, un autographe de johnny halliday contresigné par dieu en personne.... Et tout ça avec des delais de plusieurs mois par formulaire, ce qui rendait le tout très difficile à faire.
Alors cette année, Google a pu négocier avec l'IRS visiblement: eux ne retiendront rien, mais en contrepartie c'est à toi de te démerder pour prouver à l'IRS qu'ils ne sont pas obligés de venir te chercher avec une batte de baseball, et pour expliquer au gouvernement français qu'ils n'ont pas non plus à te prendre tes sous (ca c'est un peu plus facile).
Sinon, la structure d'accueil, ben... "Chez moi". Je crois qu'il y a un point à clarifier là: le summer of code ne fait absolument pas office de stage, ni de CDI, ni de CDD, ni de rien. C'est un vaste arrangement à l'amiable, avec une bourse versée en contrepartie de ta coopération avec un projet libre.
En tant que tel, faut pas espérer aller s'installer a Mountain View pour l'été, ou quoi que ce soit d'autre. Il n'y a pas de structure d'entreprise, puisque tu ne travailles pas pour une entreprise. Google est simplement celui qui détient les fonds de ta bourse, et te les versera une fois que tes mentors auront donné le feu vert.
Donc, le plus proche sosie du summer of code dans le milieu professionel, ca serait du télétravail. Mais du télétravail pour un projet libre, avec des gens éparpillés dans le monde entier, qui peuvent ou non avoir pignon sur rue. :-)
J'espère que c'est plus clair maintenant. C'est un accord tout ce qu'il y a de plus sympathique à mon humble avis, parce que ca te donne un goût de ce que ca donne de contribuer à un projet libre "comme tout le monde", sans traitement de faveur. Et en plus, le fait de ne pas être contraint à des horaires de bureau, ca fait qu'on est tout à fait libre d'allouer son temps comme il nous plait.
Petit paradoxe néanmoins, malgré le fait que ce ne soit pas un emploi dans le sens commun du terme, finir son summer of code peut compter comme expérience professionelle, au même titre qu'une mission en entreprise si on est un consultant indépendant.
[^] # Re: Une expérience fantastique et valorisante
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 6.
Au niveau de ton stage, je ne crois pas que ça pose problème avec Google, tant que tu es encore officiellement inscrit comme étudiant auprès de ton IUT au début de la période "active" du SoC. Après, à toi de voir si tu peux tenir le rythme. Perso, j'estime que c'était globalement un travail de 6 à 8h par jour, mais des heures assez relax.
Sinon, pour les projets, un petit point pour ceux qui voudraient postuler : beaucoup d'organismes proposent des sujets, et se proposer pour en prendre un augmente ses chances d'être pris (à moins de proposer quelque chose qui est vraiment incroyablement innovant et utile au projet auquel personne n'a pensé). De plus, si un projet ne colle avec aucune des organisations mentor, on peut se faire mentorer par Google himself, mais inutile de dire qu'ils sont très sélectifs sur les projets retenus, et que proposer quelque chose qui intéresserait Google, c'est mieux (genre, un MMORPG, ils s'en foutent un peu quoi).
Voilà voilà :-)
# Une expérience fantastique et valorisante
Posté par David Anderson . En réponse à la dépêche Le Google Summer of Code 2006 arrive !. Évalué à 10.
Pour ma part, cela m'a permis de rejoindre le développement d'un projet libre, à une époque de l'année ou j'aurais construit des burgers à longueur de journée pour me faire un peu d'argent de poche.
En ce qui concerne le déroulement, les choses ont été encore simplifiées cette année. Notamment, l'an dernier Google retenait 30% de taxes sur votre paiement, a moins que vous ne puissiez produire les documents qui vont bien auprès de l'IRS, dans un délai très court. Cela a posé un grand nombre de problèmes, ce qui fait que cette année, Google a réussi a obtenir un meilleur deal: Ils ne retiendront rien du montant, et c'est à vous de déclarer la somme aux pays qui vont bien (astuce: la France, ainsi que pas mal d'autres pays d'europe, ont un traité avec les USA qui font que ce type de revenu est taxé à 0%). Bref, l'organisation a tiré les leçons des réussites et echecs de l'an dernier, et revient à la charge avec une machine bien mieux huilée!
Du coté des organisations, je ne peux parler vraiment que pour le projet Subversion, mais l'accueil était très chaleureux, nous étions très libres dans nos mouvements et dans ce que nous proposions, et globalement nous étions totalement intégrés à l'équipe de développement non-SoC. Cela a grandement contribué à ma participation au projet, et ce jusqu'a ce jour, puisque je suis actuellement Release Manager pour le projet.
Et pour conclure sur une petite parenthèse professionelle, pouvoir mettre "J'ai fait partie des 419 sélectionnés pour le Summer of Code, et j'ai fini mon projet" sur son CV est un atout formidable, bien plus que je ne le pensais. Je suis encore en plein dans mes études, mais rien que pour la recherche de stage, le Summer of Code m'a bien aidé, même longtemps après sa conclusion. Malgré sa relative jeunesse, c'est déjà devenu un certain gage de compétence auprès de beaucoup de professionnels.
Bref, le Summer of Code, c'est bon, mangez en! :-) Et sur une note plus perso, le projet Subversion se reprend au jeu cette année, et proposera bientôt une liste de projets de dimension adéquate qui nous intéressent. En raison de diverses circonstances, je risque de ne pas pouvoir candidater en tant qu'étudiant, mais je me ferai un plaisir de vous accueillir en tant que mentor ;-)
Ah, et au fait - Petite correction concernant le texte de la dépêche, par ailleurs excellent: il est bien vrai qu'il n'y a pas besoin d'être une organisation au sens juridique du terme pour devenir organisme mentor du Summer of Code. En revanche, le projet Subversion ne fait plus partie de cette catégorie: les développeurs se sont récemment regroupés et, avec la bénédiction complète de CollabNet (qui détient un copyright sur pas mal du code), ont formé une organisation non-profit, dans le but de pouvoir gérer de l'argent pour l'organisation d'événements, et d'avoir une assise légale plus conséquente pour défendre les trademarks du projet.
En pratique, ca ne change pas grand chose : CollabNet reste un grand contributeur au projet, et c'est son département juridique qui se chargera de défendre Subversion contre les abus (en vertu d'un accord passé entre CollabNet et l'organisation indépendante de Subversion). Néanmoins, c'est une étape dans la vie du projet, puisque nous avons maintenant une existence juridique propre, plutot que d'exister via une entreprise (qui n'a toujours oeuvré que pour le bien du projet, je tiens à le signaler).
Voilà. En rétrospective, ca fait deux gros paragraphes pour corriger une toute petite phrase, vous m'en excuserez - je me suis emporté :-)
# Boarf
Posté par David Anderson . En réponse au journal Les conflits d'intérêt. Évalué à 4.
Merci FR2 donc de rassurer mes 4 voisins équipés de points d'accès wifi; merci d'ainsi venir à la défense de mes connexions internet de secours :-)
[^] # Re: Ainsi que...
Posté par David Anderson . En réponse au journal Subversion bientot sur SF.net!. Évalué à 8.
Qu'on le veuille ou non, Sourceforge reste un indicateur majeur du libre (rien qu'au nombre de projets), et reste massivement plus grand que les autres. C'est donc une étape significative de l'acceptation de Subversion comme remplaçant de fait de CVS qui est entrain d'être franchie. Et, étant développeur Subversion, ben j'en suis plutot content.
Néanmoins, c'est effectivement vrai que j'ai pas pensé a Gna! et TuxFamily, merci donc d'apporter ces précisions. Si ce n'était pas clair par ma pique de fin de journal, je vous recommande plutot d'aller vous établir dans une autre grange, si vous vous trouvez dans l'éventualité de lancer un projet sous peu.
(Notez qu'il ne parle absolument pas des 100 000 sourceforgiens qui vont débarquer sur #svn avec "Namarchpaaaaaaaa", il aura de la Patience... :-)
# Wokay...
Posté par David Anderson . En réponse au journal GMail dans les choux ?. Évalué à 10.
Mais bon, je concède que si on a pas laissé de backups de ses mails ailleurs, et qu'on se sert de gmail comme système principal, la mort de gmail c'est plus chiant.
[^] # Re: Type de license?
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 3.
Je suis d'accord avec ton évaluation des licences. Simplement, j'ai parlé avec mes mots à moi, et dans mon système de valeurs une licence garantissant la liberté dans la durée et la totalité mérite plus l'apellation 'libre'. Toujours pour moi, la BSD est plus permissive, oui, mais pas plus libre.
Oui, ce ne sont que des nuances de vocabulaire sur lesquelles on pourrait s'entredéchirer pendant des mois. Mais comme je l'ai dit précédemment, c'est dans mon système de valeurs, et c'est totalement personel. À vous d'avoir le votre, peut-être différent du mien. Le mien m'a échappé dans mes formulations et est devenu un troll en lancement potentiel, ben "oups", c'était pas fait exprès.
Donc GPL, BSD, MPL, CCL (CoinCoin Licence), tout l'égout est dans la nature ;-)
En ce qui concerne les marques déposées, la question (à mon avis, IANAL) est de savoir quels recours légaux sont disponibles dans l'éventualité d'une violation. Est-ce qu'une marque déposée aux US peut faire valoir sa marque dans d'autres pays? Est-ce que mettre la contrainte dans la licence ne donne pas plus de poids juridique, puisqu'en cas de violation, les droits qui t'incombaient avant sont révoqués par l'acte même de transgression, plutot que par une décision de tribunal quelques mois plus tard?
Enfin j'en sais rien en fait, et je devrais arrêter d'énoncer des hypothèses qui doivent écorcher les oreilles de nos amis juristes :-)
Bref, voila, mea culpa sur le petit lapsus de conviction personelle, j'espère que ca ne partira pas en troll complet!
[^] # Re: Felicitations a ttes l'équipe !
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 5.
Le résultat, c'est qu'après une demi-douzaine de hacks proposés pour supporter explicitement le format OOo, il a été proposé autre chose, plus simple et offrant un gain pour plus de monde.
Debian a intégré à sa libz un patch ajoutant une option pour produire des fichiers compressés "rsyncable", c'est à dire ayant une empreinte changeante minimale, pour faciliter les rsync rapides. Il a été suggéré à OOo qu'ils intègrent cette modification algorithmique (qui devrait etre portable aux algos zip), ainsi les deltas entre deux versions d'un fichier se verraient grandement réduits. En le faisant à ce niveau là, le gain n'est pas seulement pour les utilisateurs de Subversion, mais pour la totalité des applications qui se causent en diffs.
Je comprends que cette solution puisse sembler être un passage de la patate chaude, mais il faut aussi voir le contexte : dans le cadre de la discussion sur "est-ce qu'il faudrait traiter les fichiers compressés spécialement?", il y a eu énormément de tentatives de pousser les développeurs à introduire un système similaire à Clearcase, ou tous les fichiers sont spéciaux et gérés différemment. Ca s'est terminé en un affront du type "soit on implémente la spécialisation des diffs maintenant, pour tout, soit on fait rien et on attend de pouvoir le faire correctement". C'est ce dernier, en combinaison avec une suggestion au projet OOo, qui a été retenue, et ce au moins jusqu'a ce que le merge tracking soit implémenté.
Donc, euh, voila. Donc l'état actuel, c'est que les fichiers compressés sont traités comme tous les autres (notez tout de même que c'est toujours mieux que CVS, puisqu'il y a un algo de diff binaire assez efficace), ce qui place Subversion à égalité avec beaucoup d'outils concurrents (à l'exception notable des plus gros, plus anciens et plus commerciaux). Et l'état futur, c'est que c'est l'une des montagnes à l'horizon que nous franchirons sur notre chemin :-)
[^] # Re: Felicitations a ttes l'équipe !
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 3.
Le problème en vient donc à l'impossibilité de spécialiser proprement le comportement pour les fichiers "binaires" (d'ailleurs, qu'est-ce qui est un fichier binaire? Cette question peut aussi être problématique parfois). On en revient donc au comportement proposé pour l'implémentation: pouvoir activer ou désactiver globalement le stockage du text-base pour une copie de travail. On peut imaginer par la suite un mode hybride, ou le non-stockage serait dicté par (au hasard) une propriété rattachée au fichier.
Dans tous les cas, si tu veux nous aider à trouver une définition qui te plaise au problème (et donc à la solution), je t'invite à venir en parler sur dev@subversion.tigris.org (mailing list de développement du projet), pour voir avec les développeurs spécialistes de la bibliothèque de gestion de la copie de travail où ca en est.
[^] # Re: Felicitations a ttes l'équipe !
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 3.
Bien sur, si tu te sens l'âme de t'y mettre, je ne pense pas que (sauf excellente raison spécifique d'attendre) ca posera problème. Simplement, les développeurs actuels sont occupés sur d'autres choses.
[^] # Re: Et un vrai systeme de merge ?
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 10.
Là encore, pour ceux qui trouvent que c'est lent, on est pas immobiles. Déjà, Collabnet organise d'ici quelques jours une réunion de ses gros clients, pour leur demander ce que eux, en tant que développeurs, entendent par "Gestion des merges" (on dirait peut-être pas, mais on peut implémenter une immense variété de comportements derrière ce nom vague, avec des dizaines d'UI possibles par implémentation). Une fois que nos développeurs de Collabnet (les seuls payés à plein temps pour subversion) ont le feedback des clients, la question sera posée aux utilisateurs de Subversion en général. Après, l'ensemble des résultats sera digéré, une spécification sera pondue, et l'implémentation démarera.
Juste une petite note concernant la procédure : la question est d'abord posée aux clients de Collabnet parce que nous pensons que leurs ingénieurs et chefs de projet sont à même de nous dire précisément et avec un minimum d'ambiguité ce qu'ils veulent, et que d'avoir quelques définitions claires pourrait aider le "grand public" libre à donner des réponses utiles, plutot que des tautologies du type "on veut un suivi des merges!". Ce n'est absolument pas pour favoriser les clients de Collabnet, et je peux vous assurer que les développeurs de Subversion non-employés par collabnet, une majorité dont je fais partie ne se laisseront pas faire (même s'il n'y a jamais eu besoin de se battre - Collabnet à toujours oeuvré dans le respect complet du "code moral" des projets libre).
Donc voilà, c'est en marche, mais je ne cache pas que cela prendra du temps. Et oui, je suis au courant que nombre de systèmes de contrôle de révision implémentent déjà quelque chose, mais nous préférons bien comprendre le problème avant d'implémenter une solution qui ne fait que la moitié de ce qu'on attend d'elle ;-) Mais réalistiquement, je ne pense pas qu'il faille s'y attendre avant subversion 1.6 au plus tôt (estimation powered by pifomètre, désolé). En attendant, l'utilisation de svnmerge et svk est recommandée pour la gestion des merges, ce sont de bons logiciels (et on se privera pas de leur piquer des idées le moment venu ;-)
[^] # Re: Type de license?
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 1.
Les restrictions ont été ajoutées par Collabnet, l'entreprise qui a lancé le développement en 2000 (en embauchant Karl Fogel, expert CVS, et en lui disant "Tu vois CVS? Tu vois ce qui te plais pas? Code nous un CVS que tu aimerais utiliser" :). Ayant fait le pari de faire de leur SCM un projet entièrement libre, elle a tout de même ajouté des clauses pour protéger ses marques déposées (Collabnet et Tigris).
Donc, pour résumer, c'est pas aussi libre que la GPL, parce que Collabnet et d'autres veulent une licence type BSD pour pouvoir développer des composants propriétaires (pour Collabnet, c'est notamment les modules d'intégration à leur produit de groupware); mais c'est vraiment libre, d'après l'OSI et les DFSG (Debian Free Software Guidelines). J'ai un doute pour la FSF, donc je vais la fermer au lieu de risquer de dire une connerie. Allez vérifier :P
[^] # Re: Felicitations a ttes l'équipe !
Posté par David Anderson . En réponse à la dépêche Subversion 1.3.0 est disponible. Évalué à 2.
Il est prévu à l'avenir de permettre la création d'une copie de travail sans ces text-base, pour avoir une copie de travail moins grosse, au prix de devoir avoir le réseau à disposition même pour les opérations triviales comme 'svn diff' ou 'svn status' (qui devrait demander au serveur pour pouvoir comparer).
L'implémentation de cette fonctionalité était également un projet Summer of Code d'ailleurs, mais la personne qui y a été affectée (qui était déjà un développeur Subversion) a préféré s'atteler à des problèmes plus urgents finalement, et donc ca n'a pas été terminé.