A regra geral ao portar um pacote de código aberto é manter um registro das alterações feitas para que ele seja compilado e executado em seu sistema e, se você achar que as alterações serão úteis para a comunidade em geral, enviá-las aos mantenedores do pacote. Normalmente, isso também tem a vantagem de reduzir o esforço para futuras portas do mesmo pacote.
Eu portei muitos pacotes de software para VOS e OpenVOS e geralmente tento enviar minhas alterações aos mantenedores. Mas nem sempre. Eis o motivo.
1. Algumas alterações são específicas do ambiente OpenVOS. Se eu fizer uma alteração para contornar uma restrição que se aplica apenas ao OpenVOS, não faz sentido enviar essa alteração para o upstream. Os mantenedores geralmente rejeitam esses patches. Um exemplo pode ser o limite que as versões anteriores à 17.0 do OpenVOS impõem ao comprimento dos nomes de arquivos.
2. Algumas alterações podem já ter sido adotadas em versões posteriores do pacote de código aberto. Antes de enviar qualquer alteração, é sempre uma boa ideia verificar se alguém já fez essa alteração antes de você. Isso é especialmente verdadeiro se já faz algum tempo desde que você baixou o código-fonte original. Não faz sentido desperdiçar o tempo de todos com alterações desatualizadas.
3. As alterações estão, na verdade, em um produto diferente. Por exemplo, recentemente terminei de portar o MySQL 5.1.48 para o OpenVOS Release 17.1. Consegui fazer com que ele usasse o novo recurso de vinculação dinâmica no OpenVOS 17.1, fazendo várias alterações nos scripts de compilação. Mas não faz sentido enviar essas alterações para a equipe do MySQL, porque elas estão, na verdade, no pacote autoconf, que é mantido por uma equipe diferente. O pacote MySQL é apenas um usuário do autoconf; eles não têm nenhum controle sobre o que ele faz para qualquer plataforma específica.
4. Muito tempo se passou entre o momento em que obtive uma cópia do pacote e hoje. O problema aqui é que um pacote de código aberto é um alvo em movimento. Enquanto alguns pacotes são bastante estáveis e raramente são atualizados, outros estão passando por mudanças constantes. Passei nove meses portando o MySQL 5.1.48, porque era um trabalho em tempo parcial e porque, mesmo depois de portado, eu precisava sincronizar com nosso processo interno de teste e lançamento. Então, quando eu estava pronto para enviar alguns patches de volta para a equipe do MySQL, eles já haviam passado para a versão 5.5 (no ciclo de disponibilidade geral) e para a versão 5.6 (no ciclo de desenvolvimento). Muitas das alterações que eu precisei fazer não se aplicam mais de forma limpa; em alguns casos, os arquivos de origem foram renomeados ou movidos para novos diretórios. Eu poderia fazer o trabalho de atualizar completamente os patches para a versão atual, mas isso dá muito trabalho e, pelo menos na minha opinião, não vale o esforço necessário. A lição que tirei disso é que eu deveria ter enviado as alterações para o upstream assim que elas ficassem estáveis na minha versão. Obviamente, isso é uma questão de julgamento.
Às vezes, você pode tomar todas as medidas corretas para enviar um patch específico, bem escrito e bem depurado, e os mantenedores ainda assim irão ignorá-lo ou rejeitá-lo. Isso pode ser frustrante, mas não se preocupe com isso. Muitos pacotes de código aberto são mantidos por voluntários e, portanto, eles têm tempo limitado para lidar com patches para plataformas incomuns.
No caso da porta OpenVOS do MySQL 5.1.48, optei por abrir cinco relatórios de bugs específicos para problemas bem definidos e independentes no pacote MySQL que, segundo minha pesquisa, ainda estão presentes na versão de desenvolvimento atual. Também abri um relatório de bug para poder contribuir com todas as nossas alterações, uma medida que está de acordo com os termos da Licença Pública GNU. Em cada um desses casos, contribui com um patch de código-fonte que mostra as alterações que considero apropriadas para encerrar o relatório de bug. Espero que a equipe do MySQL integre as cinco alterações específicas que solicitei. Elas representam problemas que podem afetar outras plataformas, não apenas o OpenVOS. Se você estiver curioso para ver os patches que enviei ao MySQL, acesse http://bugs.mysql.com, clique em Pesquisa avançada e procure os bugs 44300, 44832, 60907, 60908, 60910, 60911, 60912 e 60913.
A porta OpenVOS do MySQL 5.1.48 será chamada de “MySQL para OpenVOS, Versão 2.0” pela Stratus e estará disponível em breve, simultaneamente com a disponibilidade do OpenVOS Versão 17.1.