Laurent J a écrit 2938 commentaires

sans oublier :

• pain au chocolat ou chocolatine ?

Si j'ai bien compris, c'est pas l'envie de contribuer qui te manque.

Ne cherche pas à te dire tout seul "qu'est ce que je pourrais bien faire sur ce projet". Tu ne trouveras pas.

Par contre, va voir les développeurs, et demande leur. Commence par leur demander des trucs qui sont faciles à faire. Cela a plusieurs avantages :

• cela te fait découvrir l'intérieur du code source
• cela fait avancer ENORMEMENT le projet. En effet, les trucs trop simple à corriger, il y en a des tonnes, parce que justement, c'est trop simple et que les développeurs déjà en place sont trop occupés à développer les trucs les plus compliqués.
• cela rend le logiciel mieux fini, donc plus agréable pour l'utilisateur.

Par exemple, corriger une faute d'orthographe dans un menu :
- tu apprends où est le code des menus (ou alors comment et où sont stockées les chaînes de traduction)
- tu libères 5 minutes de temps pour les développeurs (et 5 min + 5 min + 5 min +… ça leur en fait du temps de gagner pour dev les trucs les plus durs)
- tu rends le logiciel moins agaçant pour les utilisateurs pour qui cette faute les choquent.

Tu commences donc par ces trucs anodins, et au fur et à mesure des patchs, tu passes à des bug fix ou des fonctionnalités plus compliquées. Et au bout de quelques mois ou année, tu finis par devenir un core-developper, code reviewer etc :-)

Une chose est sûre : tu ne pourras jamais arriver dans un projet et pouvoir proposer une grosse évolution tout de suite. C'est comme tout, il faut apprendre comment il fonctionne, de l'interieur et de l'exterieur. Bref, de la motivation, du courage, et de l'huile de coude.

Pour prendre l'exemple de Mozilla, dans la liste des choses à faire, il y a les bugs marqués "good first bug". Facile à faire en principe pour un nouveau venu. Pioche ! ;-) (tu peux aussi affiner la recherche en fonction des composants ou applis qui correspondraient plus à tes compétences/envies, le projet Mozilla ne se résume pas à Firefox ;-) )

pour un truc aussi bête que de la lecture d'EPUB.

Je te recommande d'aller lire la spec de epub3 par exemple, pour te rendre combien cette spec est complexe et contenant de nombreux trucs mal foutu, voir le blog de Daniel Glazman à ce sujet.

en ce qui me concerne, non, ce n'est pas une question de génération (put** je vais sur mes 40 balais). J'ai vu plusieurs fois des épisodes de la 7ième compagnie (mais ça fait très longtemps), et j'adore la série kaamelott. Comme quoi, on peut aimer les vieux trucs et les trucs récents à la fois :) Et dans les deux oeuvres, il est excellent :-) (faut reconnaitre aussi que les dialogues de kamelott sont écrits aux petits oignons, en particulier donc avec son rôle de césar)

bon par contre, "cordier juge et flic", jamais pu accroché.

Je viens de me balader sur le site de typematrix. Et que vois-je, dans la section "Dans les nouvelles" d'une page ? Un lien vers un article de ploum sur linuxfr :-)

Okay merci :-) J'essaierai ça ce week-end

Merci pour l'astuce. Je crois que je vais configurer mon laptop comme ça :-)

Maintenant, juste une question de newbie en utilisation des niveaux d’exécution (disons que je ne me suis jamais amusé avec) : le fait d'appeler une commande init, ça ne va pas te déconnecter ou relancer certains programmes ? On peut lancer ça quand on est sous gnome/kde par exemple ? ça ne va pas redémarrer gnome/kde ?

PS: j'imagine bien que ça va arrêter les services qui sont en K dans le nouveau level, mais pour les services qui sont communs à l'ancien et au nouveau ?

