Oui, il y a des bugs non corrigés existants depuis des lustres.
Et non, ce n'est pas volontaire de la part des développeurs ou de leur hiérarchie, de laisser ces bugs pourrir.
C'est juste qu'ils n'ont pas le temps de tout faire. C'est juste parce qu'un projet comme celui là, il y a des milliards de choses à faire. Et qu'il y a des priorités.
Et non, ne pas développer Hello ou autre trucs qui vous semblent futiles dans le navigateur, ne vas pas donner plus de temps pour corriger les bugs que tu pointes. Tout simplement parce que ce ne sont pas les mêmes personnes qui travaillent sur ces parties. Et ce ne sont pas les mêmes personnes, parce que cela n'exige pas les mêmes compétences.
Pour les problèmes CSS, cela exige une connaissance sur le moteur de rendu, donc des compétences en C++, en algo de reflow et cie, en architecture d'un moteur de rendu HTML, et surtout, une connaissance du code source existant (très complexe). Faire un Hello, ça exige des connaissances en JS/HTML pour l'interface, et C++ pour l'implem de WebRTC, des connaissances poussées sur WebRTC (qui est une spec bien complexe ). Faire un outil de debug, ça nécessite aussi du JS/HTML pour l'UI, mais aussi des connaissances poussées sur le moteur JS (en C/C++), bien complexe lui aussi, pour implémenter par exemple les API de debugs etc..
Bref, chacun a sa spécialité. Le nombre de personne qui ont une connaissance approfondie de l’entièreté du code de Gecko (je ne parle que de Gecko, pas de l'interface de Firefox et ses composants périphériques comme Hello etc), on doit les compter sur les doigts des deux mains. Si ce n'est qu'une seule.
Moi par exemple dans Gecko, ma spécialité était le serializer HTML/XML, l’implémentation des élements DOM XUL, et l'éditeur HTML (le truc qui sert à avoir des champs de saisie dans une page web, ou à pouvoir éditer une page en wysiwyg avec le mode contenteditable). Mais je suis totalement incapable de toucher à un truc dans le layout engine (css et cie quoi), ni au moteur JS. Au delà de savoir si j'aurais eu suffisamment les compétences pour toucher à cette partie (très complexe), je n'avais surtout pas le temps de me plonger dedans (en tant que bénévole). Ce à quoi je contribuais m'en prenais déjà énormément.
Et sur les parties sur lesquelles je contribuais, il y a là aussi des dizaines de bugs non résolu depuis des lustres : pas le temps de tout corriger. Il faut faire alors un choix. Ok ce bug A emmerde quelques utilisateurs, et il est là depuis des lustres, mais il y a ce bug B, plus récent certes, mais qui emmerdent beaucoup beaucoup plus de monde. Donc corrigeons ce Bug B. J'aimerais bien corriger aussi le bug C, mais là, il n'y a pas énormément de tests sur le code existants, et ce qu'il faut modifier risque de casser plein de trucs. Donc ça va prendre énormément pour développer tous les tests. Ah oui mais là le truc a un comportement bizarre : bug, oubli ou feature mal spécifiée ? Le bug C que je croyais pouvoir corriger en quelques heures va me prendre des journées entières, parce qu'il va falloir que j'étudie du code source et des specs à tire-larigo. Bon ben le bug C, ça sera pour quelqu'un d'autre. Ah, et puis y a le bug D. Trop important. C'est une feature totalement nouvelle dans HTML5, que les développeurs veulent tout de suite parce que trop kikoolol et que les autres nav ont déjà implémenté. Donc allons-y pour le bug D.
etc. etc. etc..
Voilà à quoi peut ressembler les contributions d'un bénévole. Pour un employé Mozilla, ils ont moins de latitudes à choisir. Faut qu'ils développent les nouvelles features. Parce que bon, y a des râleurs qui se plaignent du retard en HTML5 etc, alors faut qu'on avance. Hein ? quoi ? ah, faut aussi corriger les bugs vieux de 8 ans ? Ah bah oui mais faut savoir ce qu'ils veulent aussi...
Firefox est un gros projet. Et comme tout gros projets, il y a des choses qui ne sont pas corrigés, parce qu'il y a des choses plus prioritaires que d'autres, parce que le nombre de dev travaillant sur une partie n'est pas illimités, parce qu'un dev travaillant sur une partie n'est pas forcément compétent pour travailler sur une autre partie.
Donc voilà. Ok, y a 3 bugs qui t'agacent. Je te comprends. Moi-même j'en ai. Mais pas les même. Bref, y en a des centaines.
[^] # Re: Et le support standard du HTML 5 ??
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche Firefox 34, ce Hérault. Évalué à 9.
Oui, il y a des bugs non corrigés existants depuis des lustres.
Et non, ce n'est pas volontaire de la part des développeurs ou de leur hiérarchie, de laisser ces bugs pourrir.
C'est juste qu'ils n'ont pas le temps de tout faire. C'est juste parce qu'un projet comme celui là, il y a des milliards de choses à faire. Et qu'il y a des priorités.
Et non, ne pas développer Hello ou autre trucs qui vous semblent futiles dans le navigateur, ne vas pas donner plus de temps pour corriger les bugs que tu pointes. Tout simplement parce que ce ne sont pas les mêmes personnes qui travaillent sur ces parties. Et ce ne sont pas les mêmes personnes, parce que cela n'exige pas les mêmes compétences.
Pour les problèmes CSS, cela exige une connaissance sur le moteur de rendu, donc des compétences en C++, en algo de reflow et cie, en architecture d'un moteur de rendu HTML, et surtout, une connaissance du code source existant (très complexe). Faire un Hello, ça exige des connaissances en JS/HTML pour l'interface, et C++ pour l'implem de WebRTC, des connaissances poussées sur WebRTC (qui est une spec bien complexe ). Faire un outil de debug, ça nécessite aussi du JS/HTML pour l'UI, mais aussi des connaissances poussées sur le moteur JS (en C/C++), bien complexe lui aussi, pour implémenter par exemple les API de debugs etc..
Bref, chacun a sa spécialité. Le nombre de personne qui ont une connaissance approfondie de l’entièreté du code de Gecko (je ne parle que de Gecko, pas de l'interface de Firefox et ses composants périphériques comme Hello etc), on doit les compter sur les doigts des deux mains. Si ce n'est qu'une seule.
Moi par exemple dans Gecko, ma spécialité était le serializer HTML/XML, l’implémentation des élements DOM XUL, et l'éditeur HTML (le truc qui sert à avoir des champs de saisie dans une page web, ou à pouvoir éditer une page en wysiwyg avec le mode contenteditable). Mais je suis totalement incapable de toucher à un truc dans le layout engine (css et cie quoi), ni au moteur JS. Au delà de savoir si j'aurais eu suffisamment les compétences pour toucher à cette partie (très complexe), je n'avais surtout pas le temps de me plonger dedans (en tant que bénévole). Ce à quoi je contribuais m'en prenais déjà énormément.
Et sur les parties sur lesquelles je contribuais, il y a là aussi des dizaines de bugs non résolu depuis des lustres : pas le temps de tout corriger. Il faut faire alors un choix. Ok ce bug A emmerde quelques utilisateurs, et il est là depuis des lustres, mais il y a ce bug B, plus récent certes, mais qui emmerdent beaucoup beaucoup plus de monde. Donc corrigeons ce Bug B. J'aimerais bien corriger aussi le bug C, mais là, il n'y a pas énormément de tests sur le code existants, et ce qu'il faut modifier risque de casser plein de trucs. Donc ça va prendre énormément pour développer tous les tests. Ah oui mais là le truc a un comportement bizarre : bug, oubli ou feature mal spécifiée ? Le bug C que je croyais pouvoir corriger en quelques heures va me prendre des journées entières, parce qu'il va falloir que j'étudie du code source et des specs à tire-larigo. Bon ben le bug C, ça sera pour quelqu'un d'autre. Ah, et puis y a le bug D. Trop important. C'est une feature totalement nouvelle dans HTML5, que les développeurs veulent tout de suite parce que trop kikoolol et que les autres nav ont déjà implémenté. Donc allons-y pour le bug D.
etc. etc. etc..
Voilà à quoi peut ressembler les contributions d'un bénévole. Pour un employé Mozilla, ils ont moins de latitudes à choisir. Faut qu'ils développent les nouvelles features. Parce que bon, y a des râleurs qui se plaignent du retard en HTML5 etc, alors faut qu'on avance. Hein ? quoi ? ah, faut aussi corriger les bugs vieux de 8 ans ? Ah bah oui mais faut savoir ce qu'ils veulent aussi...
Firefox est un gros projet. Et comme tout gros projets, il y a des choses qui ne sont pas corrigés, parce qu'il y a des choses plus prioritaires que d'autres, parce que le nombre de dev travaillant sur une partie n'est pas illimités, parce qu'un dev travaillant sur une partie n'est pas forcément compétent pour travailler sur une autre partie.
Donc voilà. Ok, y a 3 bugs qui t'agacent. Je te comprends. Moi-même j'en ai. Mais pas les même. Bref, y en a des centaines.
Mais je te rassure, c'est pareil ailleurs : il y a aussi des milliers de vieux bugs non corrigés sur Webkit concernant CSS. Idem sur les autres.
Ce sont des projets trop complexes, impossible de tout corriger, de tout s'occuper. Surtout pour une organization comme Mozilla qui est touuuuute petite à coté de ses concurrents...