Contribuindo com código

Requerimentos

• Conhecimento básico de Subversion (checkout, update, commit e capacidade de resolver conflitos);
• Conhecimentos básicos em desenvolvimento web com Python e Django;
• Desejável conhecimento de uso das ferramenta diff e patch.

Passo-a-passo

• Cadastre-se na lista de discussão da Django Brasil;
• Solicite, através da lista de discussão, a sua inclusão como membro do projeto. Assim, você poderá efetuar commits no repositório com a sua conta do Google;
• Assine o feed das atividades do projeto;
• Faça checkout do projeto e o configure (InstalacaoConfiguracao);
• Verifique as issues;
• Caso deseje contribuir com uma outra tarefa que não esteja nas issues, abra uma nova issue;
• Altere o status da issue para Started para informar aos outros colaboradores que está trabalhando nesta issue (volte pra Accepted caso tenha cancelado esta atividade);
• Altere os arquivos utilizando um editor de texto de sua preferência, efetuando commits que resolva uma issue de cada vez (informe qual issue o commit está relacionado, veja exemplos em Contribuindo);
• Feche a issue em questão alterando seu status para Fixed, não esqueça de informar em qual revisão ela foi finalizada (por exemplo: "Corrigido em r13" -- o Google cria ligações automaticamente utilizando este formato).

Lembre-se que o site é da comunidade e para a comunidade (principalmente). Discuta sempre antes de inserir um novo recurso no site, para ver se o mesmo é viável ou se é o momento certo para tal (nada o impede de realizar a tarefa em um branch ou localmente).

Obs.: é importante que uma nova issue que necessita de discussão tenha o status como New. Apenas marque para Accepted caso alcance um consenso (ou use o bom senso).

Equipe da Garantia da Qualidade (QA)

O trabalho de um membro da QA é basicamente:

• Verificar as issues finalizadas que precisam de aprovação;
• Conferir se a solução foi satisfatória ou não e avaliá-la pela revisão de código do Google Code, fazendo observações quando necessário;
• Mudar o status da issue para Verified se a solução poderá ser repassada ao branch online
• Fazer merge com o branch online com a solução, para ela ir ao ar.

Qualquer pessoa pode fazer o trabalho relacionado à equipe de QA desde que:

• Saiba o que está fazendo;
• Se sinta confiante;
• Não altere o status de uma issue para Verified se foi você quem a resolveu.

Relatando bugs e outros problemas, ou sugestões de melhorias

Utilize as issues. Confira antes se seu problema já não foi relatado.

Relatando problemas de segurança

Não utilize a ferramenta de relatório de bugs do Google Code para relatos de vulnerabilidades, pois tornando a vulnerabilidade pública, antes da correção ser aplicada, se torna um potencial risco para o nosso e outros sites que utilizam nosso código.

Para isso, contate diretamente por e-mail algum membro do projeto no Google Code (informação disponível na página inicial do projeto) ou contate algum autor do código de sua confiança. Uma lista de autores e seus respectivos e-mails, pode ser obtida no arquivo AUTHORS.

Patches

Criando um patch

Faça sua modificação no código do projeto e, à partir da raiz do projeto, execute:

svn diff > ~/fix_issue_X.diff

Aplicando um patch

À partir da raiz do projeto, execute:

patch -p0 -i ~/fix_issue_X.diff

Estilo de Codificação

Seguimos o estilo de codificação do Django Project. Você pode conferí-la em Coding style.

Quando algo for omitido, siga a PEP 8 (tradução).

Controle de versão (Subversion) e repositório do código

Algumas informações relacionadas ao Subversion e o repositório do código do projeto.

Modelos de mensagens de log

Corrigido #13 -- Formulário de contato não funciona.

Adequando quebra de linhas para 80 colunas.

Fazendo merge do trunk com o branch online

Baixe uma cópia local do trunk e do branch online.

Dentro da cópia de trabalho do branch online, digite:

svn merge -r125:127 /caminho/para/djangobrasil/trunk .

Onde 125:127 é o intervalo das revisões que queira fazer merge. Após isso, dê commit utilizando o seguinte modelo para a mensagem de log:

Merged from trunk up r127.

Documentação para Subversion

• Ultimo Log: Controle de Versão com Subversion (SVN)! Rápido e Prático!
• Livro on-line sobre Subversion: svnbook. Leitura obrigatória, de preferência os capítulos 1, 2, 3 e 4!

Configuração do Subversion

Na sessão [miscellany] de seu arquivo de configuração do Subversion, é recomendado que ignore ao menos os sufixos ##, *.pyc, *.pyo, .*~, *~ e .#* para evitar que os mesmos sejam introduzidos no repositório e que fique presentes em patchs gerados através do comando svn diff.

Veja um exemplo da configuração para essa sessão:

[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.pyc *.pyo *.project *.pydevproject

Outra configuração essencial é fazer com que o Subversion coloque automaticamente a propriedade svn:eol-style=native nos arquivos CSS, HTML e .py. Dessa maneira, usuários de diferentes sistemas operacionais não terão problemas com o caracter de quebra-de-linha e a mudança de de quebra-de-linha nos arquivos não será considerada como uma modificação na linha beneficiando assim os patchs gerados pelo comando svn diff.

Para tal configuração, é necessário ativar o auto-props na sessão [miscellany] e especificar os padrões na sessão [auto-props]. Veja um modelo que você pode adotar para as duas sessões:

[miscellany]
global-ignores = *.o *.lo *.la #*# .*.rej *.rej .*~ *~ .#* .DS_Store *.pyc *.pyo *.project *.pydevproject
enable-auto-props = yes

[auto-props]
*.py = svn:eol-style=native
*.html = svn:eol-style=native
*.css = svn:eol-style=native
*.xml = svn:eol-style=native
*.json = svn:eol-style=native
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.h = svn:eol-style=native
*.sh = svn:eol-style=native;svn:executable
*.txt = svn:eol-style=native
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
Makefile = svn:eol-style=native

Maiores informações sobre essas questões, no svnbook [1] [2] [3]. O arquivo de configuração do Subversion, em sistemas GNU/Linux, fica em ~/.subversion/config.