Beaucoup préfèrent un github tout joli avec des effets javascript à un gitweb (ou carrément l'utilisation de git en ligne de commande).

mmm… tu n'as pas dû regarder ce qu'était github.

gitweb, ce n'est qu'un navigateur pour un dépôt Git. Github ça comporte quand même beaucoup plus de fonctionnalités.

Après je ne vois pas l'utilisation de github en contradiction avec l'utilisation de git en ligne de commande.

J'utilise git tout les jours, en ligne de commande, et pour partager, j'utilise github. ça m'évite de monter un serveur git, ça évite à mes contributeurs de monter eux aussi leur serveur git pour que je puisse récupérer leur contributions, et ça me permet de faire de la review de code plus facilement.

Bref, tu compares des choux et des carottes.

Et utiliser des applis web/gui desktop, n'est pas en contradiction avec utiliser des outils en ligne de commande. Ils sont tout les deux complémentaires.

oups. oui en effet désolé. Je me suis mélangé les pédales. Les vacances, c'est décidément trop fatiguant.

On utilise pas des dénominations différentes pour désigner une voiture en fonction de son pays d'origine.

Bah, si, en anglais, voiture se dit "car". En allemand "wagen" etc..

Donc pourquoi faudrait-il avoir le même mot dans toutes les langues pour désigner un être humain qui va dans l'espace ?

J'ai été déçu quand la France a eu ses premiers cosmonautes, grâce à l'Union soviétique avec Jean-Loup Chrétien et grâce aux États unis d'Amérique avec Patrick Baudry, et qu'elle s'est crue obligée de forger un nouveau terme sans justification autre qu'un orgueil national mal placé

Il y a peut-être un orgeil national mal placé, mais je crois qu'il y a plutôt une autre raison. Il faut se replacer dans le contexte : à cette époque, surtout avec Jean-Loup Chrétien, nous sommes en pleine guerre froide. Avec ce partenariat (proposé par les russes), la France est prise en sandwich : d'un coté, allié des américains, et de l'autre, cette opportunité d'envoyer un français dans l'espace, avec l'aide de "l'ennemi" qui est de l'autre coté du mur. Si, officiellement, on avait appelé Mr Chrétien, un "astronaute", ça aurait probablement déplu aux russes. Si cela avait été "cosmonaute", cela aurait déplu aux américains. Bref, diplomatiquement, d'un coté comme de l'autre, cela aurait été tendu. Alors hop, appelons le, un "spationaute", cela ne va froisser personne. Et en plus c'est plus logique dans notre langue.

D'ailleurs si on suit ta logique, pourquoi tout le monde n'a pas appelé une voiture "voiture" dans les autres pays. Pourquoi d'ailleurs tout le monde ne parles-t-il pas la même langue ?

bof, c'est pas l'économie des salaires de 4-5 gars qui vont permettre de payer toutes ces pubs…

et un os qui t'interdit d'installer autre chose que ce qui est fourni par une boutique unique

à priori, tu as encore quelques libertés sur Mac : tu n'es pas obligé de passer par cette boutique pour installer un logiciel.

parfois/souvent ( rayer la mention inutile)

il faut que je raye les deux. Il manque le choix "toujours".

Elles sont toutes innovantes ?

à toi de voir..

Joost, Zoomcreator, Etna etc, oui c'était innovant. De mon point de vue en tout cas…

Est-ce pour autant que tout le monde forke et patche ? Non.

Tu es allé dans toutes les boites qui font du Qt ? et sur des projets internes ? Je suis sûr que non, donc tu ne peux pas affirmer cela.

Si ce n'est pas possible, c'est que xulrunner n'était pas le bon framework pour développer l'application. Si c'est suite à un manque de volonté de la part de Mozilla, tout pareil.

Le choix d'un framework ne se fait pas seulement sur la facilité de patcher en upstream etc.. Le choix se fait aussi sur les technologies, sur ce que cela offre pour répondre à des besoins. Par exemple, développer (ou intégrer dans l'application) un navigateur web basique avec xulrunner, se fait en 5 minutes, et sans environnement de compilation ou autre. Avec webkit, c'est quand même moins évident, faut quand même un minimum d'heures.

