Généralement, ce qui est fait sur la gestion des bugs c'est de faire appel aux "utilisateurs avancés" de la distribution (cela n'intéresse que peu les développeurs généralement qui désespèrent des rapports de bugs non qualifiés de certains utilisateurs qui confondent le bugzilla et les forums, oubliant bien souvent de se greffer sur un bug existant pour le compléter).
Il y a des squash bugs party dans la plupart des distributions (genre un week-end pendant la phase d'alpha ou bêta) permettant de former des personnes à l'utilisation des outils et effectuer les relances des utilisateurs pour tests, éventuellement remonter upstream pour faire s'intéresser les développeurs au bug qualifié.
Monter ce genre d'équipe interface entre l'utilisateur, les développeurs et l'upstream permet d'augmenter la qualité des remontées et des diagnostics (à défaut de proposer des patchs directement pour l'upstream) et c'est la valeur ajoutée de la plupart des distributions (pour éviter que l'upstream croule sous des rapports de bugs de versions obsolètes - selon eux - notamment).
J'ose espérer que cela fonctionne bien chez Ubuntu vu la base d'utilisateurs ;-)
Toute la difficulté est surtout que les utilisateurs ont la version stable et non celle en développement (que ce soit au niveau logiciel ou au niveau distribution), ce qui ne motive àmha ni développeurs de la distrib' ni l'upstream.
J'ai tout de même l'impression que dans la communauté du libre (au sens large), il nous reste un gros effort à faire pour démocratiser les bonnes pratiques de développement et proposer des process documentés plutôt qu'ad'hoc afin que tout le monde s'y retrouve :
- faire que l'upstream pense plus au "release early, release often" (seuls les logiciels majeurs sont en version svn dans les distribs), estampiller une version svn comme suffisament stable et la publier (en version mineure par exemple) permet d'avancer plus vite et promeut l'intégration dans les distribs qui n'ont pas non plus le temps de suivre chaque commit.
- faire que les utilisateurs et utilisateurs avancés pensent à "comment reproduire le bug" et est-il reproductible dans une version plus récente de l'upstream pour pousser les dévs de la distrib' à monter de version
[^] # Re: Toujours aussi bien.. sauf que
Posté par BAud (site web personnel) . En réponse à la dépêche Test d'Ubuntu Jaunty (9.04). Évalué à 3.
Il y a des squash bugs party dans la plupart des distributions (genre un week-end pendant la phase d'alpha ou bêta) permettant de former des personnes à l'utilisation des outils et effectuer les relances des utilisateurs pour tests, éventuellement remonter upstream pour faire s'intéresser les développeurs au bug qualifié.
Monter ce genre d'équipe interface entre l'utilisateur, les développeurs et l'upstream permet d'augmenter la qualité des remontées et des diagnostics (à défaut de proposer des patchs directement pour l'upstream) et c'est la valeur ajoutée de la plupart des distributions (pour éviter que l'upstream croule sous des rapports de bugs de versions obsolètes - selon eux - notamment).
J'ose espérer que cela fonctionne bien chez Ubuntu vu la base d'utilisateurs ;-)
Toute la difficulté est surtout que les utilisateurs ont la version stable et non celle en développement (que ce soit au niveau logiciel ou au niveau distribution), ce qui ne motive àmha ni développeurs de la distrib' ni l'upstream.
J'ai tout de même l'impression que dans la communauté du libre (au sens large), il nous reste un gros effort à faire pour démocratiser les bonnes pratiques de développement et proposer des process documentés plutôt qu'ad'hoc afin que tout le monde s'y retrouve :
- faire que l'upstream pense plus au "release early, release often" (seuls les logiciels majeurs sont en version svn dans les distribs), estampiller une version svn comme suffisament stable et la publier (en version mineure par exemple) permet d'avancer plus vite et promeut l'intégration dans les distribs qui n'ont pas non plus le temps de suivre chaque commit.
- faire que les utilisateurs et utilisateurs avancés pensent à "comment reproduire le bug" et est-il reproductible dans une version plus récente de l'upstream pour pousser les dévs de la distrib' à monter de version