Patcher un logiciel open source lors de la mise à niveau n'est pas une option?

J'ai récemment rencontré un bug plutôt ennuyeux (confirmé) dans un progiciel open source que j'ai intégré à mon application. Selon le traqueur de problèmes publics, ce bogue a été résolu dans la dernière version du logiciel.

Parfois, vous AVEZ BESOIN de cette correction de bogue pour éviter une refonte coûteuse d'un module particulier, mais pour des raisons techniques et / ou politiques, vous ne pourrez pas effectuer la mise à niveau vers la dernière version.

En inspectant les modifications de code apportées, le correctif semble assez simple pour que je pense qu'une option viable serait de patcher le code moi-même et de recompiler ma version approuvée actuelle du logiciel, mais les détracteurs veulent faire valoir que c'est presque toujours une mauvaise idée en ce qu'il est risqué et introduit une complexité gênante.

À leurs yeux, car ce changement de code a été fait par nous uniquement pour notre usage, il doit faire partie de notre base de code, ce qui signifie que plutôt que d'introduire le logiciel open source en tant que dépendance tierce, nous devons l'introduire comme un nouveau projet et intégrer sa construction automatisée dans notre processus de construction.

Pour moi, je pense que c'est une mauvaise direction, car 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 les modifications de code antérieures. De plus, cela semble être quelque chose de beaucoup trop compliqué pour un si petit changement de code qui doit être fait.

Serait-ce une mauvaise idée de faire ce qui précède dans ce cas? Si oui, quelle est la situation idéale lorsque l'open source doit changer, mais uniquement pour votre seul bénéfice en interne?

Si vous ne pouvez pas utiliser une version ultérieure qui n'a pas le problème que vous rencontrez, les seules options que vous avez sont soit

• vivre avec le problème et trouver une solution de contournement
• forkez la bibliothèque et corrigez-la dans votre version privée (ce que vous feriez effectivement)
• jetez l'éponge et dites à vos gestionnaires que le problème est insurmontable (ce qui serait un mensonge, car vous avez deux autres options à votre disposition).

J'ai été à votre place, l'option 2 (fabriquer une fourchette personnalisée) est souvent la solution la plus agréable au goût disponible. C'est la vie lorsqu'il s'agit de bibliothèques open source, en particulier celles qui évoluent rapidement et ont la mauvaise habitude de rompre la compatibilité descendante entre les versions (ce qui, selon mon expérience, est la raison la plus courante de devoir faire des choses comme ça).
Pour plus de quelques bibliothèques OSS, cela m'a conduit, ainsi que les équipes dont j'ai fait partie, à mandater des wrappers autour de chacun d'entre eux et à accéder aux fonctionnalités des bibliothèques tierces exclusivement via ces wrappers. De cette façon, si nous devons remplacer une bibliothèque tierce par une version si différente qu'elle briserait notre code, les modifications sont au moins largement limitées à ce wrapper. Ce n'est pas le plus agréable (ajoute du code, peut ajouter de la complexité et des performances de coût) mais parfois c'est le seul moyen de conserver votre raison.

Ce que vous êtes sur le point de faire est une mauvaise idée dans le cas le plus courant où vous regroupez des logiciels tiers et avez l' intention de suivre leurs versions . Habituellement, les gens le font parce qu'ils veulent une fonctionnalité dans le composant tiers que les responsables ne sont pas disposés à implémenter ou à implémenter de la manière dont vous avez besoin.

Cependant, vous avez explicitement déclaré que vous ne mettriez pas à niveau le code fourni. Cela fait de vous le responsable du composant tiers. Par conséquent, que le correctif soit une bonne idée ou non dépend uniquement de la compréhension de ce code suffisamment pour être sûr de l'effet souhaité. Vos tests d'intégration devraient être suffisants pour vérifier qu'il fait bien ce que vous supposez. Par conséquent, comme vous dites la situation, il me semble que vos critiques ont tort.

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.

Ce que vous voulez faire semble assez raisonnable, mais il semble qu'il y ait des raisons (sonores?) De s'y opposer. Je ne comparerai pas les solutions proposées, mais il y a peut-être un moyen de prendre votre gâteau et de le manger aussi:

Si le projet open source en question le permet, apportez votre correction de bug rétroportée à leur référentiel. Autrement dit, si vous utilisez la version 1.5.2 et que la version stable actuelle est 1.6.1, ajoutez un correctif à 1.5.2. S'il est adopté, vous pouvez récupérer la source fixe directement à partir du référentiel (peut-être en tant que version 1.5.3) et rendre tout le monde heureux.

En d'autres termes: corrigez-le pour tous ceux qui sont dans votre situation aussi. Bien sûr, cela n'est possible que si le projet prend en charge (ou au moins autorise) les mises à jour des versions publiées. Mais c'est certainement une pratique assez courante de nos jours.