La règle générale à suivre lors du portage d'un paquet open source est de garder une trace des modifications que vous apportez pour le compiler et l'exécuter sur votre système, et si vous pensez que ces modifications pourraient être utiles à la communauté dans son ensemble, de les soumettre aux responsables du paquet. En général, cela présente également l'avantage de réduire l'effort nécessaire pour les futurs portages du même paquet.
J'ai porté de nombreux progiciels vers VOS et OpenVOS, et j'essaie généralement d'envoyer mes modifications aux responsables de la maintenance. Mais pas toujours. Voici pourquoi.
1. Certaines modifications sont spécifiques à l'environnement OpenVOS. Si j'apporte une modification pour contourner une restriction qui s'applique uniquement à OpenVOS, il n'est pas très utile d'envoyer cette modification en amont. Les responsables de la maintenance rejettent généralement ce type de correctifs. Un exemple pourrait être la limite imposée par les versions antérieures à 17.0 d'OpenVOS sur la longueur des noms de fichiers.
2. Certaines modifications ont peut-être déjà été adoptées dans les versions ultérieures du paquet open source. Avant d'envoyer des modifications, il est toujours judicieux de vérifier si quelqu'un ne vous a pas devancé. Cela est particulièrement vrai si vous avez téléchargé le code source original il y a longtemps. Il est inutile de faire perdre du temps à tout le monde avec des modifications obsolètes.
3. Les modifications concernent en réalité un autre produit. Par exemple, j'ai récemment terminé le portage de MySQL 5.1.48 vers OpenVOS Release 17.1. J'ai réussi à le faire fonctionner avec la nouvelle fonctionnalité de liaison dynamique sur OpenVOS 17.1 en apportant diverses modifications aux scripts de compilation. Mais il est inutile d'envoyer ces modifications à l'équipe MySQL, car elles concernent en réalité le paquet autoconf, qui est géré par une autre équipe. Le paquet MySQL n'est qu'un utilisateur d'autoconf ; il n'a aucun contrôle sur ce que fait autoconf pour une plate-forme donnée.
4. Trop de temps s'est écoulé entre le moment où j'ai récupéré une copie du paquet et aujourd'hui. Le problème ici est qu'un paquet open source est une cible mouvante. Si certains paquets sont assez stables et rarement mis à jour, d'autres subissent des changements constants. J'ai passé 9 mois à porter MySQL 5.1.48, car c'était un travail à temps partiel et parce que, même une fois le portage terminé, je devais me synchroniser avec notre processus interne de test et de publication. Ainsi, lorsque j'étais prêt à renvoyer certains correctifs à l'équipe MySQL, celle-ci était déjà passée à la version 5.5 (dans le cycle de disponibilité générale) et à la version 5.6 (dans le cycle de développement). Bon nombre des modifications que j'avais dû apporter ne s'appliquaient plus correctement ; dans certains cas, les fichiers source avaient été renommés ou déplacés vers de nouveaux répertoires. Je pourrais mettre à jour complètement les correctifs pour les adapter à la version actuelle, mais cela représente beaucoup de travail et, à mon avis du moins, cela ne vaut pas la peine. La leçon que j'en tire, c'est que j'aurais dû envoyer les modifications en amont dès qu'elles étaient stables dans ma version. C'est évidemment une question de jugement.
Parfois, même si vous avez suivi toutes les étapes nécessaires pour envoyer un correctif spécifique, bien rédigé et bien débogué, les responsables de maintenance peuvent tout de même l'ignorer ou le rejeter. Cela peut être frustrant, mais ne vous énervez pas pour autant. De nombreux paquets open source sont gérés par des bénévoles, qui disposent donc d'un temps limité pour traiter les correctifs destinés à des plateformes peu courantes.
Dans le cas du portage OpenVOS de MySQL 5.1.48, j'ai choisi d'ouvrir 5 rapports de bogues spécifiques pour des problèmes bien définis et indépendants dans le paquet MySQL qui, d'après mes recherches, sont toujours présents dans la version de développement actuelle. J'ai également ouvert un rapport de bogue afin de pouvoir contribuer à toutes nos modifications, une démarche conforme aux termes de la licence publique GNU. Dans chacun de ces cas, j'ai fourni un correctif du code source qui montre les modifications que je juge appropriées pour clore le rapport de bogue. J'espère que l'équipe MySQL intégrera les 5 modifications spécifiques que j'ai demandées. Elles représentent des problèmes qui pourraient affecter d'autres plateformes, et pas seulement OpenVOS. Si vous souhaitez consulter les correctifs que j'ai envoyés à MySQL, rendez-vous sur http://bugs.mysql.com, cliquez sur « Advanced Search » (Recherche avancée) et recherchez les bogues 44300, 44832, 60907, 60908, 60910, 60911, 60912 et 60913.
Le port OpenVOS de MySQL 5.1.48 sera appelé « MySQL for OpenVOS, Release 2.0 » par Stratus, et sera bientôt disponible, en même temps que la version 17.1 d'OpenVOS.