Il n'y a vraiment rien de mal à le faire tant que tout le monde peut supporter les coûts, les avantages et les risques.
... le correctif semble assez simple ... pour patcher le code moi-même
Lorsque vous avez un travail à faire, parfait (avoir une bibliothèque tierce qui est exactement ce que vous voulez) est l'ennemi de suffisamment bon (le patcher vous-même), et parfois vous devez faire des choses comme ça. J'ai fait un certain nombre de projets où nous avons acheté des licences source pour des bibliothèques commerciales afin que nous puissions résoudre les problèmes avant que le vendeur n'y arrive.
... les détracteurs veulent faire valoir que c'est presque toujours une mauvaise idée car elle est risquée et introduit une complexité gênante.
C'est une mauvaise idée si vous n'avez pas les côtelettes pour gérer la dissection du code de quelqu'un d'autre, l'identification d'un problème et l'écriture d'un correctif. C'est vrai que le code soit interne ou tiers; la seule différence est de savoir s'il a été projeté sur une cabine ou un mur de bâtiment avant d'atterrir sur vos genoux.
Si vos détracteurs repoussent simplement l'idée sans peser le coût de ne pas faire ce patch, ils ne font pas leurs devoirs. Si vous avez beaucoup de code interne affecté par le bogue que votre correctif corrigerait, vous devrez le parcourir et le modifier pour le contourner et tester à nouveau tout pour vous assurer qu'il fonctionne correctement. Ensuite, si jamais vous mettez à niveau le package vers une version corrigée, il se peut que vous deviez trouver et supprimer vos solutions de contournement et refaire un nouveau test. Il existe également des risques à le faire, comme manquer un cas que vous avez modifié ou des tests insuffisants. Personnellement, si j'ai la possibilité de corriger un bogue à sa source, je préfère de loin le faire plutôt que de courir autour du reste du code avec une tapette à mouches et j'espère avoir tout.
... le changement de code a été fait par nous ... il doit faire partie de notre base de code ... nous devons le présenter comme un nouveau projet et incorporer sa construction automatisée dans notre processus de construction.
Si vous faites un patch, le patch fait partie de votre propre code, ce qui signifie que vous devez l'intégrer à votre processus. Ce n'est pas différent que d'ajouter quelque chose qui est 100% votre code à votre système. Traitez la distribution tierce comme sacro-sainte et placez-la dans un module comme si c'était du code source. Tous les correctifs que vous écrivez sont stockés avec lui dans des fichiers séparés et appliqués dans le cadre du processus de génération. De cette façon, vous passez toujours d'une source propre à une source corrigée en passant par un produit intégré et pouvez montrer exactement ce qui se passe. (Certains décompressent, corrigent à la main, reconditionnent et stockent cela dans le contrôle de version. C'est mauvais.)
... nous tirerions leur code de leur référentiel de contrôle de source dans le nôtre, et nous perdons l'historique derrière toute modification de code ...
Si vous traitez la bibliothèque tierce comme une dépendance tierce, vous n'avez pas cet historique pour commencer et vous ne perdez rien. Si vous avez toujours accès au référentiel du tiers, vous pouvez le consulter si vous en avez besoin. Les versions tierces doivent être traitées comme des blobs amorphes que vous enregistrez dans votre propre système sans modification. Si vous devez examiner les modifications entre la version que vous utilisez et les versions ultérieures, vous pouvez le faire et, si vous le souhaitez, proposer des correctifs pour l'ancienne version qui incorporent les modifications que vous souhaitez.
De plus, cela semble être quelque chose de beaucoup trop compliqué pour un si petit changement de code qui doit être fait.
Si votre processus de construction est suffisamment sophistiqué, l'ajout de cela ne devrait pas être plus difficile que l'ajout de votre propre code. Il y a un peu de travail à faire pour arriver au point où le processus de décompression / patch / build est automagique, mais une fois terminé, il est fait pour toujours. Il peut y avoir un bogue maintenant, mais il pourrait y en avoir vingt à l'avenir. S'il y en a, vous serez beaucoup plus heureux que vous ayez jeté les bases pour soutenir tout cela maintenant, car cela rendra le traitement des 19 prochains beaucoup moins de travail.