Sylvestre Ledru a écrit 659 commentaires

Que c'est pas un jeu à somme nulle. Ca permet de libérer du temps pour faire autre chose que déplacer un bug dans un composant ou d'ajouter un mot clé (qui est un boulot peu intéressant et que les machines peuvent faire maintenant).
A la place, ce temps libéré nous permet d'améliorer les méta données (dans quelle version de firefox le bug a été introduit, par quel changement, etc) du bugs pour faciliter la vie des développeurs et des release managers. Automatiser le triage permet aussi d'être beaucoup plus réactif: les bugs sont devant bonnes personnes beaucoup plus rapidement (quelques minutes au lieu de quelques jours).

Firefox est un projet tellement énorme (presque 20M de lignes de code) qu'il devient critique d'améliorer tous les outils de qualité pour pouvoir tenir le rythme et la qualité…

L'outil fait du triage de bugs. Pas (encore) les corriger.

Un projet comme Firefox a des centaines de nouveaux bugs par jour, on peut pas tout faire…
Faut pas hésiter à insister/relancer.

wtc bosse plus sur nss depuis un moment, faut pinger les gens pour que ca avance :)

Si tu changes la pref entre temps.

Déposes un rapport bug sur flang

Philipp Kewisch est toujours actif sur Lightning.
Tu veux pas essayer de finaliser le travail pour que ça soit commit dans le tree? C'est pas si compliqué!

C'est dans Debian Buster (testing pour le moment):

$ apt install flang
Ca n'est pas dans le projet LLVM (pour le moment?)

Suite à cette discussion, j'ai ouvert: https://bugs.llvm.org/show_bug.cgi?id=40802

Faisant parti de la communauté llvm, j'ai posé la question sur cfe-dev (la ml dev clang), voila une réponse:
http://lists.llvm.org/pipermail/cfe-dev/2019-February/061345.html
(le thread a plein de réponses intéressantes)

tldr: il manque une option (-fstack-clash-protection), fortify source pourrait être amélioré

Généralement, les trois principales raisons qui ressortent de rester avec gcc sont:
- l'aspect licence: BSD-style (même si ça vient de changer pour une Apache2) vs GPL donc le vieux débat sur ce qui est le plus libre… Pour cette raison que certains BSD (ex: FreeBSD) en ont fait leur compilateur par défaut
- LLVM/Clang est un projet de grosses boites (Google, Apple, ARM, Sony, etc). gcc un peu moins…
- gcc fonctionne, pourquoi en changer?

Après, les deux projets collaborent souvent ensemble (et coordonnent sur certains points, exemple: https://reviews.llvm.org/D52034#1240216 & https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87442). Chris Lattner était lui même un développeur gcc et, avant la création de clang, avait proposé que LLVM devienne à la base d'une nouvelle version de gcc…

des critiques ont fusées à l’encontre de Clang

La discussion est ici:
https://pagure.io/fesco/issue/2020 (j'étais curieux)

J'avais lu que Apache 2 était aussi une option valide.
C'est plus le cas?

Quel dommage d'avoir choisi cette licence par contre… :/

J'ai ouvert ce ticket: https://github.com/NASA-SW-VnV/ikos/issues/42

Ca ressemble a https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=909818, non ?

Pourrais tu déposer un bug ? https://bugzilla.mozilla.org/
merci!

Tu as tout compris. On a été dans cette direction en augmentant la durée de la maintenance de 52 & 60 à environ un an et demi mais plus la release diverge de ESR, plus c'est difficile de backporter les patches.

Ca nécessite aussi de préserver l'infra de build (avec la sortie de 60, on a arrêté le support de Windows XP et arrêté buildbot).

Et tu verrais quoi comme solutions/alternatives? Augmenter la durée de maintenance ESR?

Si je disais cela, c'est que l'on (Mozilla) a plein d'outils pour s'assurer que Firefox se comporte correctement.
Quand le navigateur crash, la vaste majorité du temps, c'est de la faute d'un logiciel tiers (antivirus, malware, logiciel de sécurité) ou d'un driver pourri. Google avec Chrome fait fasse aux problèmes que Mozilla là dessus…

Bien souvent, désactiver l'antivirus permet d'identifier la source du problème.

Est-ce que tu as eu des crashes? Si oui, est ce que tu pourrais partager les urls qui sont dans about:crashes?
Si tu as déposé des bugs, pourrais-tu m'indiquer les numéros? Merci!

Si tu tournes sous Windows (on sait jamais), essayes de désactiver les antivirus.

Oui, on fait un package debian/ubuntu par crate. C'est une des forces de Debian!
Et oui pour le control.
On développe debcargo https://salsa.debian.org/rust-team/debcargo
Et le packaging se passe ici: https://salsa.debian.org/rust-team/debcargo-conf
Par exemple, pour un package "complexe" comme ripgrep: https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/ripgrep/debian

Mais la plupart des packages sont triviaux:
https://salsa.debian.org/rust-team/debcargo-conf/tree/master/src/rand/debian

C'est en cours: https://qa.debian.org/developer.php?login=pkg-rust-maintainers%40alioth-lists.debian.net
Mais c'est beaucoup plus compliqué qu'un ppa. En effet, on veut avoir tous les packages indépendamment dans l'archive.

Tout à fait:
https://kernel-recipes.org/en/2018/practical/

A Mozilla, on a compile le trunk de Firefox avec gcc 8 depuis un moment avec -Werror
On a créé ce meta bug pour lister tous les bugs trouvés ainsi:
https://bugzilla.mozilla.org/show_bug.cgi?id=1409283

Le plus courant est -Wclass-memaccess (pas mentionné dans cet article?)

On a ignoré -Wmultistatement-macros: pénible pour certaines de nos utilisations.

-Wformat-truncation a été amélioré, on a pu corriger quelques problèmes qui pouvaient (rarement) causé des problèmes.

Et, surtout, Firefox étant un bon test case, on a pu déposé des bugs upstream comme https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82728 (régression avec -Wunused-but-set-variable)

Bref, on recommande de faire pareil pour les logiciels importants… C'est bénéfique à la fois pour le compilateur et pour le projet (des vrais bugs sont trouvés ainsi).

Intéressant, au moins au sujet de Mozilla & Firefox, j'avais plutôt tendance à trouver que ça s'améliore!