Como Dobey mencionou, para que um patch seja aceito em uma versão já lançada do Ubuntu, ele deve passar pela atualização estável da versão (SRU) processo. A barra de entrada para SRUs é bastante alta. Uma maneira simples de resumir o pensamento por trás do processo pode ser: "O bug que conhecemos é melhor do que o bug que não conhecemos". Na prática, isso significa que somente as correções de erros direcionadas são permitidas e nenhuma alteração é muito "intrusiva".
Há vários requisitos que devem ser atendidos para prosseguir com um SRU:
- O bug é corrigido na versão atual de desenvolvimento (ou seja, quantal).
- A descrição do relatório de erros deve ser atualizada para incluir uma justificativa de porque a correção é necessária na versão estável, um caso de teste para reproduzir o bug e verificar se foi corrigido, e uma discussão do potencial de regressão da correção. li>
- A equipe do Launchpad
ubuntu-srudeve estar inscrita no relatório de erros. - O pacote é então enviado para release
-proposedPara que isso aconteça, você precisará passar pelo processo de patrocínio (mais informações abaixo).
Depois de tudo o que ocorreu, a equipe do SRU verificará se o pacote em -proposed resolve o bug. Em seguida, o pacote será enviado para -updates depois de ter passado por um período mínimo de 7 dias.
Encontrar a pessoa certa
Sua pergunta sugere que, às vezes, o Launchpad parece que é onde os patches vão morrer. Infelizmente, se você não conhece o processo, pode parecer assim, mas eu juro que não é tão ruim assim. Felizmente, a principal coisa que você precisa saber é simples. Confira o processo de patrocínio para todos os detalhes e algumas dicas, mas a parte mais importante é inscrever-se no ubuntu-sponsors equipe para o relatório de bug. Isso garante que ele irá aparecer na fila de patrocínio e obter olhei por um desenvolvedor honesto para o Ubuntu.
Se você precisar falar algo em tempo real, #ubuntu-devel no Freenode IRC fará o truque. Verifique o tópico do canal para o piloto de patch atual. Eles estão lá para ajudar você. Se não houver um piloto em serviço, sinta-se à vontade para pedir ajuda no canal, mas, por favor, seja paciente.
Preparando tudo para ir
Para tornar o processo o mais rápido possível, há algumas coisas a fazer.
Atualize a descrição do bug para se parecer com:
% bl0ck_qu0te% Em seguida, prepare seus patches. As coisas serão mais rápidas se você fornecer debdiffs que cuida de todos os bits de embalagem, em vez de um patch contra a fonte upstream. Isso inclui o uso do sistema de correção de pacotes, se ele usar um. Felizmente add-patch de ubuntu-dev-tools pode cuidar disso para você.
Vamos passar por isso. Primeiro pegue a fonte e o patch no relatório do bug:
$ pull-lp-source compiz precise
$ wget https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/974242/+attachment/3141645/+files/fix-974242.patch
Agora vamos adicionar o patch ao pacote fonte:
$ cd compiz-0.9.7.8/
$ add-patch ../fix-974242.patch
Isso adicionará o patch a debian/patches e executará dch solicitando que você adicione uma nova entrada a debian/changelog . Ajuste a entrada para segmentar proposta e incremente o número da versão para que fique abaixo da próxima versão enviada para o lançamento de desenvolvimento. Assim:
compiz (1:0.9.7.8-0ubuntu1.1) precise-proposed; urgency=low
* debian/patches/fix-974242.patch: [DESCRIBE CHANGES HERE]
-- Your Name <[email protected]> Mon, 11 Jun 2012 17:37:59 -0400
O arquivo em debian/patches/fix-974242.patch também tem alguns cabeçalhos que você pode querer editar:
## Description: add some description
## Origin/Author: add some origin or author
## Bug: bug URL
Agora, crie seu novo pacote de fontes:
$ debuild -S -us
E crie o debdiff:
$ cd ..
$ debdiff compiz_0.9.7.8-0ubuntu1.dsc compiz_0.9.7.8-0ubuntu1.1.dsc > sru-for-lp-974242.debdiff
Agora você pode anexar o arquivo debdiff resultante ao seu relatório de erros.