Par patch à la volée, tu entends patch de script shell ?
oui. Des scripts non shell aussi (Python, Perl,…)
de fichier de conf ?
Oui.
Parce que dès qu'on rentre dans le dur (bug sur un binaire Red Hat, voire dans le noyeau), j'imagine mal des personnes recompiler un binaire avant de le livrer, non ?
Script ou binaire, c'est le même problème. C'est pas « officiel » tant que c'est pas releasé officiellement (ce qui inclut généralement une procédure de test). Il y avait aussi du C userland et kernel.
Et vos chefs acceptaient cette façon de faire (le client est roi, faites tout ce que vous pouvez pour qu'il soit satisfait), ou bien vous faisiez ça "à leur insu" ?
C'est pas parce qu'on est capable d'écrire le patch à la volée qu'on donne le résultat au client, et surtout pas en le présentant comme une solution supportée. L'intérêt c'est surtout de donner un paquet de test expérimental histoire de vérifier qu'on a bien compris le problème. Après ça dépend un peu du type de client (s'il a du mal avec la notion de « système de test» ou ne comprend pas trop quand on lui dit « ne pas utiliser en production » …) et du genre de bug.
Après, en pratique les clients qui rapportent un nouveau bug (pour lequel il n'y a pas déjà un patch) de manière compréhensible du premier coup sont quand même assez rare proportionnellement.
Ces propos sont les miens. Je ne suis plus affiliés à cette société. Je ne parle pas pour l'ensemble de la société telle qu'elle existe actuellement ou telle qu'elle existait lorsque j'y était employé. Contactez le support directement si vous voulez en savoir plus sur les procédures.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Mouraf
Posté par Krunch (courriel, site web personnel) . En réponse au journal Utiliser du Redhat avec du Support SuSE grâce à Microsoft, solution idéale ?. Évalué à 4.
oui. Des scripts non shell aussi (Python, Perl,…)
Oui.
Script ou binaire, c'est le même problème. C'est pas « officiel » tant que c'est pas releasé officiellement (ce qui inclut généralement une procédure de test). Il y avait aussi du C userland et kernel.
C'est pas parce qu'on est capable d'écrire le patch à la volée qu'on donne le résultat au client, et surtout pas en le présentant comme une solution supportée. L'intérêt c'est surtout de donner un paquet de test expérimental histoire de vérifier qu'on a bien compris le problème. Après ça dépend un peu du type de client (s'il a du mal avec la notion de « système de test» ou ne comprend pas trop quand on lui dit « ne pas utiliser en production » …) et du genre de bug.
Après, en pratique les clients qui rapportent un nouveau bug (pour lequel il n'y a pas déjà un patch) de manière compréhensible du premier coup sont quand même assez rare proportionnellement.
Ces propos sont les miens. Je ne suis plus affiliés à cette société. Je ne parle pas pour l'ensemble de la société telle qu'elle existe actuellement ou telle qu'elle existait lorsque j'y était employé. Contactez le support directement si vous voulez en savoir plus sur les procédures.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.