il faut juste alors arrêter de promouvoir xulrunner comme une plateforme de développement généraliste.

Je ne sais pas où tu as vu où Mozilla, ou quiconque, y compris moi, promeut encore XulRunner. J'ai arrêté de promouvoir XulRunner le jour où Mozilla avait annoncé qu'ils n'en ferait pas un produit. Même si cela ne m'empêche pas de l'utiliser pour certains projets, ce n'est pas quelque chose que je propose absolument à mes clients ou que je le cri sur tout les toits.

Pourquoi cela n'arrive-t-il pas avec les éditeurs basés sur webkit ?

C'est une blague ? Tu prend les versions stables de toutes les applis et navigateurs utilisant webkit, pas une n'utilise la même version de webkit. D'ailleurs les développeurs web s'en plaignent. Surtout qu'avec Webkit, tu as plusieurs backend possible pour telle ou telle partie, ce qui fait que tu n'as pas un webkit identique.

D'ailleurs, si tu regardes dans debian, libqt4-webkit n'utilise pas par exemple le paquet libwebkit-1.0-2. Tu as donc au moins deux versions de webkit dans debian.

D'un autre côté, j'imagine mal un truc comme sunbird ou thunderbird nécessiter une modification du moteur de rendu.

XulRunner, ce n'est pas seulement un moteur de rendu.. M'enfin, je n'ai plus trop le temps d'expliquer ce qu'est XulRunner, Gecko, l'ecosystème Mozilla etc…

On peut distribuer une appli compilée statiquement

Oui, et bien ? Je ne comprend pas. C'est ce que je dis non ? Des projets fournissent leur propre XulRunner (d'ailleurs le binaire xulrunner est souvent renommé). C'est pareil que de fournir une appli avec des libs compilées statiquements, donc non partagées avec d'autres applis.

(ne sommes nous pas en train de nous prendre la tête alors qu'on est d'accord ?)

https://developer.mozilla.org/en-US/docs/List_of_Mozilla-Based_Applications

https://developer.mozilla.org/en-US/docs/List_of_Former_Mozilla-Based_Applications

Et encore ce n'est pas exhaustif, et il y a plein de projets non publics.

Tu parles de payer le dév pour remonter les patches, je me demande comment quantifier les ressources gaspillées à porter les modifs de chaque appli d'une version à l'autre de XulRunner.

Quand tu suis un projet un minimum et que tu connais bien les sources, je t'assure que porter les modifs d'une version à une autre est souvent bien moins couteux que de proposer en upstream.

Proposer en upstream sur un projet aussi gros que Mozilla, peut consommer énormément de temps, parce que le patch ne peut pas plaire, parce qu'on te demande de le refaire comme-ci, comme-ça. Corriger ton patch, ça peut être bénéfique bien sûr. Et puis il y a tout un workflow à suivre : proposition du patch, review du patch, vérifier que tout les tests passent, commiter, attendre une nouvelle fois que les tests des machines de build passent etc. Et pour Mozilla, attendre 12 à 18 semaines que ce soit dans une release officielle (et encore, avant le fast release cycle, fallait attendre 1 ou 2 ans). Pour d'autres projets, attendre peut-être des mois et des mois…

Chez Mozilla, j'ai eu des patchs refusés parce que ça impactait ou était incompatible avec tel ou tel composant externe ou appli mozilla. Le souci, c'est que moi, pour mon appli, j'en avait rien à fiche. Le patch fonctionnait parfaitement pour mon appli, c'était le principal. Parce que la majorité des applis que je développe, c'est pour des clients, ou pour mon employeur (quand j'étais salarié :-)). J'ai des délais pour réaliser une appli. Dans mon exemple, rajouter des heures et des heures pour adapter le patch pour qu'il fonctionne pour tout le monde en upstream n'aurait pas été possible dans le planning du projet. Donc voilà, pas d'intégration upstream pour certains patchs (en tout cas, pas dans un premier temps, et pas dans les délais de réalisation du projet).

