Como participar de um projeto de software livre

Apresentação em tema: "Como participar de um projeto de software livre"— Transcrição da apresentação:

1 Como participar de um projeto de software livre
Antonio Terceiro - Quem aí é, ou quer ser, programador? - Vamos falar de todas, ou de boa parte das formas de participar em um projeto de SL - Todas elas são importantes - Mas estamos na trilha de desenvolvimento - Então vamos dar um pouco mais de atenção às formas que envolvem programação

2 Sobre mim - Participação em vários projetos, tanto liderando quando mandando patches esporádicos - Debian, Foswiki, Noosfero, analizo, awesome e outros - doutorado - Foco: falar sobre os meus erros - T++ - erro: querer começar o próprio projeto - pstreams p/ Debian: erro de empacotar um software que você não usa

3 Por quê participar?

4 Aprender

5 Trabalhar - Desempenhar um trabalho - Conseguir um trabalho
- Eu tenho a sorte de trabalhar diretamente com software livre → MOSTRAR FIGURAS! - Quem quiser saber um pouco mais pode vir amanhã na palestra “Contribuindo com o Noosfero”

6 Brincar

7 Todas as alternativas anteriores ;-)

8 A estrutura social de um projeto de software livre

9 Core and periphery in free software projects
Initiator Release Coordinator Passive users Active users Co-developers Core developers - Explicar as camadas - Você tem que “agradar” os caras ali no meio - mas como você descobre quem são eles/elas? The “onion” model. Adapted from [Crowston and Howison, 2005]

10 Chegue mais - participe dos espaços do projeto
- mailing list, IRC, forum, etc etc - a não ser que você queira fazer uma contribuição pontual!

11 O quê fazer num projeto?

12 Testar Certifique-se de testar a versão mais atual!

13 Relatar bugs - Versão mais atual também - Varia de projeto pra projeto
- O procedimento provavelmente está documentado - Senão, pergunte

14 Documentação - Doc para desenvolvedores - Doc para usuários
- Procure fazer de forma integrada com o projeto

15 Trabalhando com tradução
- Saiba inglês - Não faça tradução literal - Se aproxime dos times de tradução (GNOME, KDE, times genéricos)

16 Anatomia de um aqruivo .po
- Apesar de vários projetos usarem interfaces gráficas, acho válido mostrar como é um arquivo .po por dentro

17

18 Contexto

19 Texto original

20 Tradução

21 Enviando traduções - Única exceção nas contribuições de “código”: enviar arquivo completo, e NÃO UM PATCH. - Quase sempre o patch fica muito maior do que o original, a não ser quando for uma mudança de apenas 1 ou 2 strings. - Comprima o arquivo com gzip

22 Patches - Patches para consertar bugs
- Patches para implementar novas funcionalidades - Patches para melhorar a organização do código - Patches para documentação

23 Anatomia de um patch

24

25 Nome do arquivo

26 Contexto

27 Contexto (2)

28 Linhas removidas

29 Linhas adicionadas

30 Criando um patch

31 Com um SCM $ svn diff > meu.patch $ git format-patch # etc
- Aprenda a usar o SCM que o projeto que você quer contribuir usa!

32 Sem SCM – 1 arquivo $ cp src/a.ext src/a.ext.orig $ hack src/a.ext
$ diff -u src/a.ext.orig \ a/a.ext

33 Sem SCM – 2+ arquivos $ cp -r projeto-x.y.z \ projeto-x.y.z.orig
$ hack projeto-x.y.z/* $ diff -Nru projeto-x.y.z.orig \ projeto-x.y.z > meu.patch

34 Enviando um patch - Depende da cultura do projeto - Lista de discussão
- BTS - Comprimir ou não

35 Aplicando um patch $ patch -p0 < /tmp/meu.patch
$ git apply|am /tmp/meu.patch # etc

36 O que se espera de um bom patch?

37 Limpo - O patch faz apenas uma coisa
- Mal exemplo: consertar um bug e ao mesmo tempo arrumar a indentação - Patch series - Cuidado com editores que mexem na indentação automaticamente!

38 Revisado - LEIA o seu próprio patch antes de enviar

39 Testado - testes automatizados - teste manual

40 Consistente - Fazer uma mesma sempre do mesmo jeito
- Evita que o código fique bagunçado - Como coisas parecidas foram feitas no passado - não inclui arquivos gerados automaticamente MAKE CLEAN

41 Consensual - No caso de patches grandes e/ou que fazem mudanças significativas, normalmente precisa haver um consenso sobre a forma de fazer as coisas - Saudável discutir um patch antes de ter uma versão final dele.

42 Considerações finais

43 Tempo Economize o tempo das pessoas

44 Reputação - Sua contribuição com o projeto é o seu cartão de visita na comunidade - Você será reconhecido por boas contribuições. - Você será ESPECIALMENTE reconhecido por más contribuições

45 Happy hacking

46 Hackeia aí, omi! :)