Contribuindo para o pacote ou ramo de upstream?

Question

Enquanto aprende sobre o desenvolvimento e & amp; embalagem, há uma parte que não é muito clara para mim. Então, digamos que estamos no meio do desenvolvimento ativo (por exemplo, Raring) antes do congelamento de recursos e quero trabalhar para melhorar um programa empacotado para o Ubuntu - por exemplo, Guake Eu gostaria de corrigir um bug, adicionar um novo recurso, etc. Agora, vejo duas maneiras de fazer isso:

1. trabalhando no tronco do upstream lp: guake , enviando uma proposta de mesclagem e solicitando ao mantenedor do pacote para o Ubuntu ressincronizar o pacote
2. trabalhando na ramificação do pacote ubuntu: guake , enviando minha correção para lá e permitindo que o projeto ou o responsável pelo pacote se preocupe encaminhando essa correção para o upstream ou criando uma versão corrigida do guake-ubuntu0 para o repositório de pacotes

Uma dessas duas abordagens é melhor? Depende da situação (por exemplo, tipo de contribuição - correção de bug ou um novo recurso; fase de desenvolvimento) e, em caso afirmativo, como? Seria ótimo se alguém experiente pudesse fornecer mais orientações e conselhos sobre esse assunto.

Ao trabalhar no ecossistema do GitHub, sempre parece muito claro - tudo está centrado na última versão de desenvolvimento e todos os pedidos de pull são enviados para ele (pelo menos eu nunca esbarrei em alguém enviando coisas para alguma versão antiga 0.7 do projeto X ), enquanto no Launchpad essa disparidade entre o pacote e as ramificações do upstream me confunde. Não tenho certeza se é melhor executar a última compilação de desenvolvimento do Ubuntu e acessar a fonte que está disponível lá (por meio de apt-get source <package> ) ou se deveria obter o código de tronco mais recente no meu Ubuntu estável, fazer a alteração e ver se pode de alguma forma fazer com que os mantenedores encaminhem essa mudança para o pacote (ressincronizando, verificando se as compilações ainda funcionam contra outras bibliotecas do Ubuntu, etc.)

Eu leio tanto o antigo quanto o novo guia de embalagem, mas ainda me deixou confuso sobre essas questões.

    

Answer 1

Você precisa conceitualmente separar o Ubuntu do upstream, mesmo quando o branch upstream estiver hospedado no Launchpad. A grande maioria dos pacotes no Ubuntu tem sua ramificação upstream hospedada em outro lugar completamente (ou seja, GitHub ou SourceForge). Um projeto upstream hospedado no Launchpad pode ter um relacionamento mais próximo com o Ubuntu, mas deve ser tratado essencialmente como qualquer outro projeto upstream.

O Ubuntu redistribui o software upstream normalmente apenas fazendo alterações quando necessário para a integração com todos os outros softwares que enviamos. Na maioria dos casos, a melhor opção é corrigir os erros no envio. Dessa forma, a correção atinge a maioria das pessoas. Isso também reduz a carga no Ubuntu, não tendo que manter as modificações locais.

Então, idealmente, o processo parece sua primeira opção. Você conserta o bug no upstream, o upstream faz um novo lançamento e o Ubuntu atualiza para essa versão. Como você percebeu, as coisas nem sempre funcionam assim.

Às vezes, os cronogramas de lançamento do Ubuntu e de um projeto upstream podem não estar alinhados. Digamos que você tenha encontrado e consertado um bug que gostaria de ver no próximo lançamento do Ubuntu, mas o Ubuntu está lançando em três meses e o upstream não tem idéia de quando será seu próximo lançamento. Em uma situação como essa, a melhor abordagem é consertar o bug do upstream, mas voltar ao release no Ubuntu como um patch específico do Ubuntu. Este também é o caso quando estamos corrigindo uma versão estável do Ubuntu, onde provavelmente não poderemos incluir uma nova versão original.

Às vezes, o Ubuntu leva as alterações para o upstream. Se o bug estiver nessas mudanças, a correção deve ir diretamente para o Ubuntu. Isso inclui problemas em coisas como a embalagem.

É improvável que novos recursos sejam aceitos no Ubuntu, a menos que já tenham sido aceitos no upstream. Frequentemente, aceitamos patches corrigindo um problema específico antes que ele seja aplicado a montante em prol do projeto maior, mas normalmente não gostamos de nos desviar do upstream em termos de design ou funcionalidade.

Eu sei que basicamente estou dizendo que depende, mas isso acontece!