Si tu rapportes un bug sur une vieille version, le bug n'est plus forcément valide.
Ça dépend de ce que tu appelles «vieille version». Les gros projets ont plusieurs versions en parallèle (stable, développement, etc), et ils peuvent maintenir les vieilles versions.
C'est donc mieux si le rapporteur peux reproduire lui même avec une version plus récente pour être sûr que le bug est toujours d'actualité
C'est le point de vue du développeur. Pour l'utilisateur, mettre à jour son bureau pour une version plus récente, c'est un peu n'importe quoi. Ça veut dire qu'il faut renoncer au systèmes de paquets de sa distribution, ou mettre en place deux versions du bureau en parallèle (je ne sais même pas si c'est possible), etc. Du point de vue logistique, c'est le genre de manips envisageables pour un développeur, mais pas pour un utilisateur.
Mais en le faisant tu augmentes les chances que ton bug soit corrigé en faisant toi même une partie de l'investigation, et c'est à mon avis vrai pour tous les projets libres.
Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs, si le projet est organisé pour les traiter. Par exemple, les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes. Ces infos là, c'est ce qui remonte directement de tes utilisateurs, et pas de la communauté de développeurs. Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).
Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur. Ça n'a pas forcément de valeur pour corriger un bug tel qu'on l'imagine quand on est développeur, mais ça donne une idée de si ton programme fonctionne chez les vrais gens et s'il leur donne satisfaction.
[^] # Re: Si j'ai bien compris...
Posté par arnaudus . En réponse au journal LibreOffice, altération d'images intégrées :( ?. Évalué à 3.
Ça dépend de ce que tu appelles «vieille version». Les gros projets ont plusieurs versions en parallèle (stable, développement, etc), et ils peuvent maintenir les vieilles versions.
C'est le point de vue du développeur. Pour l'utilisateur, mettre à jour son bureau pour une version plus récente, c'est un peu n'importe quoi. Ça veut dire qu'il faut renoncer au systèmes de paquets de sa distribution, ou mettre en place deux versions du bureau en parallèle (je ne sais même pas si c'est possible), etc. Du point de vue logistique, c'est le genre de manips envisageables pour un développeur, mais pas pour un utilisateur.
Je pense que les projets bénéficient beaucoup des rapports de bugs des simples utilisateurs, si le projet est organisé pour les traiter. Par exemple, les utilisateurs vont remonter beaucoup de bugs dupliqués, obsolètes, dûs aux patches de leur distribution, ou à des composants externes (bibliothèques tierces), voire remonter des comportements qui ne sont pas des bugs ou des suggestions irréalistes. Ces infos là, c'est ce qui remonte directement de tes utilisateurs, et pas de la communauté de développeurs. Si tu n'as pas les ressources pour traiter ces bugs, alors il ne faut pas encourager les remontées (typiquement, le cas de la fenêtre qui s'ouvre, «le logiciel a planté, voulez-vous remonter le bug? Oui/Non", tu ne peux pas imaginer avoir d'autres infos utiles que celles que le système te remonte).
Sur le fond, quelqu'un qui prend du temps pour te remonter un bug ou une suggestion, ça a toujours de la valeur. Ça n'a pas forcément de valeur pour corriger un bug tel qu'on l'imagine quand on est développeur, mais ça donne une idée de si ton programme fonctionne chez les vrais gens et s'il leur donne satisfaction.