A regra geral ao portar um pacote de código aberto é acompanhar as mudanças que você faz para que ele seja construído e executado em seu sistema, e se você acha que as mudanças seriam úteis para a comunidade em geral, submetê-las aos mantenedores do pacote. Normalmente, isto também tem o benefício de reduzir o esforço para futuras portas do mesmo pacote.
Tenho portado muitos pacotes de software para VOS e OpenVOS, e geralmente tento enviar minhas mudanças para os mantenedores. Mas nem sempre. Aqui está o porquê.
1. Algumas mudanças são específicas para o ambiente OpenVOS. Se eu fizer uma mudança para contornar uma restrição que só se aplica ao OpenVOS, então não faz muito sentido enviar esta mudança para cima. Os mantenedores geralmente rejeitarão tais correções. Um exemplo pode ser o limite que as versões pré-17.0 do OpenVOS colocam nos comprimentos dos nomes dos arquivos.
2. Algumas mudanças podem já ter sido adotadas em versões posteriores do pacote de código-fonte aberto. Antes de enviar qualquer mudança, é sempre uma boa idéia verificar e ver se alguém o venceu na mudança. Isto é especialmente verdadeiro se já faz algum tempo desde que você baixou o código-fonte original. Não adianta desperdiçar o tempo de todos com mudanças obsoletas.
3. As mudanças estão na verdade em um produto diferente. Por exemplo, recentemente terminei de portar o MySQL 5.1.48 para a versão 17.1 do OpenVOS. Consegui fazer com que ele utilizasse o novo recurso de link dinâmico no OpenVOS 17.1, fazendo várias mudanças nos scripts de construção. Mas não faz sentido enviar estas mudanças para a equipe do MySQL, porque as mudanças estão de fato 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 uma determinada plataforma.
4. Já se passou muito tempo entre quando peguei 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 são pouco atualizados, outros estão passando por constantes mudanças. Eu passei 9 meses portando o MySQL 5.1.48, porque foi um esforço em tempo parcial, e porque mesmo uma vez portado, eu tive que sincronizar com nosso processo interno de teste e lançamento. Assim, quando eu estava pronto para enviar alguns patches de volta para a equipe do MySQL, eles tinham subido para a versão 5.5 (no ciclo geralmente disponível) e para a versão 5.6 (no ciclo de desenvolvimento). Muitas das mudanças que eu tive que fazer não se aplicam mais de forma limpa; em alguns casos, os arquivos fonte 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 é muito trabalho e, pelo menos a meu ver, não vale a pena o esforço que isso exigiria. A lição para mim é que eu deveria ter enviado as mudanças assim que elas se mantiveram estáveis em minha versão. Isso é obviamente uma espécie de chamada de julgamento.
Às vezes, você pode tomar todas as medidas certas para enviar um remendo específico, bem escrito e bem depurado, e os mantenedores ainda o ignorarão ou o rejeitarão. Isso pode ser frustrante, mas não se preocupe com isso. Muitos pacotes de código aberto são mantidos por voluntários, e assim eles têm tempo limitado para lidar com patches para plataformas incomuns.
No caso da porta OpenVOS do MySQL 5.1.48, eu optei por abrir 5 relatórios de bug específicos para questões bem definidas e independentes no pacote MySQL que minha pesquisa mostra que ainda estão presentes na versão atual de desenvolvimento. Eu também abri um relatório de bug para que eu pudesse contribuir com todas as nossas mudanças; um passo que é consistente com os termos da Licença Pública GNU. Em cada um destes casos, eu contribuí com um patch de código fonte que mostra as mudanças que eu acho que são apropriadas para fechar o relatório de bug. Tenho esperança de que a equipe do MySQL integre as 5 mudanças específicas que solicitei. Elas representam questões que poderiam afetar outras plataformas, não apenas o OpenVOS. Se você estiver curioso para ver os patches que enviei ao MySQL, visite http://bugs.mysql.com, clique em Pesquisa Avançada e procure pelos bugs 44300, 44832, 60907, 60908, 60910, 60911, 60912, e 60913.
A porta OpenVOS do MySQL 5.1.48 será chamada "MySQL for OpenVOS, Release 2.0" por Stratus, e estará disponível em breve, concomitantemente com a disponibilidade da versão 17.1 do OpenVOS.
Empresa