openSUSE:Colaboração Build Service
Índice
Introdução
O Build Service oferece várias maneiras de colaborar. A maneira mais fácil de aumentar a colaboração é permitir que um número maior de pessoas tenham permissão de escrita dentro de um pacote ou projeto. Este método permite que uma pequena equipe trabalhe em conjunto para colaborar de forma mais efetiva.
No entanto, esta metodologia não funciona na maioria das vezes:
- Colaboradores desconhecidos não possuem direito de escrita e, portanto, não podem aplicar alterações.
- A confiança em um projetos diminui com o aumento do número de pessoas com permissão de escrita.
- Mesmo as pessoas com permissão de escrita pode querer obter uma revisão de suas alterações, antes de se tornar ativa em um projeto.
- Mudanças frequentes levam o projeto à um estado que nunca terminará de construir. Mudanças em projetos base podem inviabilizar outros pacotes indefinidamente.
Portanto, o Build Service propõem outra maneira de contribuir. Você pode preparar as mudanças em um "branch" do projeto, para então submeter as alterações ao projeto principal.
Grandes projetos, como KDE, GNOME, Apache, and YaST, muitas vezes precisam de uma revisão extra, onde as submissões podem ser marcadas antes de serem integradas ao projeto principal. Este é o caso do openSUSE:Factory, por exemplo. Este projeto define um projeto de desenvolvimento para cada pacote. O Build Service ajuda os usuários a desenvolver e apresentar as contribuições de cada pacote ao projeto principal. Os responsáveis pelo desenvolvimento do projeto podem aplicar todas as contribuições no openSUSE:Factory. Este processo pode ser visualizado aqui.
Exemplo com o cliente de linha de comando
O nosso cliente via linha de comando (Command Line Client) é chamado "osc". Você pode encontrar a versão mais recente no repositório do projeto openSUSE:Tools, que pode ser baixado [aqui].
Aqui está outro exemplo mencionando o uso da interface web, com camadas, ligações, correções e agregações para um projeto (PackageKit) está aqui:
Como eu posso contribuir com minhas alterações em algum pacote ?
Digamos que você queira trabalhar no pacote openSUSE:Factory/initviocons e posteriormente, apresenta-lo ao projeto openSUSE:Factory.
A seguir mostraremos os procedimentos passo a passo.
Criar um Branch do Projeto
Em primeiro lugar, precisamos criar um branch do pacote (e de seu projeto), nós precisamos trabalhar em nosso projeto pessoal
# osc branch <projeto de origem> <pacote de origem> osc branch openSUSE:Factory initvicons
Este comando cria um novo projeto home:$yourself:branches que é um projeto branch. Este projeto branch tem a mesma estrutura do projeto original. O comando também cria o pacote dentro do branch como um link para o original.
Muitos pacotes possui um 'Devel Project'(Projeto de Desenvolvimento), e neste caso, o servidor usa o projeto de desenvolvimento como origem. É possível ver isso na saida do 'osc branch', como pode ser visto a seguir
# crie um branch de um pacote do Factory mas que será desenvolvido em um projeto diferente osc branch openSUSE:Factory glib2
criará home:$seu_usuario:branches:GNOME:UNSTABLE/glib2.
Isso garante que as suas mudanças seguirão o fluxo de mudanças já existente no diretório real do pacote.
Trabalhando com alterações
Agora que você criou um branch de um pacote, você poderá começar a trabalhar com ele. Siga os seguintes passos:
osc checkout home:$seu_usuário:branches:GNOME:Factory/glib2 cd home:$seu_usuario:branches:GNOME:Factory/glib2
Receba os pacotes no seu disco local. Os links de origem serão obtidos. Quando você cria um branch, um link para o pacote original é criado. Com este link, nosso branch estará sempre atualizado com as mudanças do pacote original. Para trabalhar no seu branch, você precisará dos pacotes originais, e não somente de um arquivo XML com os links. Por padrão, o checkout recebe dos links os arquivos do pacote original. É, portanto, obter os arquivos originais, mais quaisquer alterações existentes.
# agora trabalhe com o pacote vi ... osc status vi ... osc vc
Suas mudanças podem ser funcionalidades, correções, melhorias etc.
# construa o pacote completamente osc build
Construir o pacote localmente ajuda a reduzir o tempo gasto no seu desenvolvimento, já que não há a necessidade de esperar pelo término da construção sempre que efetuar uma correção
Depois de terminado, é hora de informar o serviço de compilação sobre as alterações:
# submeta as mudanças osc commit -m "changed this and that"
As suas mudanças vão para o servidor e a construção é agendada.
Após ter realizado o 'checkout' não será necessário criar um patch para o pacote. O Build Service toma cuidado para fazer tudo isso para você, comparando o seu branch com o original e criando diffs no Build Service.
Depois de um tempo você poderá ver como esta o trabalho:
# verificar se foi construido osc results
Talvez você queira ver o quão diferente é o seu pacote do original. Você poderá discutir sobre as suas alterações com qualquer um, por exemplo. Ou mesmo saber o que o outro desenvolvedor tem feito ao mesmo tempo. Para fazer isso, utilize:
# mostrar a diferença entre sua versão e outra no openSUSE:Factory osc rdiff home:seu_usuario:branches:openSUSE:Factory glib2
Depurando a construção
osc build deixa alguns arquivos no diretório de compilação que poderá ajuda-lo a diagnosticar o problema, a última saída do osc build é:
The buildroot was: /var/tmp/build-root
Se você for lá, poderá encontrar os seguintes arquivos:
| nome | conteúdo |
|---|---|
| .build.log | Registro da compilação e identificação do erro |
| .build.command | O comando usado na compilação atual |
| .build.packages | Os diretórios onde estão os arquivos |
Se a compilação falhar, você poderá tentar corrigir alguma coisa no diretório de compilação; isso é comum, mas não é o ideal. osc build frequentemente descarta tudo que tem no diretório ( rm -rf ) e reinicia a partir do zero. Esta estratégia não é viável para as mudanças incrementais: se a compilação demora muito tempo, o que é comum em grandes projetos. Para resolver este problema, veja no arquivo .build.command; ele normalmente contém a seguinte linha:
rpmbuild -ba package.spec
Este comando descarta tudo que você compilou, e é ele que nós não podemos utilizar. Com os comandos a seguir, poderemos prosseguir com a compilação
rpmbuild -bc --short-circuit package.spec #compile rpmbuild -bi --short-circuit package.spec #install
Estas opções são explicadas detalhadamente no Fedora RPM Guide.
Submeta as suas alterações para serem incorporadas
Quando você estiver satisfeito e acreditar que as suas alterações serão aceitas pelos mantenedores do projeto -- que é, se você estiver usando os exemplos deste artigo, os mantenedores do openSUSE:Factory -- você pode ir em frente e submeter as alterações.
osc submitrequest -m 'version update to 3.3'
Isto submete as alterações do pacote em seu local de trabalho para o projeto definido no link de origem.
Você pode também também fazer isso sem uma cópia do checkout usando o seguinte comando:
osc submitrequest home:$seu_usuário:branches:openSUSE:Factory initviocons openSUSE:Factory -m 'version update to 3.3'
Isso indica que você criou algo brilhante para apresentar ao projeto Factory. :-) Os mantenedores do projeto conferirão rapidamente. Se as mudanças forem aceitas, eles incorporarão ao projeto. Se isso precisar de mais trabalho, eles podem enviar comentários adicionais.
Como as minhas contribuições são manipuladas?
O mantenedor do projeto (por exemplo, openSUSE:Factory) é responsável por avaliar as contribuições (ou seja, para apresentar pedidos) como este:
% osc request list openSUSE:Factory 37 new home:poeml/initviocons -> openSUSE:Factory/initviocons 'version update to 3.3'
O mantenedor vai olhar as mudanças e comparar com a versão corrente, e aceita-la ou recusa-la, apresentando uma justificativa
% osc request show -d 37
Request to submit (id 37):
home:poeml/initviocons -> openSUSE:Factory/initviocons
Source revision MD5:
f839321325a0b5582def283c3520bf13
Message:
'version update to 3.3'
State: new 2008-03-20T19:57:02 poeml
changes files:
--------------
--- initviocons.changes
--- initviocons.changes
@@ -20 +20 @@
- which sends a characteristic primary da
+ which sends a characteristic primary DA
[...]
Depois disso, o mantenedor poderá aceitar a submissão:
osc request accept 37
Ou rejeita-la, apresentando uma justificativa:
osc request decline -m "changelog missing, but required by policy" 37
Exemplo com a interface web
Este artigo descreverá realizar como alterações através da interface web, você pode encontra-la aqui.
A interface web é muito boa para fazer pequenas coisas ou para obter uma visão geral, corrigir erros obvios ou descrição de pacotes. Para fazer alterações complexas, como corrigir erros de incorporações o cliente de linha de comando ainda é a melhor alternativa.
Como eu posso contribuir com minhas alterações em algum pacote ?
Vamos dizer que você precisa trabalhar no pacote openSUSE:Factory/initviocons, e depois submete-lo ao projeto openSUSE:Factory.
A seguir mostraremos os procedimentos passo a passo.
Criar um Branch do Pacote
Você precisa criar um branch, que basicamente é uma cópia do pacote original, porque você dificilmente terá permissão de escrita no objeto. Ou na maioria das vezes você prefere esperimentar primeiro, antes de disponibilizar o código para todos os usuários.
O Branch sempre se funde com o as mudanças do pacote original.
Para o projeto openSUSE:Factory vá até a lista de pacotes e procure o seu pacote.
Crie um Branch do Projeto
Em primeiro lugar, precisamos criar um branch do pacote (e de seu projeto), nós precisamos trabalhar em nosso projeto pessoal. Clique no menu "Actions" em seguinda em "Branch package".
O servidor criará um novo projeto em home:$seu_usuário:branches, o projeto branch. Este Branch possui a mesma estrutura do projeto original. O comando também cria o pacote dentro do branch como um link para o original.
Muitos pacotes possui um 'Devel Project'(Projeto de Desenvolvimento), e neste caso, o servidor usa o projeto de desenvolvimento como origem.
Trabalhando com alteraçṍes
Clique na aba "source files" e edite os fontes como quiser. Você deve esperar para ver se eles realmente estão compilando.
Você pode baixar o pacote e ver se as alterações realmente surtiram efeito.
Submeta as suas alterações para serem incorporadas
Quando você estiver satisfeito e acreditar que as suas alterações serão aceitas pelos mantenedores do projeto -- que é, se você estiver usando os exemplos deste artigo, os mantenedores do openSUSE:Factory -- você pode ir em frente e submeter as alterações.
Você pode enviar um pedido de submissão através do menu "Actions" ou produrar o link "show diff and submit these changes back" na página "Source Files".
Isso criará um pedido para mantenedor, que irá revisar a submissão e na maioria das vezes aceita-la. O seu pacote branch normalmente é removido após a incorporação ao original (exceto se você não permitir isso).
Tratamento especial para openSUSE:Factory
Cada pacote do openSUSE:Factory tem um "repositório de desenvolvimento". Estes repositório de desenvolvimento é utilizado para o desenvolvimento do próprio. (Você pode ver o desenvolvimento do pacote através do comando osc meta pkg openSUSE:Factory <pacote> | grep devel.) Se você executar osc branch openSUSE:Factory <pacote> não se assuste se você receber o pacote de outro lugar, se você quiser realizar alterações no openSUSE:Factory.
Para submeter uma alteração ao openSUSE Factory (Nota: a aceitação no projeto de desenvolvimento não significa que as alterações serão aceitas no projeto openSUSE:Factory automaticamente!), o mantenedor do Devel-Project deve fazer algo parecido com isso:
osc sr -m "- updated package, thanks to foo bar" <devel:project> <package> openSUSE:Factory
Então, nós temos dois ccenários aqui:
Branch, Fluxo de trabalho não oficial do projeto de desenvolvimento
- osc branch openSUSE:Factory <pacote>
- osc submitrequest (pedido de submissão de alteração)
- Aceitação da submissão pelo mantenedor do projeto de desenvolvimento osc sr accept <id>
- Mantenedor do projeto de desenvolvimento realiza outro pedido de submissão ao Factory
- O time do openSUSE:Factory aceita as mudanças
Fluxo de trabalho do mantenedor do projeto de desenvolvimento
- Mantenedor do projeto de desenvolvimento realiza outro pedido de submissão ao Factory
- O time do openSUSE:Factory aceita as mudanças
osc request list <devel:project>