Recentemente, encontrei um bug irritante (confirmado) em um pacote de software de código aberto que integrei ao meu aplicativo. De acordo com o rastreador de problemas públicos, esse bug foi resolvido na versão mais recente do software.
Ocasionalmente, você PRECISA dessa correção para evitar um refator caro de um módulo específico; no entanto, por razões técnicas e / ou políticas, você não poderá atualizar para a versão mais recente.
Ao inspecionar as alterações feitas no código, a correção parece simples o suficiente para que eu sinta que uma opção viável seria corrigir o código pessoalmente e recompilar minha versão atual aprovada do software, no entanto os detratores querem argumentar que essa é quase sempre uma má idéia na medida em que é arriscado e introduz uma complexidade problemática.
Para eles, porque essa alteração de código foi feita por nós apenas para nosso uso, ela deve fazer parte de nossa base de códigos, o que significa que, em vez de introduzir o software de código aberto como uma dependência de terceiros, devemos apresentá-lo como um novo projeto e incorporar sua criação automatizada em nosso processo de criação.
Para mim, acho que isso está errado, pois estaríamos retirando o código do repositório de controle de origem para o nosso e perdemos o histórico por trás de qualquer alteração no código que veio antes disso. Também parece ser algo muito complicado para uma alteração tão pequena do código que precisa ser feita.
Seria uma má idéia fazer o que foi dito acima neste caso? Em caso afirmativo, qual é a situação ideal quando o código aberto precisa mudar, mas apenas para seu benefício exclusivo em casa?
fonte
Respostas:
Se você não pode usar uma versão posterior que não tenha o problema que está encontrando, as únicas opções que você tem são:
Estive na sua posição, a opção 2 (faça um garfo personalizado) é geralmente a solução mais saborosa disponível. Essa é a vida quando se lida com bibliotecas de código aberto, especialmente as que evoluem rapidamente e têm o mau hábito de quebrar a compatibilidade entre versões anteriores (que, na minha experiência, é o motivo mais comum para fazer coisas como essa).
Por mais de algumas bibliotecas OSS, isso me levou a fazer parte de equipes para exigir wrappers em todo e qualquer um deles e acessar a funcionalidade de bibliotecas de terceiros exclusivamente por meio desses wrappers. Dessa forma, se precisarmos substituir uma biblioteca de terceiros por uma versão tão diferente que interrompa nosso código, as alterações serão pelo menos amplamente restritas a esse invólucro. Não é o melhor (adiciona código, pode adicionar complexidade e desempenho de custos), mas às vezes é a única maneira de manter sua sanidade.
fonte
O que você está prestes a fazer é uma má idéia no caso mais comum em que você agrupa software de terceiros e pretende acompanhar seus lançamentos . Geralmente, as pessoas fazem isso porque desejam um recurso no componente de terceiros que os mantenedores não estão dispostos a implementar ou a implementar da maneira que você precisa.
Você, no entanto, disse explicitamente que não atualizará o código incluído. Isso o torna efetivamente o mantenedor do componente de terceiros. Portanto, se o patch é uma boa ideia ou não, depende apenas de você entender esse código suficientemente bem para ter certeza do efeito desejado. Seus testes de integração devem ser suficientes para verificar se ele está realmente fazendo o que você supõe. Portanto, ao contar a situação, parece-me que seus revisores estão errados.
fonte
Realmente não há nada de errado em fazer isso, desde que todos possam suportar os custos, benefícios e riscos.
Quando você tem um trabalho a fazer, a perfeição (ter uma biblioteca de terceiros exatamente o que você deseja) é inimiga do suficiente (corrigindo você mesmo) e, às vezes, é preciso fazer coisas assim. Eu já fiz vários projetos nos quais compramos licenças de origem para bibliotecas comerciais, para que pudéssemos resolver problemas antes que o fornecedor chegasse.
É uma péssima idéia se você não tiver os recursos necessários para dissecar o código de outra pessoa, identificar um problema e escrever uma correção. Isso é verdade se o código é interno ou de terceiros; a única diferença é se foi jogado sobre um cubículo ou sobre um muro antes de cair no seu colo.
Se seus detratores estão simplesmente descartando a idéia sem pesar os custos de não fazer esse patch, eles não estão fazendo a lição de casa. Se você tiver muitos códigos internos afetados pelo bug que o seu patch corrigia, será necessário alterá-lo para contorná-lo e testar novamente tudo para garantir que funcione corretamente. Então, se você atualizar o pacote para uma versão corrigida, talvez seja necessário localizar e remover as soluções alternativas e testar novamente. Também há riscos em fazer isso, como a falta de um caso que você alterou ou o teste insuficiente. Pessoalmente, se eu tiver a oportunidade de corrigir um bug em sua fonte, prefiro fazê-lo lá do que procurar o resto do código com um mata-moscas e espero ter tudo.
Se você estiver fazendo um patch, ele faz parte do seu próprio código, o que significa que você precisa torná-lo parte do seu processo. Isso não é diferente de adicionar algo que é 100% seu código ao seu sistema. Trate a distribuição de terceiros como sacrossanto e coloque-a em um módulo como se fosse um código-fonte. Quaisquer correções que você escreve são armazenadas em arquivos separados e aplicadas como parte do processo de criação. Dessa forma, você sempre passa de uma fonte limpa para uma fonte corrigida para um produto construído e pode mostrar exatamente o que está acontecendo. (Algumas pessoas descompactam, remendam manualmente, reembalam e armazenam isso no controle de versão. Isso é ruim.)
Se você estiver tratando a biblioteca de terceiros como uma dependência de terceiros, não terá esse histórico e não estará perdendo nada. Se você tiver acesso contínuo ao repositório de terceiros, poderá consultar o que for necessário. Os lançamentos de terceiros devem ser tratados como blobs amorfos que você faz check-in no seu próprio sistema inalterados. Se você precisar examinar as alterações entre o release que está usando e os posteriores, poderá fazer isso e, se desejar, criar patches para a versão antiga que incorporam as alterações desejadas.
Se o seu processo de compilação for suficientemente sofisticado, adicionar isso não deve ser mais difícil do que adicionar seu próprio código. Há uma pequena quantidade de trabalho para chegar ao ponto em que o processo de descompactação / correção / compilação é automagic, mas, uma vez feito, é feito para sempre. Pode haver um bug agora, mas pode haver vinte no futuro. Se houver, você ficará muito mais feliz ao estabelecer as bases para apoiar tudo isso agora, porque isso fará com que lidar com os próximos 19 seja muito menos trabalhoso.
fonte
O que você quer fazer parece bastante razoável, mas parece que existem (som?) Razões de processo para se opor a isso. Não vou comparar as soluções propostas, mas talvez haja uma maneira de você comer seu bolo e também comê-lo:
Se o projeto de código aberto em questão permitir, contribua com a correção de bug portada para o repositório. Ou seja, se você estiver usando a versão 1.5.2 e a versão estável atual for 1.6.1, contribua com um patch para a 1.5.2. Se for adotado, você pode buscar a fonte fixa diretamente do repositório (talvez como a versão 1.5.3) e fazer todo mundo feliz.
Em outras palavras: faça o patch para todos os outros que também estão na sua situação. Obviamente, isso só é possível se o projeto suportar (ou pelo menos permitir) atualizações para as versões lançadas. Mas essa é certamente uma prática bastante comum nos dias de hoje.
fonte