C'est facile de dire que le kernel hacker n'a pas testé ses kernels, mais en l'occurence, il l'avait fait, et ça marchait sur sa configuration avec les bonnes options.
C'est bien joli de venir expliquer que ça fonctionnait sur sa machine à lui, mais le fait est que ça ne marchait QUE chez lui, et nulle part ailleurs.
On any machine - but preferably a different one than that used for compilation - do an upgrade or an install, and then check:
* Are all the expected files created at their expected places with the expected rights and owners?
* Are all the installation modifications (if any) effective?
* Are all binaries executable, and is the documentation accessible to the intended users?
Perfectionists should try various different installs and uninstalls to check whether all expected features are implemented correctly, for example without required packages.
If all of these tests are passed successfully, you are almost done, and should go to the last step of the process: submitting packages.»
En l'occurence, il aurait du tester son paquetage sur une autre machine avant de l'uploader. Ce RPM how-to s'applique aux paquetages normaux, et il est évident que dans le cadre d'un paquetage système critique, il faut tester de fond en comble la chose, et pas juste se contenter d'un « ça marche sur ma machine de test »
Après, tout le monde sait que MandrakeCooker est une distribution de test, que ça peut planter, être instable, et avoir des problèmes, mais je ne sais pas si tu as conscience du fait que de plus en plus de contributeurs râlent sur la ML Cooker parce que justement Mandrake leur fait faire le gros du boulot. En gros tout est uploadé sans avoir seulement testé, et c'est ensuite les contributeurs qui se tapent le gros du travail à tout déboguer. Le coup du kernel 2.6.10-2 illustre parfaitement ce problème, et franchement, version de dev ou pas, que cela soit précisé noir sur blanc dans le rpm-how-to ou pas, le bon sens aurait voulu que pour un nouveau noyau, il y ait eu un minimum de tests avant la mise en ligne.
Sinon, après, il ne faut pas venir essayer d'expliquer comment une Mandrake officielle qui crash des lecteurs de CD a bien pu sortir... Et le coup de la mauvaise implémentation de l'Atapi par LG a bon dos, parce que Mandrakelinux a été la seule distribution officielle à renconter le problème, et elle persisté à vendre des produits défectueux, sans seulement ajouter une mise en garde dans les boîtes (J'ai encore une boîte Discovery 9.2 ici). Pour rappel, les lecteurs de CD LG équipaient à l'époque plus de la moitié des fabricants d'ordinateurs de marque, et il était théoriquement impossible qu'un tel bogue passe inaperçu.
[^] # Re: re
Posté par Anonyme . En réponse au journal Mandrakelinux 10.2 Beta 2 pour x86-64. Évalué à 4.
C'est bien joli de venir expliquer que ça fonctionnait sur sa machine à lui, mais le fait est que ça ne marchait QUE chez lui, et nulle part ailleurs.
Maintenant, si tu lis bien ce qui est dit dans le lien qui a été donné http://qa.mandrakesoft.com/twiki/bin/view/Main/RpmHowTo#Testing_an_(...) , tu y trouveras ça :
« Install test
On any machine - but preferably a different one than that used for compilation - do an upgrade or an install, and then check:
* Are all the expected files created at their expected places with the expected rights and owners?
* Are all the installation modifications (if any) effective?
* Are all binaries executable, and is the documentation accessible to the intended users?
Perfectionists should try various different installs and uninstalls to check whether all expected features are implemented correctly, for example without required packages.
If all of these tests are passed successfully, you are almost done, and should go to the last step of the process: submitting packages.»
En l'occurence, il aurait du tester son paquetage sur une autre machine avant de l'uploader. Ce RPM how-to s'applique aux paquetages normaux, et il est évident que dans le cadre d'un paquetage système critique, il faut tester de fond en comble la chose, et pas juste se contenter d'un « ça marche sur ma machine de test »
Après, tout le monde sait que MandrakeCooker est une distribution de test, que ça peut planter, être instable, et avoir des problèmes, mais je ne sais pas si tu as conscience du fait que de plus en plus de contributeurs râlent sur la ML Cooker parce que justement Mandrake leur fait faire le gros du boulot. En gros tout est uploadé sans avoir seulement testé, et c'est ensuite les contributeurs qui se tapent le gros du travail à tout déboguer. Le coup du kernel 2.6.10-2 illustre parfaitement ce problème, et franchement, version de dev ou pas, que cela soit précisé noir sur blanc dans le rpm-how-to ou pas, le bon sens aurait voulu que pour un nouveau noyau, il y ait eu un minimum de tests avant la mise en ligne.
Sinon, après, il ne faut pas venir essayer d'expliquer comment une Mandrake officielle qui crash des lecteurs de CD a bien pu sortir... Et le coup de la mauvaise implémentation de l'Atapi par LG a bon dos, parce que Mandrakelinux a été la seule distribution officielle à renconter le problème, et elle persisté à vendre des produits défectueux, sans seulement ajouter une mise en garde dans les boîtes (J'ai encore une boîte Discovery 9.2 ici). Pour rappel, les lecteurs de CD LG équipaient à l'époque plus de la moitié des fabricants d'ordinateurs de marque, et il était théoriquement impossible qu'un tel bogue passe inaperçu.