j'ai le sentiment que ça doit tendre vers le zéro bugs, zéro besoins avec le temps, non ?
Au fil du temps, tu as des changements divers qui apparaissent et qui peuvent nécessiter des modifications plus ou moins légères du code: le 64 bits, l'IPv6, du TLS un peu partout, une libc remplacée par une autre, une bibliothèque qui change d'API ou d'ABI, une nouvelle architecture matérielle, un nouveau format de packaging, un systemd qui apparaît, une traduction dans une nouvelle langue, l'Unicode, etc. plein de choses qui dans l'idéal nécessite juste une modification légère et une recompilation en gros, qui dans le pratique peuvent s'avérer plus compliquées et surtout faire apparaître/dévoiler des bugs existants ou faire apparaître/ajouter de nouveaux bugs. Et si ces modifs ne sont pas faites, le code « vieillit » peu à peu, perd de son attrait, ne marche plus sur du matériel ou des systèmes récents, etc., bref se meurt. J'aurais plutôt tendance à dire que zéro besoin veut dire zéro utilisateur.
Vous avez déjà vu souvent des systèmes de suivi des bugs complètement vidés ? Suffit de voir celui de LinuxFr :). En fait, c'est plutôt « la nature a horreur du vide » : plus les développeurs corrigent vite, plus les utilisateurs soumettent des demandes (« cool c'est pris en compte », « chouette je peux retester », habitude de revenir régulièrement, de suivre le projet, etc.). Moins les développeurs corrigent, moins les utilisateurs en soumettent (« ça sert à rien de signaler mon bug ils s'en foutent », personne ne va plus lire les bugs, mort lente, reste juste les spammeurs qui sont fidèles eux).
[^] # Re: Qu'est-ce qui est nouveau ?
Posté par Benoît Sibaud (site web personnel) . En réponse à la dépêche Sortie de Gnu Bison 3.0. Évalué à 8. Dernière modification le 23 août 2013 à 11:41.
Au fil du temps, tu as des changements divers qui apparaissent et qui peuvent nécessiter des modifications plus ou moins légères du code: le 64 bits, l'IPv6, du TLS un peu partout, une libc remplacée par une autre, une bibliothèque qui change d'API ou d'ABI, une nouvelle architecture matérielle, un nouveau format de packaging, un systemd qui apparaît, une traduction dans une nouvelle langue, l'Unicode, etc. plein de choses qui dans l'idéal nécessite juste une modification légère et une recompilation en gros, qui dans le pratique peuvent s'avérer plus compliquées et surtout faire apparaître/dévoiler des bugs existants ou faire apparaître/ajouter de nouveaux bugs. Et si ces modifs ne sont pas faites, le code « vieillit » peu à peu, perd de son attrait, ne marche plus sur du matériel ou des systèmes récents, etc., bref se meurt. J'aurais plutôt tendance à dire que zéro besoin veut dire zéro utilisateur.
Vous avez déjà vu souvent des systèmes de suivi des bugs complètement vidés ? Suffit de voir celui de LinuxFr :). En fait, c'est plutôt « la nature a horreur du vide » : plus les développeurs corrigent vite, plus les utilisateurs soumettent des demandes (« cool c'est pris en compte », « chouette je peux retester », habitude de revenir régulièrement, de suivre le projet, etc.). Moins les développeurs corrigent, moins les utilisateurs en soumettent (« ça sert à rien de signaler mon bug ils s'en foutent », personne ne va plus lire les bugs, mort lente, reste juste les spammeurs qui sont fidèles eux).