Existem muitas maneiras de se envolver no projeto Cem Cortes de Papel. É importante notar que você não precisa ser um programador para fazer uma contribuição significativa. Há muitos papéis que precisam ser preenchidos e escrever código é apenas uma pequena parte da correção de um recorte de papel.
Se você achar algo abaixo do que achar interessante, então junte-se à equipe do Paper Cut Ninja no Launchpad , inscreva-se no e-mail lista, apresentar-se e nos deixou saber o que você está interessado em fazer. Se você tiver alguma dúvida, ficaremos felizes em ajudá-lo.
Repórter - informa um problema
Reportar um problema é algo que todos podem fazer. Se houver algo em seu aplicativo favorito que esteja sob sua pele, informe-o (contanto que o aplicativo esteja incluído na área de trabalho). Se você realmente quiser se envolver, escolha um aplicativo na área de trabalho e sente-se nele por uma ou duas horas e procure por cortes de papel para relatar.
Analista - identifica o que está realmente errado
Confirme novos bugs - alguém precisa vir e ver se o backlog de bugs recém-reportados são cortes de papel realmente válidos. Sente-se com o aplicativo em questão e veja o que está acontecendo. Se o comunicado não fornecer informações suficientes, solicite as informações que faltam e marque o relatório como Incompleto .
Triagem erros confirmados - uma vez que um erro foi confirmou-se a existência, alguém tem que vir e descobrir o que realmente está errado. Por exemplo, é o problema com o aplicativo em si ou no kit de ferramentas gráfico com o qual ele é construído, como o Gtk. Isso geralmente envolve conversar com alguém nas equipes de Cortes em papel ou Desktop para obter orientação até que você tenha experiência suficiente para tomar a decisão.
Uma vez que o pacote afetado foi identificado, alguém pode descobrir o que realmente está errado. Se você não estiver familiarizado com a base de código do pacote, entre em contato com o desenvolvedor do pacote para obter orientação. Quando eles lhe disserem o que está acontecendo, você deve postar essa resposta como um comentário no relatório de erros.
Designer - decide como deve funcionar
Uma vez que um problema tenha sido identificado, uma correção precisa ser projetada. Isso não será necessário para cada corte de papel (alguns deles terão apenas um único caminho a ser corrigido). Nos outros casos, você deve se sentar com o aplicativo e pensar em como a correção deve funcionar. Uma vez que você tenha uma ideia, você deve obter um
Desenvolvedor - implementa correção no código
Se você sabe exatamente o que está acontecendo, pode ficar preso no código e começar a corrigir o corte de papel. A maneira como você faz isso depende do aplicativo em que está trabalhando e de onde esse aplicativo foi originalmente desenvolvido.
Se for um aplicativo Gnome, sua melhor opção seria retirar o código-fonte de git.gnome.org , trabalhe no seu patch e exporte a correção como um arquivo .patch que você pode anexar ao relatório de bug no Gnome Bugzilla.
Muitos outros projetos estão hospedados em repositórios Git e rastreiam seus problemas no Bugzilla. Se você ainda não tem certeza de onde ir, então entre no # ubuntu-desktop e pergunte. Alguém vai ficar mais do que feliz em apontar você na direção certa.
Se é um bug em um pacote do Ubuntu, como o Unity ou o Ubuntu Software Center, então existe um ótimo guia para corrigir bugs do Ubuntu no site do desenvolvedor do Ubuntu.
Testador - verifica se a correção funciona corretamente
Uma vez que um caminho tenha sido desenvolvido e enviado para aprovação, alguém precisa testá-lo. Isso poderia ser deixado para o desenvolvedor / mantenedor do pacote, mas eles têm muito trabalho a fazer, e tudo que pode ser feito para aliviar sua carga de trabalho em uma área significa que eles podem fazer mais em outros. .A esse respeito, se um patch ou branch estiver em um recorte de papel, seja no Launchpad ou no upstream, o download e a aplicação desse patch antes de dar a ele um test drive será uma grande ajuda.
Uma vez que você tenha feito isso, deixe uma mensagem no relatório do bug, tanto no upstream quanto no Ubuntu, detalhando seus resultados. No começo, o desenvolvedor ou mantenedor não será capaz de simplesmente acreditar que o patch está pronto, mas se você trabalhar muito em um pacote e o desenvolvedor conhecer você, sua palavra terá mais peso e você poderá até mesmo receber direitos de upload para o arquivo de origem dos pacotes.
Ligação - garante que a correção seja aceitável a montante
O Liason e o Testador podem, mas não precisam, se sobrepor. Depois de verificar que um patch resolveu o problema, ele precisa obter aprovação do desenvolvedor do pacote. Comentários do rastreador de bugs upstream nem sempre são postados no Launchpad, então alguém tem que agir como o corredor entre os dois, copiando e colando as perguntas e suas respostas entre os dois. Lembre-se, o Ubuntu não é a única distro em que esses aplicativos estão aparecendo, e não se pode esperar que os desenvolvedores acompanhem todos que usam o software deles, então você precisa garantir que todos os que estão trabalhando em um bug sejam mantidos em loop.
Packager - integra patch ou branch na distro
Depois que um patch é gravado, ele precisa ser integrado ao pacote de aplicativos existente. Isso envolverá o download e a instalação da versão do Ubuntu na qual você deseja que o patch seja lançado, faça o download do código-fonte do pacote, aplique o patch e empacote o resultado. O Guia de empacotamento do Ubuntu explica como fazer isso.
Dependendo da natureza do patch, você pode precisar fazer isso três vezes - a versão estável atual, o LTS atual e a versão de desenvolvimento atual são todos alvos viáveis para patches.
Atualizador - lida com o SRU para obter o patch na versão estável
Este é um que nem todo mundo será capaz de fazer, pois requer o upload direto para os arquivos do pacote Ubuntu. Uma vez que um patch tenha sido empacotado, ele pode precisar ser retornado para as necessidades da versão estável atual, do LTS atual ou de ambos. Se você quiser ganhar o upload certo, a melhor maneira de fazer isso é empacotando os patches e propondo-os para o SRU. Depois de propor um número que seja perfeito na primeira vez, você pode solicitar os direitos de upload.