La règle générale à suivre lors du portage d'un paquet open-source est de suivre les modifications que vous apportez pour le faire construire et exécuter sur votre système, et si vous pensez que les modifications seraient utiles à la communauté dans son ensemble, de les soumettre aux responsables du paquet. Habituellement, cela a aussi l'avantage de réduire l'effort pour les futurs portages du même paquet.
J'ai porté de nombreux logiciels sous VOS et OpenVOS, et j'essaie généralement d'envoyer mes modifications aux responsables. Mais pas toujours. Voici pourquoi.
1. Certains changements sont spécifiques à l'environnement OpenVOS. Si j'apporte une modification pour contourner une restriction qui ne s'applique qu'à OpenVOS, il n'est pas très utile d'envoyer cette modification en amont. Les mainteneurs rejettent généralement ces correctifs. Un exemple pourrait être la limite que les versions d'OpenVOS antérieures à la version 17.0 imposent sur la longueur des noms de fichiers.
2. Certains changements ont peut-être déjà été adoptés dans des versions ultérieures du paquet open-source. Avant d'envoyer des modifications, il est toujours bon de vérifier si quelqu'un vous a devancé. Cela est particulièrement vrai si le code source original n'a pas été téléchargé depuis un certain temps. Il est inutile de faire perdre du temps à tout le monde avec des modifications périmées.
3. Les changements sont en fait dans un produit différent. Par exemple, j'ai récemment terminé le portage de MySQL 5.1.48 sur OpenVOS version 17.1. J'ai pu l'amener à utiliser la nouvelle fonction de liens dynamiques d'OpenVOS 17.1 en apportant diverses modifications aux scripts de compilation. Mais il est inutile d'envoyer ces changements à l'équipe MySQL, car les modifications sont en fait dans le paquet autoconf, qui est maintenu par une autre équipe. Le paquet MySQL n'est qu'un utilisateur d'autoconf ; il n'a aucun contrôle sur ce qu'il fait pour une plate-forme donnée.
4. Trop de temps s'est écoulé entre le moment où j'ai pris une copie du paquet et aujourd'hui. Le problème ici est qu'un paquet open-source est une cible mouvante. Alors que certains paquets sont assez stables et sont rarement mis à jour, d'autres sont en constante évolution. J'ai passé 9 mois à porter MySQL 5.1.48, parce que c'était un travail à temps partiel, et parce que même une fois porté, je devais me synchroniser avec notre processus de test et de publication interne. Ainsi, lorsque j'ai été prêt à renvoyer quelques correctifs à l'équipe MySQL, ils étaient passés à la version 5.5 (dans le cycle généralement disponible) et à la version 5.6 (dans le cycle de développement). Beaucoup des changements que j'ai dû faire ne s'appliquent plus proprement ; dans certains cas, les fichiers sources ont été renommés ou déplacés dans de nouveaux répertoires. Je pourrais faire le travail pour mettre complètement à jour les correctifs de la version actuelle, mais cela représente beaucoup de travail et, du moins à mon avis, ne vaut pas l'effort que cela demanderait. La leçon pour moi est que j'aurais dû envoyer les changements en amont dès qu'ils étaient stables dans ma version. C'est évidemment une question de jugement.
Parfois, vous pouvez prendre toutes les mesures nécessaires pour envoyer un patch spécifique, bien écrit et bien débogué, et les responsables l'ignoreront ou le rejetteront. Cela peut être frustrant, mais ne vous énervez pas pour autant. De nombreux paquets open-source sont maintenus par des volontaires, et ils ont donc peu de temps pour s'occuper des correctifs pour les plates-formes peu communes.
Dans le cas du portage OpenVOS de MySQL 5.1.48, j'ai choisi d'ouvrir 5 rapports de bogue spécifiques pour des problèmes bien définis et indépendants dans le paquet MySQL qui, selon 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 à tous nos changements ; une étape qui est cohérente avec les termes de la licence publique GNU. Dans chacun de ces cas, j'ai fourni un correctif du code source qui montre les changements que je pense être appropriés pour clore le rapport de bogue. J'espère que l'équipe MySQL intégrera les 5 changements spécifiques que j'ai demandés. Ils représentent des problèmes qui pourraient affecter d'autres plateformes, et pas seulement OpenVOS. Si vous êtes curieux de voir les patchs que j'ai envoyés à MySQL, visitez http://bugs.mysql.com, cliquez sur Advanced Search, et cherchez les bugs 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.