Trata-se de um projeto do Launchpad?
(Se você já sabe que é um projeto do Launchpad, você pode pular isto.)
Nem todos os projetos encontrados no Launchpad são realmente hospedados e desenvolvidos lá - alguns são espelhos do código hospedado em outro lugar (GitHub / Gitorious / etc), outros vêm do Debian. Essas fontes originais são conhecidas como projetos "upstream", e geralmente é melhor enviar patches na origem e deixar as alterações chegarem "downstream" no Ubuntu (geralmente na próxima versão).
Deve ser claramente indicado na página do projeto se ele está hospedado em outro lugar ou no Launchpad. Se não, basta perguntar aos mantenedores do projeto como eles desejam receber as mudanças. Alguns projetos de upstream preferem arquivos de correção simples, outros preferem envios / envios através de seus respectivos hosts.
Como uma nota especial, os pacotes oficiais do Ubuntu (software armazenado nos repositórios oficiais do Ubuntu que você pode instalar do Centro de Software) tem algumas maneiras diferentes de enviar correções, pois muitos desses pacotes vêm diretamente do Debian e devem idealmente ser corrigido lá e não apenas no Ubuntu. (Esta é uma outra pergunta).
Como enviar um patch
A maneira geral de enviar um patch é que você faça sua ramificação, faça o commit localmente e envie de volta para o Launchpad:
bzr push lp:~user/project/branch-name
Você pode então propor a sua ramificação para mesclar no pai de onde você veio, seja através do site, ou usando o comando bzr lp-propose
.
Se você registrou um bug, e sua filial corrige, certifique-se de fazer o seguinte ao cometer, onde 000000
é substituído pelo seu número de bug, supondo que seja um bug relatado no Launchpad, e não em outro lugar em vez disso.
bzr commit --fixes=lp:000000
Uma nota sobre o fluxo de trabalho "padrão"
Esse é basicamente o fluxo de trabalho típico moderno , que você pode comparar ao GitHub. No entanto, o Launchpad tem sido um pouco mais longo, portanto, esse fluxo de trabalho evoluiu após o fato, em vez de ser incorporado ao sistema desde o início, portanto, alguns projetos mais antigos podem depender de outros métodos de aceitação de patches. A maioria dos projetos mais recentes dependem desse fluxo de trabalho, onde no GitHub os "pull requests" sempre estiveram lá, e as pessoas simplesmente usam o padrão porque nunca houve um meio de fazer algo diferente no GitHub.