| dgit-sponsorship(7) | dgit | dgit-sponsorship(7) |
NOME¶
dgit-sponsorship - tutorial para patrocínio de envio Debian, usando git
INTRODUÇÃO E ESCOPO¶
Este tutorial descreve como um contribuidor patrocinado de Debian e um DD (ou DM) patrocinador podem colaborar e publicar usando git.
O patrocinador tem que pretender usar dgit para o envio. (Se o patrocinador não usar dgit, não é possível publicar de modo apropriado um ramo git de um patrocinado.)
É melhor se o patrocinado também usar dgit; mas também está coberto (mais tarde) o caso em que o patrocinado fornece uma proposta a enviar na forma de pacote fonte, mas o patrocinador deseja trabalhar em git.
Este tutorial não fornece uma lista de verificação para a revisão do patrocinador. Espera-se que ambos contribuidores esteja familiarizados com o empacotamento Debian e os processos de Debian, e com o git.
FLUXO DE TRABALHO DO PATROCINADO¶
Esta secção é endereçada ao patrocinado:
Geral¶
Você deve preparar o pacote como se fosse você próprio a envia-lo com "dgit push-source" ou "dgit push-built".
Para um NMU direto, consulte dgit-nmu-simple(7).
Se você é o (prospectivo) maintainer, você pode adoptar qualquer fluxo de trabalho git (compatível com dgit). Os tutoriais dgit-maint-*(7) descrevem algumas das possibilidades.
Preparação do envio¶
Você deve passar por todos os passos que um maintainer que auto-envia iria passar, incluindo compilar para testes especiais, e verificar via uma compilação formal (ex. usando "dgit sbuild") que o pacote compila em (ou no lançamento visado).
No ponto em que você iria, se fosse um DD, fazer o envio real ao correr dgit push, você entrega o trabalho ao seu patrocinador.
Se você vai usar uma das opções "--quilt=" para dgit, ou "dgit --gbp" ou "dgit --dpm", você tem de especificar isso no seu email de entrega - veja em baixo.
entrega baseada em git+origs¶
OS elementos da entrega consistem de:
- O ramo git.
- Quaisquer tarballs .orig que irão ser necessários, ou amostras de comandos git-deborig(1), git-archive(1) ou gbp-buildpackage(1) para os gerar.
- Uma amostra de comando dgit push-source, contendo qualquer opção --quilt=, --gbp ou --dpm do dgit necessária
- E mais é claro, toda a informação usual acerca do estado do pacote, quaisquer advertências ou áreas onde deseje que o patrocinador se foque na sua revisão, restrições sobre altura certa do envio, etc.
Se a entrega for feita por email, os elementos em cima devem estar numa única mensagem, assinada. Isto pode ser uma submissão RFS contra o pseudo-pacote de pedidos de patrocínio.
ramo git
Os nomes de ramo usados pelo patrocinado na sua máquina local, e no servidor, não interessam.
Em vez disso, o patrocinado deve incluir o id de cometido git do seu CABEÇALHO no seu email de entrega.
tarballs de origem
Se o patrocinado gerou estes tarballs com git-deborig(1), git-archive(1) ou gbp-buildpackage(1), eles podem simplesmente incluir uma amostra de invocação de git-deborig(1) ou git-archive(1) ou assegurar que um gbp.conf apropriado está presente no pacote fonte para gerar o tarball.
Caso contrário, a abordagem mais simples é cometer o os tarballs orig com pristine-tar(1), ex.
% pristine-tar commit ../foo_1.2.3.orig.tar.xz upstream/1.2.3
e certifique-se de empurrar o ramo pristine-tar. Se você está a usar git-buildpackage(1), apenas passe --git-pristine-tare --git-pristine-tar-commit.
Em alternativa, o patrocinado pode coloca-los num servidor web apropriado, ou anexa-los no e-mail, se forem pequenos.
O patrocinado deve citar sha256sums dos .origs no seu email de entrega, a menos que eles tenham fornecido comandos para os gerar.
opções de quilt
Forneça um comando amostra "dgit push-source" incluindo qualquer opção "--gbp" (aka "--quilt=gbp"), "--dpm" (aka "--quilt=dpm"), ou outra de "--quilt=" que precisem de usar. ex.
% dgit --gbp push-source
FLUXO DE TRABALHO DO PATROCINADOR¶
Esta parte é endereçada ao patrocinador:
Receber e validar o pedido de patrocínio¶
Você deve verificar a assinatura no email.
Use "git fetch" ou "git clone" para obter o ramo git preparado pelo seu patrocinado, e obter quaisquer .origs mencionados pelo patrocinado (para extrair .origs cometidos com pristine-tar, você pode usar origtargz(1), ou usar "gbp clone --pristine-tar".)
Verifique o ID de cometido git da dica de ramo do patrocinado, e os sha256sums dos .origs, contra o email de entrega.
Agora você pode verificar a dica do ramo, e fazer a sua revisão substantiva.
Lidar com ramos que querem --quilt=¶
Se o seu patrocinado mencionou uma opção "--quilt", e você não quer ter de agarrar no formato de árvore preferida dele, você pode converter a árvore dele para a vista standard do dgit:
% dgit -wgf --quilt=foo --dgit-view-save=unquilted quilt-fixup
% git checkout unquilted
Você deve perceber que para onde está a olhar é um descendente do ramo do patrocinado.
Algumas dicas que podem ajudar na revisão¶
"dgit fetch sid" irá obter-lhe um "refs/remotes/dgit/dgit/sid" atualizado que mostra o que já está no arquivo.
"dgit -wgf --damp-run push-source" irá verificar que o dgit pode compilar um pacote fonte apropriado.
Não é preciso correr o debdiff. O dgit não irá enviar nada que não desempacote para exatamente o cometido git que você está a empurrar, assim você pode confiar naquilo que vê em "git diff".
Efetuar o envio¶
Quando tiver completado a sua revisão da fonte, e usar "dgit -wgf [--quilt=...] sbuild -A -C" ou semelhante, para fazer a compilação, e depois "dgit -wgf [--quilt=...] push-source" ou "dgit -wgf [--quilt=...] push-built" para fazer o envio.
Verifique se o patrocinado fez uma etiqueta debian/versão. Se o fez, assegure que tem a sua etiqueta no repositório de onde está a empurrar, ou passe "--no-dep14tag". Isto evita nomeação idêntica, etiquetas não idênticas, o que pode criar confusão.
(E possível enviar a partir da vista dgit quilt-cache. Se desejar fazer isto, não passe as opções "--quilt" ou "--gbp" ou "--dpm" outra vez, e sim passe "--no-dep14tag", pois a etiqueta debian/versão deve ir no ramo do patrocinado.)
Se este foi o primeiro envio feito com dgit, você pode precisar de passar "--trust-changelog" ao dgit.
Em alternativa, se este foi o primeiro dgit push do pacote para esta suite, você pode passar "--deliberately-not-fast-forward" em vez de "--trust-changelog". Isto evita introduzir um novo cometido de origem na vista dgit do histórico git do patrocinado o qual é desnecessário e pode ser confuso.
PATROCINAR UM PATROCINADO QUE NÃO USA GIT¶
Esta parte é endereçada ao patrocinador:
Se o seu patrocinado não usar git, você ainda pode fazer a sua revisão com git, e usar o dgit para o envio.
O seu patrocinado irá fornecer-lhe um pacote fonte: isto é, um .dsc e os ficheiros que ele refere. Obtenha estes ficheiros, e verifique as assinaturas como apropriado. Depois:
% dgit clone PACOTE
% cd PACOTE
% dgit import-dsc /caminho/para/patrocinado's.dsc +patrocinado
% git checkout patrocinado
Ou para um pacote completamente novo:
% mkdir PACOTE
% cd PACOTE
% git init
% dgit -pPACOTE import-dsc /caminho/para/patrocinado's.dsc +patrocinado
Isto vai deixa-lo a olhar para o pacote do patrocinado, formatado como um ramo dgit.
Quando tiver terminado a sua revisão e os seus testes, você pode fazer o dgit push-source (ou dgit sbuild e dgit push-built) directamente a partir do ramo "patrocinado".
você vai precisar de passar "--trust-changelog" ao dgit push para cada envio com sucesso. Isto desactiva ua captura de segurança que iria normalmente detectar situações onde as alterações são perdidas por acidente. Quando o seu patrocinado lhe envia pacotes fonte - talvez múltiplos pacotes fonte com o mesmo número de versão - estas capturas de segurança são inevitavelmente ineficazes.
VEJA TAMBÉM¶
dgit(1), dgit(7), dgit-nmu-simple(7), dgit-maint-*(7)
| dgit+tag2upload team | Debian Project |