En l'occurence ce n'est pas un patch mais une base de définitions de malware. Donc je peux très bien imaginer un meeting avec un manager dire à un moment donné "on est toujours en retard face aux concurrents X, Y, on doit livrer les bases de définitions plus vite". Et un ingénieur de dire "on fait des tests pour chaque base de définitions mais depuis qu'on fait ces tests on n'a jamais vu une seul erreur et il n'y a aucune raison parce que ce n'est pas du code, on peut peut-être les supprimer pour livrer plus vite".
Et pouf on vire les tests.
La question après reste de l'impact:
- est-ce que l'image de marque de exchange a souffert au point qu'une seule entreprise va dire j'en ai marre, je migre sur autre chose ? Sachant que sortir d'exchange (comme sortir d'autres truc comme Lotus Notes ou Groupwise) ce n'est pas du tout facile et c'est le genre de gros projet que toute le monde préferrerait laisser à son successeur. Au pire ça a du donner l'envie à certains admins de migrer d'un exchange on-prem vers office365 pour ne pas avoir à bosser le 1er janvier et laisser Microsoft résoudre son problème tout seul.
- est-ce que ça a coûté cher aux clients? Il n'y a il me semble pas eu de perte de donnée puisque l'email est asynchrone et que la plupart des serveurs de mails essayent de renvoyer pendant 2 à 4 jours. En terme de disruption de flux de travail le 1er janvier pas grand monde bosse. Ça a du faire chier des admins qui étaient de piquets et des organisations qui bossent 24/24 (services hospitaliers, etc) mais ceux-ci n'utilisent pas en général l'email et les public folders pour des urgences donc ça n'a pas du être très dérangeant.
Donc passé le momen cocasse de se dire "ha ha ha une date en int32 les n00bs!" l'impact n'est pas si grand. Du coup doit-on dans ce cas rajouter ce test à chaque sortie de baseline ou simplement produire le patch, tester sur des numéros de versions prévues pour ces 30 prochaines années et ajouter un commentaire dans la doc interne que si on change ce code ou la nomemclature de version il faut retester?
[^] # Re: Pas la date
Posté par Psychofox (Mastodon) . En réponse au journal Le bug de l'an 2000 a 22 ans !. Évalué à 4.
En l'occurence ce n'est pas un patch mais une base de définitions de malware. Donc je peux très bien imaginer un meeting avec un manager dire à un moment donné "on est toujours en retard face aux concurrents X, Y, on doit livrer les bases de définitions plus vite". Et un ingénieur de dire "on fait des tests pour chaque base de définitions mais depuis qu'on fait ces tests on n'a jamais vu une seul erreur et il n'y a aucune raison parce que ce n'est pas du code, on peut peut-être les supprimer pour livrer plus vite".
Et pouf on vire les tests.
La question après reste de l'impact:
- est-ce que l'image de marque de exchange a souffert au point qu'une seule entreprise va dire j'en ai marre, je migre sur autre chose ? Sachant que sortir d'exchange (comme sortir d'autres truc comme Lotus Notes ou Groupwise) ce n'est pas du tout facile et c'est le genre de gros projet que toute le monde préferrerait laisser à son successeur. Au pire ça a du donner l'envie à certains admins de migrer d'un exchange on-prem vers office365 pour ne pas avoir à bosser le 1er janvier et laisser Microsoft résoudre son problème tout seul.
- est-ce que ça a coûté cher aux clients? Il n'y a il me semble pas eu de perte de donnée puisque l'email est asynchrone et que la plupart des serveurs de mails essayent de renvoyer pendant 2 à 4 jours. En terme de disruption de flux de travail le 1er janvier pas grand monde bosse. Ça a du faire chier des admins qui étaient de piquets et des organisations qui bossent 24/24 (services hospitaliers, etc) mais ceux-ci n'utilisent pas en général l'email et les public folders pour des urgences donc ça n'a pas du être très dérangeant.
Donc passé le momen cocasse de se dire "ha ha ha une date en int32 les n00bs!" l'impact n'est pas si grand. Du coup doit-on dans ce cas rajouter ce test à chaque sortie de baseline ou simplement produire le patch, tester sur des numéros de versions prévues pour ces 30 prochaines années et ajouter un commentaire dans la doc interne que si on change ce code ou la nomemclature de version il faut retester?