Dans bon nombre d'entreprise, c'est pareil (et j'en vois plein des boites…). les patchs sont proposés en upstream que si le budget le permet, que si on a le temps, ou que si c'est vraiment critique. Ou que si la boite est impliqué à fond dans le développement de la lib, du framework etc..

Et encore, je ne parle pas des cas où il faut attendre qu'un contributeur en face se bouge pour faire la review ou commiter (quand on n'a pas le "karma" nécessaire dans le projet upstream). Et pour les projets de libs un peu mort…

Bref, voilà, ça peut être coûteux de contribuer en upstream, dans le cadre d'un projet d'entreprise. Alors oui, on se retrouve avec des applis qui nécessitent des versions personnalisées de bibliothèque, comme c'est souvent le cas avec XulRunner.

La distro peut aussi tout simplement packager la nouvelle version, c'est comme cela que cela fonctionne

dans un monde idéal. Mais un éditeur de logiciel ne va pas attendre 4 ans que la nouvelle Debian sorte, pour avoir le paquet officiel de la dernière version de XulRunner. Et encore, quand une debian sort, bon nombre de paquet ne contiennent pas les dernières releases des libs.

"Bonjour monsieur le client, alors, je vous ai développé votre appli avec XulRunner comme vous le souhaitez, mais il va vous falloir attendre 3 ans ou plus que la prochaine debian stable sorte pour en profiter, parce que la version actuelle de XulRunner est bien trop vieille pour les besoins de l'application."

C'est principalement une conséquence du fait que xulrunner n'est pas pensé comme étant une bibliothèque partagée par plusieurs applications. Du coup ils doivent la modifier.

Non, ils doivent la modifier, parce qu'ils ont des besoins spécifiques que ne fourni pas le XulRunner standards.

Il ne faut pas voir XulRunner comme une lib classique, mais comme une plateforme, un framework embarquable.

Les fonctionnalités spécifiques (comme le support python) pourraient tout à fait être des plugins.

Tout ne peut pas se faire par des plugins. Par exemple, à l'époque où je développais mon éditeur XML wysywyg, j'avais plein de modification dans le coeur du code de l'éditeur de gecko. Impossible d'avoir l'éditeur sous forme de plugin, ça fait parti intégralement du coeur de gecko pour plein de raisons (liés très intimement au moteur de rendu par exemple). Et ce genre de situation arrive souvent dans les projets XulRunner conséquents, que j'ai vu passé.

Pour les patches custom, il suffit d'attendre la release de xulrunner, comme pour toutes les autres bibliothèques sous linux.

Tout les patchs customs ne sont pas forcément utile en upstream car trop spécifiques (c'était le cas de mon éditeur). Donc ça ne sert à rien d'attendre une release de XulRunner.

si Debian package une application, ils se débrouillent pour que les dépendances soient à jour.

Toutes les applications ne sont pas forcément packagées, et encore moins pour toutes les distros ou versions de distros. Donc l'utilisateur devrait utiliser le XulRunner proposé dans sa distro, bien souvent incompatible pour les applis complexes (surtout celles qui contiennent des composants binaires)

Si le patch en lui-même n'est pas intéressant, c'est probablement qu'il faut ajouter un hook au bon endroit, ou que le programme devrait faire autrement.

Oui genre, on peut mettre des hooks partout et puis surtout, en upstream, ils vont accepter ta tonne de patchs insérant des hooks partout… (et je passe sur le coté performance quand il y a des tonnes de hooks)

XulRunner a souvent été utilisé pour des applis innovantes, qui avaient besoin de choses en plus, ou des comportements différents dans le moteur de rendu ou dans des composants.

à l'interface incompréhensible… Faut lire tout une page pour commencer à comprendre comment ça fonctionne. En terme de facilité d'utilisation, on a vu mieux…

On pourrait comparer cette situation avec l'exemple (ouhouh, l'appeau à troll) des projets Mozilla

Non, je ne pense pas :-)

Si la plupart des projets d'applis basés sur XulRunner, sont livrées avec leur propre xulrunner, c'est pour d'autres raisons :

