Coup de gueule sur la méthode de développement de Firefox

[teoli2003]

Bonjour,

je suis depuis pas mal de temps le développement de Firefox, aussi je me permets une rapide critique.

Le développement de Firefox (et Gecko) marche relativement bien: les versions sortent à un rythme soutenu (plus rapide qu'IE, moins rapide que d'autres) et les nouvelles fonctionnalités arrivent (navigations privée, places, html5, Tracemonkey, CSS3, etc). La manière de développer Firefox a également évolué: de l'époque Fx 1.5 où chaque correction de bug devait attendre Fx 3, soit 2 versions majeures, à moins d'un miracle, à la méthode actuelle où chaque fonctionalité importante est développée puis mergée facilement(et testée) sur la branche principale, puis sur les branches spécifiques, l'efficacité (merci Mercurial!) a été globalement bien meilleure. La qualité du logiciel s'en ressent: bien meilleure et de moins en moins de régressions notables.

Mais je vois encore un problème: ce sont les évolutions de l'interface graphique. Non pas la sempiternelle guerre sur chaque nouveau thème, mais sur la quantité de projets démarrés, qui arrive sur le Trunk, qui sont retirés parce que pas assez mûrs pour la prochaine release toute proche (soit pour des questions de détails d'intéraction, soit pour des questions de performances) et qui ensuite meurent dans leur coin et loupent la version suivante.

J'en citerai 4:
1) la réfection du Ctrl-Tab. Elle est toujours-là, désactivée par défaut. Il y aurait des problèmes d'intéractions utilisateurs à corriger et à revoir. Mais rien n'a bougé depuis des mois et comme cela a raté 3.5, cela rate 3.6 et cela semble plus un projet enterré qu'autre chose.
2) About:tabs: la page devant remplacer le about:blank équivalente à certaines extensions. Là-aussi beaucoup de travail a été fait dessus pour la 3.5, cela n'a pas joué de peu. Et depuis plus rien.
3) Intégration à Windows 7: Jumplists et Tabs preview. Ca marchait, mais cela avait des soucis de perf. Il a été décidé de les repousser à Fx 3.7. Mais depuis lors (2 mois), plus rien n'a été fait dessus. Je veux bien qu'il y avait d'autres priorité au début, mais maintenant que la phase suivante est en cours, il serait bien de régler ces problèmes et de ne pas attendre 2 semaines avant la fin de l'étape suivante.
4) Plus abstrait, il y avait peu avant la 3.5 un projet pour transformer la barre d'onglet en une vrai barre d'outils où l'on puisse ajouter des boutons, des marque-pages, etc. Mais là aussi plus rien depuis la 3.5 (là je comprends mieux, c'est plus expérimental et le travail pour Fx 4 pourrait rendre tout cela caduc).

Autant les travaux sur le javascript, le layout, css etc semblent suivis et cohérent (à leur rythme, Tracemonkey s'améliore régulièrement, les normes CSS implémentées, l'accélération matérielle arrive, les OOP-plugins, etc), autant la manière de planifier le travail sur l'UI paraît aléatoire. Soit cela démarre très tardivement (c'est la première fois avec Fx 3.7/4.0 que les premiers schémas apparaissent dans la phase alpha), soit cela arrive jusqu'au Trunk puis est retiré et oublié, en passant à quelque chose de plus fun.

Parce que là j'entends parler de nouvelles interfaces pour les modules complémentaires, peut-être pour les marque-page, pour la fenêtre principale, etc. Mais tout ce qui était en cours semble figé.

Bref, vu de l'extérieur, cet aspect manque non pas de compétences mais d'un leader capable de motiver sur des détails moins intéressants et de maintenir le focus jusqu'à la release. La règle du 80/20. 80% des fonctionnalités sont faites en 20% du temps. Après c'est moins fun, mais tout aussi nécessaire sinon ça passe à la poubelle.

Voilà un petit coup de gueule.

[jpj]

Bonjour,

Quand j'ai vu le titre, j'ai cru à un message de bigbernie. Ben non !

Sinon, vraiment rien à répondre mais un grand merci pour ton suivi du développement, travail que peu ici, et moi le premier, n'ont le courage de faire. D'ailleurs, quand on voit ton message, on se dit que c'est stressant.

