1/ les tests automatiques qui sont exécutés à la suite de la compilation ; ces tests comprennent en particulier des tests de non-régression (en principe chaque fois qu'un bug est corrigé, le correctif devrait être accompagné d'un test de non-régression pour détecter dés le compilation la réapparition du bug), des tests de validation des filtres d'import/export basés sur la collection des fichiers à problème publiés avec les rapports de bug et des tests associés à chaque nouvelle fonctionnalité ;
2/ les tests manuels faits par les utilisateurs ;
Il y a aussi des tests avec des outils de fuzzing ainsi que des scans du code source par Coverity. Je ne sais pas si le fuzzing est utilisé de façon régulière mais les scan coverity le sont si j'en crois les rapports automatiques publiés sur la liste développeurs.
Les tests automatiques sont bien sûr exécutés à chaque compilation du système d'intégration continue. La seule VM pour processeur ARM que je vois est celle du viewer Android, il n'y en a point pour Raspberry Pi. Il n'y a donc rien de changé pour cette plateforme et les tests ne vont pas retomber sur les utilisateurs, ils y sont déjà.
Je ne vois pas en quoi cela puisse être une avancé 'preferé' dans le journal que le build 'linux 32 bits' soit retiré mais bon chacun ses choix.
Tous les processeurs modernes animant des ordinateurs de bureau sont des 64 bits. Cela devient du gaspillage de ressources de produire des builds pour des plateformes obsolètes.
[^] # Re: bof
Posté par Jean-Baptiste Faure . En réponse au journal À propos de LibreOffice 6.3. Évalué à 3.
Il y a 2 sortes de tests :
1/ les tests automatiques qui sont exécutés à la suite de la compilation ; ces tests comprennent en particulier des tests de non-régression (en principe chaque fois qu'un bug est corrigé, le correctif devrait être accompagné d'un test de non-régression pour détecter dés le compilation la réapparition du bug), des tests de validation des filtres d'import/export basés sur la collection des fichiers à problème publiés avec les rapports de bug et des tests associés à chaque nouvelle fonctionnalité ;
2/ les tests manuels faits par les utilisateurs ;
Il y a aussi des tests avec des outils de fuzzing ainsi que des scans du code source par Coverity. Je ne sais pas si le fuzzing est utilisé de façon régulière mais les scan coverity le sont si j'en crois les rapports automatiques publiés sur la liste développeurs.
Les tests automatiques sont bien sûr exécutés à chaque compilation du système d'intégration continue. La seule VM pour processeur ARM que je vois est celle du viewer Android, il n'y en a point pour Raspberry Pi. Il n'y a donc rien de changé pour cette plateforme et les tests ne vont pas retomber sur les utilisateurs, ils y sont déjà.
Tous les processeurs modernes animant des ordinateurs de bureau sont des 64 bits. Cela devient du gaspillage de ressources de produire des builds pour des plateformes obsolètes.