Les langages de scripts sont souvent bien plus connu que les langages compilés. Prenons l'exemple de Javascript. Le moindre petit développeur web connait javascript (pas forcément bien mais bon...). Et bien le moindre petit développeur web peut par exemple se faire une petite extension XUL pour Firefox en 2-3 coups de cuillère à pot. Bon j'exagère un poil, mais c'est en tout cas extrêmement plus simple que si il fallait faire l'extension à coup de fonction C/classe C++ (avec tout ce que ça apporte comme lourdeur au dev : installation de X outils de dev, compilation etc.) On en a une preuve flagrante quand on compare IE et Firefox : regardez celui qui a le plus d'extensions disponibles. C'est celui qui peut être étendu avec un simple script.
Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.
>Ce qui prouve qu'il y a eu erreur de la part de Disruptive Innovations de refuser tout développement de la version 1
Ça prouve rien du tout. Et surtout il n'y a eu aucune erreur. Ce sont des circonstances qui ont fait que la poursuite du développement de la version 1 est tombé à l'eau pour nous.
>ce KompoZer mériterait d'avoir le nom nvu-1.7.10
Peut-être, mais NVU est une marque de Linspire, et il n'est pas possible de la réutiliser pour des versions ultérieures de NVU 1.0 sans le consentement de Linspire... (oui je sais c'est dommage mais c'est comme ça et c'est valable même pour nous à DI ).
>vu que toutes les resources de Disruptive Innovations sont maintenant affectées au développement de FullerScreen :(
Je ne sais pas où tu as lu ça, mais sache que c'est totalement faux. J'ai pas l'impression de travailler sur FullerScreen, ou alors serait-ce à l'insu de mon plein grés ? :-). FullerScreen n'est qu'un "petite" extension que Glazou réalise entre deux projets.
En ce qui concerne le développement de Mozilla "nvu2" Composer, c'est vrai que c'est un peu en suspend, mais bon, todo list énorme, clients, autres projets prioritaires, tout ça... (d'ailleurs, au passage, si une entreprise veut bien "sponsoriser" le dev de Composer...).
> Si Firefox est lourd, est-ce à cause de son interface en XUL ?
c'est une cause oui. Mais bon, sur ce genre de machine, il me semble que le opera installé n'est pas la version desktop, mais une version "embarqué", avec une interface spécifique, adaptée pour les petits écrans. Donc au même titre qu'opéra, tu n'utiliseras pas Firefox sur ce genre de machine, mais son accolyte minimo ou maemo (qui n'ont à priori pas d'interfaces en XUL)
>Est-ce que Gecko tout seul est suffisamment léger pour espérer tourner sur une machine lente avec peu de RAM, si on lui fournit une GUI appropriée ?
réponse oui : minimo fonctionne depuis quelques années déjà sur des appareils bien moins puissant que le nokia. (mais le développement de minimo est un peu en suspend depuis quelques mois il me semble).
Mais il est probable tout de même que gecko soit plus lourd que le moteur d'opera.
Je suis pas expert dans lesdits protocoles, mais voila ce qu'il faut faire pour envoyer un message en xmpp à quelqu'un :
<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>
Voici le même message envoyé avec IRC :
:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?
Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.
Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !
Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).
Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.
Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).
ouai mais bon au niveau occupation de bande passante, il me semble que jabber est largement déficient. Va donc installer un serveur jabber en remplacement de freenode.net... Et offrir quelques milliers de dollars pour installer des machines supplémentaires...
Oui c'est pénible ce genre de formulaire. Heureusement, il y a des solutions, comme Firefox + extension Resizeable Form Fields, qui permet de modifier à la souris la taille d'un élement de formulaire ;-)
> Heuuuu, a quoi ils servent les millions de la fondation mozilla ????
À payer les dizaines de développeurs qui bossent non pas sur Firefox, mais sur Gecko (la plateforme quoi) ;-) Les 11 de Firefox sont ceux qui bossent exclusivement sur l'interface et les composants propres à Firefox.
Et puis il y a ceux qui bossent sur les serveurs (download, addons etc..), ceux qui bossent sur developer.mozilla.org, ceux qui bossent sur le triage de bug etc.. Et puis y a le marketing, les confs etc... Et puis y a des sous qui vont au financement des "succursales" de Mozilla à travers le monde, aux deplacements des contributeurs pour les confs etc..
> Une extraction permettrait de faciliter les mises à jour, je suppose...
Justement non, c'est pas si simple que ça, parce qu'il faut gérer les dépendances. Si je met à jour XulRunner n à n+1 (parce que telle appli le demande), comment vont se comporter les applis installées qui l'utilisent ? Y a de fortes chances que la plupart se vautrent (incompatibilité binaire si elles ont des composants binaires, incompatibilité des API etc...).
Une solution serait de maintenir la majeure partie de l'API avec des interfaces freezées mais c'est très couteux en maintenance et complique les évolutions dans XulRunner pour les devs de Firefox. Une autre serait de permettre l'installation de plusieurs versions de xulrunner, mais c'est pas simple, surtout sur windows si je ne dis pas de bêtises. Et ne parlons pas du fait que des logiciels majeures comme joost et songbird ont hacké xulrunner dans tout les sens pour intégrer des trucs très spécifiques, donc un xulrunner "commun" ne leur serait d'aucune utilité.
Maintenant, si tu penses avoir des solutions faciles pour gérer ce genre de chose, tu peux en parler à Benjamin Smedberg (qui a réalisé XulRunner). Je ne te cache pas que ça arrangerait beaucoup de monde, mais hélas, cela n'est vraiment pas aussi simple que tu le dis.
encore une fois, ce n'est que pure spéculation de ma part, et il est fortement probable que j'ai sous estimer les coûts et donc que "4 ans" soit exagéré. Faut savoir lire des fois...
>C'est marrant que d'autres projets comme debian ou gentoo arrivent à s'en tirer avec un budget approximativement nul (pour gentoo, je suis moins sûr pour debian).
Ouai genre, les devs vivent d'amour et d'eau fraiche. Et puis les machines, les serveurs, les sites web, tout est gratuit et ça ne coûte rien à personne. Qu'est ce qu'il faut pas entendre comme connerie tout de même...
>Et puis avoir en caisse de quoi fonctionner 4 ans à plein sans la moindre rentrée d'argent,
C'est juste une spéculation de ma part, je l'ai précisé il me semble : ce n'est en aucun cas un fait établi, je suis pas dans le secret de la compta de la MoCo, et il est fortement probable que j'ai largement sous-estimé les coûts.
Faut arreter de gober tout comme un gamin et de prendre pour argent comptant.
Et ce n'est que la partie visible de l'iceberg, parce que derrière y a tout l'aspect "review" des patchs qui prennent beaucoup de temps, l'aspect gestion de bugs aussi (il y en moyenne 100-150 qui débarque dans le bugzilla, dont certainement le tiers sont des duplicatas, des bugs invalides etc ce qui fait perdre énormément de temps).
Et puis renseigne toi un peu, tout ce qui a trait à XUL represente quedal au niveau temps de dev par rapport au reste (évolutions dans le layout engine par ex, dans l'API etc).
>La question que je me pose c'est comment puis-je faire - en tant que simple utilisateur - si je veux que de vieux bugs de thundebird tombent enfin dans les oubliettes de la préhistoire de Mozilla Corp.
Rechercher le bug en question sur http://bugzilla.mozilla.org, et voter, laisser un commentaire confirmant le problème dans le cas où il n'est pas confirmé...
>Pour eux, un contrat de 50 euros, c'est surement trop peu pour s'y attarder
Je confirme, c'est pas avec ça qu'on va pouvoir mettre un steak dans notre assiette. Surtout que la majorité des bug ne se corrigent pas en 1 heure, mais nécessite plusieurs jours de dev :-)
>Existe-t-il un moyen - je pense à un genre de cagnote - qui permettrais de récolter de l'argent pour résoudre ce genre de petits bugs ?
Non, y a pas à ma connaissance. Tu peux filer un don je crois, mais c'est pas sûr que ça sera investi directement dans la résolution d'un bug précis. Et puis ça peut être pervers comme système : la priorité des bugs serait alors faite sur ceux où il y a plus d'argent, et pas forcément ceux qui sont les plus importants (aux yeux de la MoCo). Genre y a des bugs très techniques qui sont important à résoudre, mais que l'utilisateur lambda en a rien à fiche ou qu'il ignore tout simplement, et donc sur lequel il y aurait peu de "mises".
Établir la priorité des bugs en fonction des désiratas des utilisateurs et des objectifs de la Moco, c'est déjà un casse tête sans fin dans le système actuel, alors si il y a en plus de l'argent en jeu...
Un des interêts de webrunner est d'avoir une interface minimum qui ne "perturbe" pas l'utilisateur. Par exemple, pour une appli web en intranet, ça peut être trés intéressante car on peut un peu mieux contrôler ce que peut faire l'utilisateur : il n'a pas de bouton back par ex. Et puis ça donne un look un peu plus pro. Et pour peu que l'interface de ladite application web soit en XUL, ça ressemble à une appli desktop.
>Surtout que si tu mets des hooks bien coercitifs sur le gestionnaire de version (genre ça commit pas si la couverture par les tests n'est pas totale, si le codestyle n'est pas parfaitement respecté etc)
Impossible à mettre de tel hook sur un commit. Vu qu'il faut 40mn pour compiler un gecko, et je ne sais pas combien pour lancer tout les tests, je vois mal attendre le dev pendant une heure que son commit se finisse.
La vérification du coding style et les tests sont faits en amonts, avant le commit. Un développeur n'a le droit de commiter son patch que si il a passé avec succés au moins deux reviews (deux vérifications faites par deux responsables de la partie du code en question, vérifications faites au niveau du coding style, du fonctionnement, de la qualité du code pour éviter les leaks etc ). Et après le commit, il y a les tinderbox (ex, celle pour firefox 3 : http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox ) qui compilent en permanence Gecko sur plein de bécanes différentes (sous linux, windows mac etc), et réalisent les tests fonctionnelles et les tests de perfs. Et si la compile passe pas (parce que les devs n'ont pas toutes les machines sur leur bureau pour tester la compile sur toutes les archis avant le commit), ou si il y a des tests qui passent pas, le commiter est prié de retirer son patch de suite et de corriger le problème.
Ils sont je crois actuellement 120-150 employé (la majorité des devs). Prenons un salaire annuel moyen de 60000 $ (charges patronales comprises, et encore pour certains dev, c'est certainement plus vu leurs compétences et la rareté de ces compétences sur le marché). ça fait donc pour 120 employés, 7,2 M$ sur un an. À cela faut ajouter les coûts de fonctionnement (serveurs, bande passante, électricité, eau etc...), des impôts diverses, les remboursement d'emprunts des locaux (tout neuf de y a 1 ou 2 ans), les déplacements des conférenciers, l'organisation des conférences et rassemblement des développeurs un peu partout dans le monde, les aides aux contributeurs de toutes sortes (localiseurs, dev, "évangélistes" etc ), les subventions aux antennes locales (en fr, au japon etc.)... Je pense qu'on peut facilement tabler pour 2 M$ de plus par an (totalement au pif). ça fait donc 9 M$ de dollars minimum et si ça se trouve, je suis sûr d'être encore loin de la réalité. Avec 40 M$ en poche, ça fait donc tenir 4 ans grand maximum à la MoCo si par malheur la MoCo n'avait plus de revenus qui rentraient (genre Google arrête son contrat).
4 ans, c'est peu je trouve, pour une organisation comme la MoCo, qui ne vend rien du tout. Et encore heureux que ce soit une boîte ayant un statut spécial qui interdit la redistribution des bénéfices.
Je crois que tu n'a pas bien compris le contenu de la page que tu sites : ils cherchent juste un moyen pour booster le développement de Thunderbird. La MoCo n'a pas assez de ressources pour développer Thunderbird de manière innovante et de manière soutenu. Donc ils cherchent juste un moyen de reorganiser tout ça afin qu'il y ait une plus grosse communauté, plus de moyens.
Et si ils trouvent (ils vont trouver j'en suis sûr), cela permettra d'avoir un projet plus vivant. Parce qu'à l'heure actuelle, il y a seulement un ou deux dev à temps plein dessus. On voit ce que cela a donné pour la version 2.0 : il n'y a pas énormément de nouveautés par rapport à la 1.5 (en tout cas, pas de quoi m'enthousiasmer personnellement, et j'ai toujours pas migrer vers la 2.0), et surtout toujours des vieux bugs qui trainent.
Enfin bref, plutôt que d'alarmer tout le monde avec une pauvre page wiki dont tu ne sais même pas le degré de son "officialité", tu ferais mieux de lire planet.mozilla.org ;-) (où il y a de nombreux posts actuellement sur cette probable réorganisation)
>des deprecated apparaissent mais ça tourne toujours.
ouai enfin, si c'est deprecated, il faut s'attendre à ce que cela n'existe plus à partir d'une certaine version (enfin en toute logique, je ne suis pas expert java non plus). Donc il faut bien que tu le retouches ton code un jour ou l'autre. En tout cas, j'aime pas laisser des trucs "deprecated" dans mon code, ça fait un peu sale...
>c'est peut-être aussi parce que php5 est beaucoup moins adapté a ce public
C'est totalement faux, tu peux toujours faire des scripts de newbie avec PHP5. Mieux, la plupart script PHP4 fonctionnent certainement moyennant quelques corrections mineures
>Peut-être que les hébergeurs feront un effort pour pousser php5. Mais pour bosser dans ce secteur, je peux vous dire que l'abandon de php4 n'est pas envisageable actuellement.
Y a une solution pour les hébergeurs : c'est que les nouveaux hébergements se fassent sur des nouvelles machines équipées de PHP5.
Bon et puis peut être que pour toi c'est pas envisageable, alors je ne sais pas où tu travailles, mais je te recommande d'aller voir ailleurs. Ça fait quand même pas mal de temps que beaucoup d'hebergeurs proposent PHP5/PHP4 en même temps (au hasard, un "petit" hébergeur : free). Alors bon... Et puis quand on voit que parmis ceux qui soutiennent gophp5, il y a des hébergeurs comme Dreamhost (un autre "petit"), j'ai comme l'impression qu'il s'agit plus d'un manque de volonté de votre part qu'un réèl obstacle..
> php4 a de beaux jours devant lui
ouai enfin, date limite aout 2008. Et puis tu vas pleurer pour proposer à tes hébergés du phpmyadmin qui ne fonctionnera plus sur PHP4.
Les projets majeurs vont abandonner le PHP4, il va bien falloir vous adapter quand vos hebergés se plaindront qu'ils ne peuvent installer telle ou telle appli.
# exemple avec firefox/XUL
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité d'un langage de script comme langage d'extension d'un logiciel.. Évalué à 2.
Et puis je plussois ce que dit pasBillpasGates : un langage de script permet de limiter les dégâts en terme de gestion de mémoire, de limiter l'accés à certaines API internes pour pas faire n'importe quoi, puisque c'est l'interpréteur qui gère ces problémes. Mais ça ne les éradique pas forcément, comme on peut le voir avec certaines extensions Firefox codées avec les pieds, et qui contiennent des leaks dans tous les sens.
[^] # Re: Nvu 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Publication de KompoZer 0.7.10. Évalué à 9.
Ça prouve rien du tout. Et surtout il n'y a eu aucune erreur. Ce sont des circonstances qui ont fait que la poursuite du développement de la version 1 est tombé à l'eau pour nous.
>ce KompoZer mériterait d'avoir le nom nvu-1.7.10
Peut-être, mais NVU est une marque de Linspire, et il n'est pas possible de la réutiliser pour des versions ultérieures de NVU 1.0 sans le consentement de Linspire... (oui je sais c'est dommage mais c'est comme ça et c'est valable même pour nous à DI ).
[^] # Re: Nvu 2
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Publication de KompoZer 0.7.10. Évalué à 7.
Je ne sais pas où tu as lu ça, mais sache que c'est totalement faux. J'ai pas l'impression de travailler sur FullerScreen, ou alors serait-ce à l'insu de mon plein grés ? :-). FullerScreen n'est qu'un "petite" extension que Glazou réalise entre deux projets.
En ce qui concerne le développement de Mozilla "nvu2" Composer, c'est vrai que c'est un peu en suspend, mais bon, todo list énorme, clients, autres projets prioritaires, tout ça... (d'ailleurs, au passage, si une entreprise veut bien "sponsoriser" le dev de Composer...).
# s/firefox/minimo
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Navigateurs webs et machines lentes. Évalué à 2.
c'est une cause oui. Mais bon, sur ce genre de machine, il me semble que le opera installé n'est pas la version desktop, mais une version "embarqué", avec une interface spécifique, adaptée pour les petits écrans. Donc au même titre qu'opéra, tu n'utiliseras pas Firefox sur ce genre de machine, mais son accolyte minimo ou maemo (qui n'ont à priori pas d'interfaces en XUL)
>Est-ce que Gecko tout seul est suffisamment léger pour espérer tourner sur une machine lente avec peu de RAM, si on lui fournit une GUI appropriée ?
réponse oui : minimo fonctionne depuis quelques années déjà sur des appareils bien moins puissant que le nokia. (mais le développement de minimo est un peu en suspend depuis quelques mois il me semble).
Mais il est probable tout de même que gecko soit plus lourd que le moteur d'opera.
[^] # Re: ou alors...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 3.
<?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
<message from='expediteur@exemple.com' to='destinataire@exemple.net' xml:lang='fr'>
<body>Hello are you receiving this message ?</body>
</message>
</stream:stream>
Voici le même message envoyé avec IRC :
:expediteur@exemple.com PRIVMSG destinataire@exemple.net :Hello are you receiving this message ?
Quand on calcule le nombre de caractère (je ne compte pas les caractères blanc entre les balises pour xmpp), on a un paquet de 298 caractères pour XMPP contre 97 pour IRC. Soit un facteur 3.
Si on ne compte pas les parties variables (nom des destinataire/expediteur et le message en lui même), on a 214 caractères contre 13, soit un facteur 16 !
Bref, xmpp est beaucoup plus gourmand en bande passante que IRC et demande un peu plus de ressource au niveau du client puisque parser du XML est quand même beaucoup plus compliqué que de parser une commande IRC (m'enfin je chippotte, pour une machine moderne, la différence ne se voit pas, sauf peut être si on est connécté à 20 channels de 150 users en même temps avec des discussions trollesques à gogo).
Maintenant peut être que XMPP permet-il au client d'envoyer directement à tous les autres clients du channel, plutôt que de l'envoyer au serveur qui dispatch ensuite. Dans ce cas, il est probable que les serveurs ne souffrent pas autant que je le dis. Mais je n'ai pas regardé comment ça fonctionne exactement.
Note: c'est amusant^W delirant aussi de voir l'énorme différence entre un ping en XMPP et un ping IRC (envoyé entre client et serveur pour savoir par l'un si l'autre est alive et vice versa).
[^] # Re: ou alors...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal IRC Plus, une initiative pour harmoniser les services IRC. Évalué à 4.
[^] # Re: Wouha !
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Alfresco : Nouvelle version 2.1 et rapport sur les usages. Évalué à 6.
https://addons.mozilla.org/fr/firefox/addon/3694
Personnellement, je ne peux plus m'en passer.
[^] # Re: Plus de développeurs, moins de décideurs....
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Mozilla veut donner plus d'autonomie et de visibilité à Thunderbird. Évalué à 6.
À payer les dizaines de développeurs qui bossent non pas sur Firefox, mais sur Gecko (la plateforme quoi) ;-) Les 11 de Firefox sont ceux qui bossent exclusivement sur l'interface et les composants propres à Firefox.
Et puis il y a ceux qui bossent sur les serveurs (download, addons etc..), ceux qui bossent sur developer.mozilla.org, ceux qui bossent sur le triage de bug etc.. Et puis y a le marketing, les confs etc... Et puis y a des sous qui vont au financement des "succursales" de Mozilla à travers le monde, aux deplacements des contributeurs pour les confs etc..
[^] # Re: de la c*nnerie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 3.
Et puis les applications qui patches XulRunner sont des cas très particulier, et je n'ai jamais dis que c'était une généralité.
[^] # Re: de la c*nnerie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 2.
Justement non, c'est pas si simple que ça, parce qu'il faut gérer les dépendances. Si je met à jour XulRunner n à n+1 (parce que telle appli le demande), comment vont se comporter les applis installées qui l'utilisent ? Y a de fortes chances que la plupart se vautrent (incompatibilité binaire si elles ont des composants binaires, incompatibilité des API etc...).
Une solution serait de maintenir la majeure partie de l'API avec des interfaces freezées mais c'est très couteux en maintenance et complique les évolutions dans XulRunner pour les devs de Firefox. Une autre serait de permettre l'installation de plusieurs versions de xulrunner, mais c'est pas simple, surtout sur windows si je ne dis pas de bêtises. Et ne parlons pas du fait que des logiciels majeures comme joost et songbird ont hacké xulrunner dans tout les sens pour intégrer des trucs très spécifiques, donc un xulrunner "commun" ne leur serait d'aucune utilité.
Maintenant, si tu penses avoir des solutions faciles pour gérer ce genre de chose, tu peux en parler à Benjamin Smedberg (qui a réalisé XulRunner). Je ne te cache pas que ça arrangerait beaucoup de monde, mais hélas, cela n'est vraiment pas aussi simple que tu le dis.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 1.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 2.
Ouai genre, les devs vivent d'amour et d'eau fraiche. Et puis les machines, les serveurs, les sites web, tout est gratuit et ça ne coûte rien à personne. Qu'est ce qu'il faut pas entendre comme connerie tout de même...
>Et puis avoir en caisse de quoi fonctionner 4 ans à plein sans la moindre rentrée d'argent,
C'est juste une spéculation de ma part, je l'ai précisé il me semble : ce n'est en aucun cas un fait établi, je suis pas dans le secret de la compta de la MoCo, et il est fortement probable que j'ai largement sous-estimé les coûts.
Faut arreter de gober tout comme un gamin et de prendre pour argent comptant.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 3.
Franchement, c'est de la connerie pure et simple. Genre les mecs de chez Mozilla foutent rien. Suit un peu les commits juste pour te rendre compte du boulot effectué.
http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&mo(...)
Et ce n'est que la partie visible de l'iceberg, parce que derrière y a tout l'aspect "review" des patchs qui prennent beaucoup de temps, l'aspect gestion de bugs aussi (il y en moyenne 100-150 qui débarque dans le bugzilla, dont certainement le tiers sont des duplicatas, des bugs invalides etc ce qui fait perdre énormément de temps).
Et puis renseigne toi un peu, tout ce qui a trait à XUL represente quedal au niveau temps de dev par rapport au reste (évolutions dans le layout engine par ex, dans l'API etc).
[^] # Re: Debugging
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 4.
Rechercher le bug en question sur http://bugzilla.mozilla.org, et voter, laisser un commentaire confirmant le problème dans le cas où il n'est pas confirmé...
>Pour eux, un contrat de 50 euros, c'est surement trop peu pour s'y attarder
Je confirme, c'est pas avec ça qu'on va pouvoir mettre un steak dans notre assiette. Surtout que la majorité des bug ne se corrigent pas en 1 heure, mais nécessite plusieurs jours de dev :-)
>Existe-t-il un moyen - je pense à un genre de cagnote - qui permettrais de récolter de l'argent pour résoudre ce genre de petits bugs ?
Non, y a pas à ma connaissance. Tu peux filer un don je crois, mais c'est pas sûr que ça sera investi directement dans la résolution d'un bug précis. Et puis ça peut être pervers comme système : la priorité des bugs serait alors faite sur ceux où il y a plus d'argent, et pas forcément ceux qui sont les plus importants (aux yeux de la MoCo). Genre y a des bugs très techniques qui sont important à résoudre, mais que l'utilisateur lambda en a rien à fiche ou qu'il ignore tout simplement, et donc sur lequel il y aurait peu de "mises".
Établir la priorité des bugs en fonction des désiratas des utilisateurs et des objectifs de la Moco, c'est déjà un casse tête sans fin dans le système actuel, alors si il y a en plus de l'argent en jeu...
[^] # Re: Précisions
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal WebRunner alias RAMinator. Évalué à 2.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 2.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 2.
Impossible à mettre de tel hook sur un commit. Vu qu'il faut 40mn pour compiler un gecko, et je ne sais pas combien pour lancer tout les tests, je vois mal attendre le dev pendant une heure que son commit se finisse.
La vérification du coding style et les tests sont faits en amonts, avant le commit. Un développeur n'a le droit de commiter son patch que si il a passé avec succés au moins deux reviews (deux vérifications faites par deux responsables de la partie du code en question, vérifications faites au niveau du coding style, du fonctionnement, de la qualité du code pour éviter les leaks etc ). Et après le commit, il y a les tinderbox (ex, celle pour firefox 3 : http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox ) qui compilent en permanence Gecko sur plein de bécanes différentes (sous linux, windows mac etc), et réalisent les tests fonctionnelles et les tests de perfs. Et si la compile passe pas (parce que les devs n'ont pas toutes les machines sur leur bureau pour tester la compile sur toutes les archis avant le commit), ou si il y a des tests qui passent pas, le commiter est prié de retirer son patch de suite et de corriger le problème.
[^] # Re: FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 3.
Ils sont je crois actuellement 120-150 employé (la majorité des devs). Prenons un salaire annuel moyen de 60000 $ (charges patronales comprises, et encore pour certains dev, c'est certainement plus vu leurs compétences et la rareté de ces compétences sur le marché). ça fait donc pour 120 employés, 7,2 M$ sur un an. À cela faut ajouter les coûts de fonctionnement (serveurs, bande passante, électricité, eau etc...), des impôts diverses, les remboursement d'emprunts des locaux (tout neuf de y a 1 ou 2 ans), les déplacements des conférenciers, l'organisation des conférences et rassemblement des développeurs un peu partout dans le monde, les aides aux contributeurs de toutes sortes (localiseurs, dev, "évangélistes" etc ), les subventions aux antennes locales (en fr, au japon etc.)... Je pense qu'on peut facilement tabler pour 2 M$ de plus par an (totalement au pif). ça fait donc 9 M$ de dollars minimum et si ça se trouve, je suis sûr d'être encore loin de la réalité. Avec 40 M$ en poche, ça fait donc tenir 4 ans grand maximum à la MoCo si par malheur la MoCo n'avait plus de revenus qui rentraient (genre Google arrête son contrat).
4 ans, c'est peu je trouve, pour une organisation comme la MoCo, qui ne vend rien du tout. Et encore heureux que ce soit une boîte ayant un statut spécial qui interdit la redistribution des bénéfices.
[^] # Re: Une boite de Culture, siouplait m'dame!
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Notre bien aimé président veut protéger la culture. Évalué à 2.
>Le premier flic de France
puis ça dans ton commentaire
>avec le flic le plus teigneux de france,
Je me pose une question : on m'aurait menti ? Il n'est pas plutôt Président de la république ?
# FUD
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal La fin de Thunderbird ?. Évalué à 1.
Et si ils trouvent (ils vont trouver j'en suis sûr), cela permettra d'avoir un projet plus vivant. Parce qu'à l'heure actuelle, il y a seulement un ou deux dev à temps plein dessus. On voit ce que cela a donné pour la version 2.0 : il n'y a pas énormément de nouveautés par rapport à la 1.5 (en tout cas, pas de quoi m'enthousiasmer personnellement, et j'ai toujours pas migrer vers la 2.0), et surtout toujours des vieux bugs qui trainent.
Enfin bref, plutôt que d'alarmer tout le monde avec une pauvre page wiki dont tu ne sais même pas le degré de son "officialité", tu ferais mieux de lire planet.mozilla.org ;-) (où il y a de nombreux posts actuellement sur cette probable réorganisation)
[^] # Re: Valide d'après le W3C
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal backend RSS linuxfr pas "normal" ?. Évalué à 3.
donc bug dans templeet ou ailleurs...
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 3.
Moi ça fait des années que j'entends ça, et pourtant....
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 2.
[^] # Re: Incompatibilités ?
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche L'arrêt du support de PHP4 annoncé. Évalué à 5.
ouai enfin, si c'est deprecated, il faut s'attendre à ce que cela n'existe plus à partir d'une certaine version (enfin en toute logique, je ne suis pas expert java non plus). Donc il faut bien que tu le retouches ton code un jour ou l'autre. En tout cas, j'aime pas laisser des trucs "deprecated" dans mon code, ça fait un peu sale...
[^] # Re: foutaise
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Fin de PHP 4 annoncée. Évalué à 2.
C'est totalement faux, tu peux toujours faire des scripts de newbie avec PHP5. Mieux, la plupart script PHP4 fonctionnent certainement moyennant quelques corrections mineures
>Peut-être que les hébergeurs feront un effort pour pousser php5. Mais pour bosser dans ce secteur, je peux vous dire que l'abandon de php4 n'est pas envisageable actuellement.
Y a une solution pour les hébergeurs : c'est que les nouveaux hébergements se fassent sur des nouvelles machines équipées de PHP5.
Bon et puis peut être que pour toi c'est pas envisageable, alors je ne sais pas où tu travailles, mais je te recommande d'aller voir ailleurs. Ça fait quand même pas mal de temps que beaucoup d'hebergeurs proposent PHP5/PHP4 en même temps (au hasard, un "petit" hébergeur : free). Alors bon... Et puis quand on voit que parmis ceux qui soutiennent gophp5, il y a des hébergeurs comme Dreamhost (un autre "petit"), j'ai comme l'impression qu'il s'agit plus d'un manque de volonté de votre part qu'un réèl obstacle..
> php4 a de beaux jours devant lui
ouai enfin, date limite aout 2008. Et puis tu vas pleurer pour proposer à tes hébergés du phpmyadmin qui ne fonctionnera plus sur PHP4.
Les projets majeurs vont abandonner le PHP4, il va bien falloir vous adapter quand vos hebergés se plaindront qu'ils ne peuvent installer telle ou telle appli.