À part cela, il doit bien y avoir un endroit sur les sites de Mozilla pour faire part de ces remarques. Et/ou faire remonter à Tristan Nitot ou Pascal Chevrel. Parce que nous, ici, malheureusement…

[Thomas]

Je suis d'accord avec toi. Le mieux serait quand même d'écrire un message en anglais et de le transmettre à l'équipe chargé de l'UX. Par exemple Alexander Limi. On n'entends plus beaucoup Alex Faaborg parlé

[Roger]

Critique que je trouve très intéressante ! Tu viens de me faire rappeler qu'il y avait des projets qui avaient l'air prometteur et que j'avais oublié avec le temps donc que je n'attendais ni ne suivais plus, et pourtant j'aime me tenir informé, d'ailleurs c'est pour ça que tes posts sont très intéressants.

En espérant que Mozilla en soit conscient et que ça s'améliore de ce côté la également

[Benoit]

Je ne mettrais pas tous tes points dans le même panier.

Pour le Ctrl+Tab il y a un vrai problème d'intérêt de la fonctionnalité : on parle de ralentir et de désorganiser le fonctionnement d'un raccourci clavier, alors que c'est typiquement un truc de Power User.

Pour la page à l'ouverture d'un nouvel onglet par contre, on peut effectivement voir un manque de leadership : il faut faire un choix et ça ne vient pas. Aux dernières nouvelles ils ont carrément lancé un concours avec une échéance à la mi-mars.

Pour l'intégration à Windows 7, je crois que le travail avait été fait par un stagiaire cet été. Il n'est plus là et personne n'a repris son travail, problème d'organisation également.

Enfin il y a toujours eu des projets qui n'ont pas abouti on ne sait pas trop pourquoi et qui sont ensuite abandonnés ou mettent des années à aboutir. Par exemple le sélecteur de styles (quand une page en propose plusieurs) qui avait été développé par David Hyatt à l'époque de Phoenix. Il y a aujourd'hui vaguement quelque chose d'approchant dans le menu Affichage mais je ne suis même pas sûr qu'il retienne le choix d'une visite à l'autre.

[pirlouy]

Quand j'ai vu le titre, j'ai cru à un message de bigbernie. Ben non !

Punaise, j'ai pensé pareil !

À part ça, je suis complètement d'accord avec les idées qu'on soi-disant repousse, mais qui ne voient jamais le jour... Sinon je suis contre Benoît qui argumente sur les points au lieu du fond !

[teoli2003]

Après avoir lu vos (intéressants) commentaires, j'aimerais apporter quelques précisions

1) C'est un coup de gueule et pas une analyse fine. C'est quelque chose qui sort des tripes et je n'ai pas passer des heures à analyser les exemples.
2) Parce que c'est un coup de gueule, je ne vais pas le transmettre à Mozilla: il y a assez de messages "yaka" (yakafaire comme cela, yakafaire mieux, c'est nul, yavaitkafaire ainsi) qui doit leur arriver sans ajouter le mien. Surtout que, comme les auteurs des autres, je suis un cépamoikifé.
3) Le point principal a retenir, et peut-être à creuser, c'est l'impression de gaspillage de ressources humaines, alors que c'est la ressource la plus rare chez Mozilla. Pour être précis ce sont les "reviewers" de code la ressource critique: des gens maîtrisant sur le bout des doigts un module entier et tous les problèmes potentiels. Et plus que le codage lui-même, c'est cette phase le point critique. (D. Baron (ou un autre dév important) le dit d'ailleurs sur les newsgroup dans la discussion actuelle sur ce qu'il faut mettre dans Lorentz - de tête, ne me demandez pas de retrouver la citation précise).

Voilà le coup de gueule est passé.

Et maintenant j'aimerais bien que la bonne dizaine de bugs important en cours de travail arrive dans le trunk. ( x2 au test JS V8, préparation pour l'accélération matérielle, amélioration de la réactivité, du scroll (compositor phase2), accélération matérielle sous WIndows (Direct2d, DirectWrite), accélération matérielle vidéo, ...). Sans oublier plein de trucs attendus (JS: polymorphic inline cache, electrolysis sous Mac, 64-bits, ... par exemple).

