Je suis d'accord que le retour d'informations est très important. Seulement ce n'est pas si simple :-)
Pour un projet JEUNE qui plante dès qu'on le lance :
- soit on est dans les 5% des cas où ça plante pour une raison actuellement inconnue
- soit les concepteurs sont déjà au courant de ce plantage (ce qui représente donc les 95 % des cas)
--> une chance sur 20 que le rapport de bug soit utile
Et globalement les bugs sont très nombreux, et il est courant de tomber dessus.
Je prends les derniers problèmes auxquels j'ai eu à faire depuis lundi (donc sur 4 jours) :
- kexec : bug sur Debian dans un cas précis. Je viens de faire un rapport, avec résolution, ça m'a pris probablement 20 minutes
- libvirt : encore un bug, parmi une foulitude, ainsi qu'une fonctionnalité problématique. Je n'ai pas fait de rapport de bug car ce projet est truffé de pépins qui sont forcément connus tellement ils sautent aux yeux après quelques heures d'utilisation
- ovirt : un bug dès la première utilisation. Pas la peine de faire un rapport, car personne ne répond sur IRC alors qu'il y a plus de 30 connectés (zéro message en 8 heures sur le canal ovirt), et la mailing list est agressive. Pas envie de me prendre la tête avec des psychopathes. Ça m'a tout de même pris plus d'une demi-heure (fragmenté en plusieurs fois) pour tenter d'entrer en contact
- nut (gestion des onduleurs) : documentation à corriger/compléter pour un modèle d'onduleur que je viens d'acheter (je vais le faire ce week end car je n'ai pas compris à qui l'envoyer). Je pense que ça me prendra 10 minutes en tout
- webvirtmgr : j'ai fait un test pour voir ce qu'est ce projet. La documentation n'est pas terrible. J'ai proposé des mini-correctifs pour éclaircir deux points concernant les identifiants. Et j'ai indiqué qu'il y a un sérieux problème, toujours avec les identifiants, car il y a trois niveaux empilés : la gestion des utilisateurs et mots de passe est inutilement compliquée. Cela dit c'est un projet fait pour les besoins de l'unique développeur (je crois), donc rapport pas forcément utile. Ça m'a pris plus d'une demi-heure pour rédiger clairement mes propositions
- vlc : un problème avec un fluc audio venant d'une webradio. Je n'ai pas fait de rapport car je ne sais pas quelles informations sont utiles, je n'ai pas envie de passer 3 heures à dialoguer/chercher pour quelque chose qui est probablement très courant puisque je suis tombé dessus lors de ma 3ème ou 4ème utilisation d'une webradio
- vlc : un problème avec les listes de « stations » dans certains cas. Idem, première utilisation, bug. Donc forcément très connu (ou alors j'ai le super-pouvoir de découvrir les bugs que personne n'a jamais vu)
- PertternFly : un bug ou fonctionnalité mal faite dont le contournement est connu. Si c'est déjà connu, pas besoin de faire un rapport, mais pourquoi ce n'est pas corrigé ?
- je sais que j'en ai oublié un, mais je l'ai oublié en tapant le texte. Je n'ai pas rapporté le problème
Ça fait donc 10 problèmes en 4 jours (dont 2 pour libvirt), qui ont consommés environ 1h30 de mon temps. Je pense que c'est dans ma moyenne, ce qui fait 75 heures par an ! En précisant que je suis loin de rapporter tous les problèmes.
Combien de ces rapports auront une utilité ? Une fois enlevé les rapports qui ont déjà été faits sans que je les ai vus, ceux qui sont ignorés, ceux qui sont considérés comme PEBKAC, etc, il ne reste plus grand'chose.
Et en plus, toujours sur ces 4 jours : un bug sur l'IPMI d'une carte-mère SuperMicro (donc probablement de toutes). Une fonctionnalité de Microsoft Office qui se révèle enquiquinante dans certains cas. Un problème de documentation chez un petit éditeur français (ça empêche juste d'installer le produit...). Et à l'instant un bug chez Orange lorsqu'on compose le 1015 (incidents pour les lignes pro) à partir d'un mobile d'un autre opérateur, dans un cas précis.
Pas de rapport fait, car cela ne sert à rien dans 95% des cas, et surtout cela ne ME sert à rien dans 99,63105% des cas.
[^] # Re: Installé... Désinstallé
Posté par Kerro . En réponse à la dépêche Ring, la plate-forme de communication multimédia distribuée et sécurisée. Évalué à 7.
Je suis d'accord que le retour d'informations est très important. Seulement ce n'est pas si simple :-)
Pour un projet JEUNE qui plante dès qu'on le lance :
- soit on est dans les 5% des cas où ça plante pour une raison actuellement inconnue
- soit les concepteurs sont déjà au courant de ce plantage (ce qui représente donc les 95 % des cas)
--> une chance sur 20 que le rapport de bug soit utile
Et globalement les bugs sont très nombreux, et il est courant de tomber dessus.
Je prends les derniers problèmes auxquels j'ai eu à faire depuis lundi (donc sur 4 jours) :
- kexec : bug sur Debian dans un cas précis. Je viens de faire un rapport, avec résolution, ça m'a pris probablement 20 minutes
- libvirt : encore un bug, parmi une foulitude, ainsi qu'une fonctionnalité problématique. Je n'ai pas fait de rapport de bug car ce projet est truffé de pépins qui sont forcément connus tellement ils sautent aux yeux après quelques heures d'utilisation
- ovirt : un bug dès la première utilisation. Pas la peine de faire un rapport, car personne ne répond sur IRC alors qu'il y a plus de 30 connectés (zéro message en 8 heures sur le canal ovirt), et la mailing list est agressive. Pas envie de me prendre la tête avec des psychopathes. Ça m'a tout de même pris plus d'une demi-heure (fragmenté en plusieurs fois) pour tenter d'entrer en contact
- nut (gestion des onduleurs) : documentation à corriger/compléter pour un modèle d'onduleur que je viens d'acheter (je vais le faire ce week end car je n'ai pas compris à qui l'envoyer). Je pense que ça me prendra 10 minutes en tout
- webvirtmgr : j'ai fait un test pour voir ce qu'est ce projet. La documentation n'est pas terrible. J'ai proposé des mini-correctifs pour éclaircir deux points concernant les identifiants. Et j'ai indiqué qu'il y a un sérieux problème, toujours avec les identifiants, car il y a trois niveaux empilés : la gestion des utilisateurs et mots de passe est inutilement compliquée. Cela dit c'est un projet fait pour les besoins de l'unique développeur (je crois), donc rapport pas forcément utile. Ça m'a pris plus d'une demi-heure pour rédiger clairement mes propositions
- vlc : un problème avec un fluc audio venant d'une webradio. Je n'ai pas fait de rapport car je ne sais pas quelles informations sont utiles, je n'ai pas envie de passer 3 heures à dialoguer/chercher pour quelque chose qui est probablement très courant puisque je suis tombé dessus lors de ma 3ème ou 4ème utilisation d'une webradio
- vlc : un problème avec les listes de « stations » dans certains cas. Idem, première utilisation, bug. Donc forcément très connu (ou alors j'ai le super-pouvoir de découvrir les bugs que personne n'a jamais vu)
- PertternFly : un bug ou fonctionnalité mal faite dont le contournement est connu. Si c'est déjà connu, pas besoin de faire un rapport, mais pourquoi ce n'est pas corrigé ?
- je sais que j'en ai oublié un, mais je l'ai oublié en tapant le texte. Je n'ai pas rapporté le problème
Ça fait donc 10 problèmes en 4 jours (dont 2 pour libvirt), qui ont consommés environ 1h30 de mon temps. Je pense que c'est dans ma moyenne, ce qui fait 75 heures par an ! En précisant que je suis loin de rapporter tous les problèmes.
Combien de ces rapports auront une utilité ? Une fois enlevé les rapports qui ont déjà été faits sans que je les ai vus, ceux qui sont ignorés, ceux qui sont considérés comme PEBKAC, etc, il ne reste plus grand'chose.
Et en plus, toujours sur ces 4 jours : un bug sur l'IPMI d'une carte-mère SuperMicro (donc probablement de toutes). Une fonctionnalité de Microsoft Office qui se révèle enquiquinante dans certains cas. Un problème de documentation chez un petit éditeur français (ça empêche juste d'installer le produit...). Et à l'instant un bug chez Orange lorsqu'on compose le 1015 (incidents pour les lignes pro) à partir d'un mobile d'un autre opérateur, dans un cas précis.
Pas de rapport fait, car cela ne sert à rien dans 95% des cas, et surtout cela ne ME sert à rien dans 99,63105% des cas.