• utilisation d'une version de XulRunner plus récente que celle proposée par le paquet officiel de la distrib. Et si l'appli a besoin d'une version plus récente, c'est bien souvent pour profiter des dernières API de Gecko etc..
• utilisation d'une version patchée de XulRunner ou buildée différement. Par exemple, BlueGriffon, en plus d'utiliser une version plus récente de XulRunner pour permettre aux utilisateurs d'utiliser les dernières nouveautés HTML5 / CSS3 dans la création de leur page web, contient aussi des patchs, qui ne sont pas encore intégrés en upstream (mais peut-être ce n'est plus le cas aujourd'hui, je crois que Glazou a fait le maximum pour pouvoir utiliser une version non patchée). Autre exemple, l'éditeur Komodo, qui utilise lui aussi XulRunner, a besoin du support python dans les XPCOM. Le flag de build pour cette fonctionnalité n'est pas activée par défaut dans XulRunner. etc..

Bref, le paquet XulRunner officiel de Debian n'est pas très utile pour pas mal de projets xulrunner, à cause de son ancienneté notamment. Cela peut convenir pour des petits projets 100% XUL, mais dés que l'on veut faire une appli complexe, on a souvent besoin d'un XulRunner spécifique en version ou patché.

D'ailleurs, pour ioQuake3, tu as souligné un peu le même souci : divers projets de jeux utilisent une version patchée différente de ioQuake3. L'utilisation d'un libioquake3 commun n'est donc pas possible, non pas parce que les développeurs ils ont la culture windows, mais parce que techniquement ce n'est pas possible. Une solution serait de porter les patchs upstream. mais il y en a probablement qui ne sont pas intéressants pour ioQuake3 et tout les jeux basés dessus.

ok, je comprend.

il refuseront d'héberger du matériel qu'ils ne connaissent pas

Juste une précision, au cas où certains lecteurs auraient des doutes : le matos en question n'est pas tombé d'un camion ou autre, il vient d'une ancienne boîte où j'ai bossé, et acquis légalement :-) (suite à dépôt de bilan)

ça vous intéresserait d'avoir un serveur de secours, même si il date de 2008 ? j'en ai quelques uns à refourguer (gratos pour les associations). Ce sont des Dell, 1U ou 2U, de diverses puissances/capacités.
Si oui, il vous faudrait quoi comme machine en terme de processeur, mémoire et disque ?

y a t'il des personnes autres que chez Mozilla qui ont des accès en écriture aux repository

Bien sûr !!! quelle question  !!??

Moi j'en ai un par exemple. Tout ceux qui contribuent régulièrement peuvent demander un accès en écriture.

J'ai toujours eu l'impression, peut être fausse (ce que j'espère), que Mozilla contrôlait l'intégralité du central.

Euh… non. Ils contrôlent l’accès, c'est à dire qu'ils donnent pas non plus l’accès en écriture au premier venu. Il faut avoir contribuer.

Ensuite, tout contributeur, qu'il soit employé Mozilla ou externe, doit d'abord proposer ses patchs en relecture, avant commit définitif sur le dépôt. C'est la qualité qui est contrôlée, pas la fonctionnalité proposée (enfin bon, on ne peut pas non plus proposer n'importe quoi comme patch, il faut que ça ait un intérêt ou que ça ne casse pas tout et empêche d'avoir un produit inutilisable).

Bref, mes codes ne sont pas réellement collaboratif ;-)

Mozilla est donc plus ouvert que ton projet.

Ok, j'exagère au niveau "unlimited". Mais les budgets de développements et marketing des ces trois grosses boites, sont largement supérieurs à ceux de Mozilla. En comparaison, alors oui, ces budgets paraissent "unlimited".

Ne viens pas me dire que chez MS, IE est développé par 3 gus dans un garage, JE sais, de source sûre, qu'ils sont toute une armada par rapport à Mozilla. Il a bien fallu rattraper d'une part tout le retard, et maintenant tenter de dépasser tout le monde.