Histoire de vous spammer sur les messages de Rumeurs et news sur le développement

Plein de yabon.

[Benoit]

J'ai vu que tu l'avais déjà fait, mais pour les autres il y a le billet de bogomil où on peut dire tout ce qui nous énerve chez Mozilla

[Flamme]

Ce qui m’ennuie un peu dans le développement des logiciels de Mozilla, c’est surtout la lenteur avec laquelle arrive les versions majeures.
Presque 2 ans entre la version 2 et 3 de Firefox. Encore 1 an entre la version 3 et 3.5. Du coup, on a vraiment l’impression d’attendre loooooongtemps avant de bénéficier de nouvelles fonctionnalités. Quant à Thunderbird… est-ce bien nécessaire de l’évoquer?
Même OOo, qui est une grosse usine, sort une nouvelle version tous les 6 mois.

[jpj]

… Du coup, on a vraiment l’impression d’attendre loooooongtemps avant de bénéficier de nouvelles fonctionnalités.

C'est un truc de geek, ça !

Sérieusement, il y a beaucoup d'utilisateurs qui supportent très mal qu'on leur change leur logiciel et, surtout, leurs habitudes. Sans parler des nouvelles fonctionnalité qui ne font pas que des heureux (cf. l'awesome bar et le nombre de messages qu'elle a suscité ici et ailleurs).

[calimo]

Ce qui m’ennuie un peu dans le développement des logiciels de Mozilla, c’est surtout la lenteur avec laquelle arrive les versions majeures.
Presque 2 ans entre la version 2 et 3 de Firefox. Encore 1 an entre la version 3 et 3.5. Du coup, on a vraiment l’impression d’attendre loooooongtemps avant de bénéficier de nouvelles fonctionnalités. Quant à Thunderbird… est-ce bien nécessaire de l’évoquer?

1 an, c'est déjà peu pour les développeurs d'extensions (et les gestionnaires de sites d'extensions). Mais au fond, le problème n'est pas tant la fréquence que l'absence de rétro-compatibilité.

Même OOo, qui est une grosse usine, sort une nouvelle version tous les 6 mois.

Tu rigoles ? La dernière (3.1) est sortie il y a bientôt un an… ou du moins le sera lors de la sortie de la 3.2. Ou alors tu parles des mises à jour mineures (3.1.1) ?

[teoli2003]

Du coup, on a vraiment l’impression d’attendre loooooongtemps avant de bénéficier de nouvelles fonctionnalités.

C'est juste mais Mozilla y travaille en modifiant ses processus.

L'attente entre Fx 2 et Fx 3 a eu lieu à cause de la méthode de développement: une branche de développement coupée très tôt (sur cvs) et un boulot gigantesque pour porter les développement Fx 2 -> Fx 3 et surtout à tout stabiliser.

Cela a été changé ensuite: HG au lieu de CVS (qui permet de gérer les branches beaucoup plus efficacement) et le système actuel: le trunk, une branche créée le plus tard possible, et des branches expérimentales pour les fonctionnalités importantes comme TM qui peuvent ainsi être développées à leur propre rythme, ...) . Le temps entre deux versions a ainsi été réduit à 1 an Fx 3 -> Fx 3.5 et maintenant à 7 mois (Fx 3.5 -> Fx 3.6); cette fois-ci en minimisant les changements apportés.

Et Mozilla veut expérimenter l'intégration de nouvelles fonctionnalités dans des versions mineures (Fx 3.6.x et OOPP vers mars si possible), mais ce n'est pas facile (compatibilité de l'API et des binaires). A voir si cela fonctionne.

De plus l'intégration du système d'extension JetPack a pour but (entre autres) de minimiser les problèmes de compatibilités entre versions de nombreuses extensions et d'ainsi de minimiser le travail pour les développeurs d'extensions entre deux versions.

Pour Tb 3, après Tb 2 le développement a été stoppé avec le départ des dévs principaux. Remonter une équipe puis créer une version a été très difficile. Il faudra voir le rythme qui sera désormais adopté, mais il est clair que Mozilla Messenger ne veut en aucun cas qu'une telle attente (3 ans) se reproduise.