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, ou ter acesso a empurrar para o repositório do patrocinado de modo a usar git-debpush (Se o patrocinador não usar dgit nem git-debpush, 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 "git debpush" 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/tag2upload). 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=", "--gbp" ou "--dpm" para dgit, ou git-debpush, 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.

•   Seja uma amostra de comando dgit push-source, contendo qualquer opção --quilt=, --gbp ou --dpm do dgit necessária ou, se o seu patrocinador puder empurrar para o seu ramo git, uma amostra do comando git debpush.

•   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

    O patrocinado deve empurrar o seu CABEÇALHO como um ramo git para qualquer servidor git apropriado. Eles podem usar o seu próprio servidor git; salsa é outra possibilidade.

    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 existirem alguns .origs que não estão já no arquivo, e o patrocinador não vai usar git-debpush(1), o patrocinador vai precisar deles como parte do envio. (Quando se usa um formato de pacote fonte nativo, nenhuns origs são necessários.)

    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

    Alguns fluxos de trabalho envolvem ramos git que não são nativamente compatíveis com dgit. Normalmente o dgit irá converte-los como necessário, durante o push.

    Forneça um comando amostra "git debpush" ou "dgit push-source" incluindo qualquer opção "--gbp" (aka "--quilt=gbp"), "--dpm" (aka "--quilt=dpm"), ou outra de "--quilt=" que precisem de usar. ex.

        % git debpush --gbp

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 "git debpush [--quilt=...]" 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"; neste caso você não pode usar git debpush. Isto evita nomeação idêntica, etiquetas não idênticas, o que pode criar confusão.

Para envios de apenas-fonte, se deve-se usar dgit push-source ou git debpush depende de se você tem acesso a empurrar para o repositório do patrocinado e se sim ou não eles já têm feita uma etiqueta debian/versão. Você pode sempre usar dgit push-source; se você puder empurrar para o repositório e o patrocinado ainda não fez uma etiqueta debian/versão, então você pode usar git debpush em vez disso.

(E também 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 desativa uma captura de segurança que iria normalmente detetar 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)