La regla general cuando se porta un paquete de código abierto es hacer un seguimiento de los cambios que se hacen para que se construya y se ejecute en el sistema, y si se cree que los cambios serían útiles para la comunidad en general, presentarlos a los mantenedores del paquete. Por lo general, esto también tiene el beneficio de reducir el esfuerzo para futuros puertos del mismo paquete.
He portado muchos paquetes de software a VOS y OpenVOS, y normalmente intento enviar mis cambios a los mantenedores. Pero no siempre. Aquí está el porqué.
1. Algunos cambios son específicos del entorno de OpenVOS. Si hago un cambio para trabajar alrededor de una restricción que sólo se aplica a OpenVOS, entonces no tiene mucho sentido enviar este cambio río arriba. Los mantenedores generalmente rechazarán tales parches. Un ejemplo podría ser el límite que las versiones anteriores a la 17.0 de OpenVOS ponen a las longitudes de los nombres de los archivos.
2. Es posible que algunos cambios ya hayan sido adoptados en versiones posteriores del paquete de código abierto. Antes de enviar cualquier cambio, siempre es una buena idea comprobar y ver si alguien se ha adelantado al cambio. Esto es especialmente cierto si ha pasado un tiempo desde que descargaste el código fuente original. No tiene sentido perder el tiempo de todos con cambios obsoletos.
3. Los cambios son en realidad en un producto diferente. Por ejemplo, recientemente terminé de portar MySQL 5.1.48 a OpenVOS versión 17.1. Pude conseguir que usara la nueva facilidad de enlace dinámico en OpenVOS 17.1 haciendo varios cambios en los scripts de construcción. Pero no tiene sentido enviar estos cambios al equipo de MySQL, porque los cambios están en el paquete autoconf, que es mantenido por un equipo diferente. El paquete de MySQL es sólo un usuario de autoconf; no tienen ningún control sobre lo que hace para cualquier plataforma dada.
4. Ha pasado demasiado tiempo entre que cogí una copia del paquete y hoy. El problema aquí es que un paquete de código abierto es un blanco móvil. Mientras que algunos paquetes son bastante estables y se actualizan con poca frecuencia, otros sufren cambios constantes. Pasé 9 meses portando MySQL 5.1.48, porque era un esfuerzo a tiempo parcial, y porque incluso una vez que fue portada, tuve que sincronizarla con nuestro proceso interno de prueba y liberación. Así que para cuando estuve listo para enviar algunos parches al equipo de MySQL, ellos habían avanzado a la versión 5.5 (en el ciclo de disponibilidad general) y a la versión 5.6 (en el ciclo de desarrollo). Muchos de los cambios que tuve que hacer ya no se aplican limpiamente; en algunos casos, los archivos de origen han sido renombrados o movidos a nuevos directorios. Podría hacer el trabajo de actualizar completamente los parches a la versión actual, pero eso es mucho trabajo y, al menos en mi opinión, no vale la pena el esfuerzo que requeriría. La lección para mí es que debería haber enviado los cambios tan pronto como fueran estables en mi versión. Eso es obviamente algo así como una llamada de juicio.
A veces se pueden dar todos los pasos necesarios para enviar un parche específico, bien escrito y depurado, y los encargados de su mantenimiento lo ignorarán o lo rechazarán. Eso puede ser frustrante, pero no se preocupe por ello. Muchos paquetes de código abierto son mantenidos por voluntarios, por lo que tienen un tiempo limitado para ocuparse de los parches para plataformas poco comunes.
En el caso del puerto OpenVOS de MySQL 5.1.48, elegí abrir 5 informes de errores específicos para temas bien definidos e independientes en el paquete de MySQL que, según mis investigaciones, todavía están presentes en la versión de desarrollo actual. También abrí un reporte de errores para poder contribuir con todos nuestros cambios; un paso que es consistente con los términos de la Licencia Pública GNU. En cada uno de estos casos, contribuí con un parche de código fuente que muestra los cambios que creo que son apropiados para cerrar el informe de errores. Espero que el equipo de MySQL integre los 5 cambios específicos que solicité. Representan problemas que podrían afectar a otras plataformas, no sólo a OpenVOS. Si tienes curiosidad por ver los parches que he enviado a MySQL, visita http://bugs.mysql.com, haz clic en Advanced Search, y busca los bugs 44300, 44832, 60907, 60908, 60910, 60911, 60912, y 60913.
El puerto OpenVOS de MySQL 5.1.48 se llamará "MySQL for OpenVOS, Release 2.0" por Stratus, y estará disponible en general pronto, junto con la disponibilidad de la versión 17.1 de OpenVOS.
Empresa