Propósitos gerais. Evidenciação Empírica de um Processo para Contribuição em Projetos de Software Livre e Código Aberto. Definição de termos

Transcrição

1 Propósitos gerais Evidenciação Empírica de um Processo para Contribuição em Projetos de Software Livre e Código Aberto 1 1 Pós Graduação em Desenvolvimento de Software Universidade Federal de Lavras Encontro Técnico UFLA, 2008 Relatar, através de uma experiência, um processo e prática para a contribuição e melhoramento em SL/CA; Responder a pergunta principal do trabalho: Como colaborar efetivamente? Três projetos iniciais: Tikiwiki; Pfsense; Bacula; Apenas um escolhido para as experiências. Propósitos pessoais Definição de termos Aumentar o conhecimento em desenvolvimento de software; Colaborar com o desenvolvimento de um produto internacional; Implementar e resolver necessidades referentes as funcionalidades desejadas do software escolhido. Colaboração submissão de patchs que são definidos como mudanças, consertos ou melhoramentos contendo código fonte, documentação e processos; Projeto de SL/CA é uma organização virtual centrada em torno de um código fonte, com participação espontânea e variável de pessoas.

2 Ponto de observações Contribuir implementando um novo recurso de interfaceamento com SGBDs para o projeto escolhido; Referenciado no trabalho como patch libdbi; Atravez da experiência, vivenciamos e capturamos o processo utilizado durante o desenvolvimento do patch. Projeto de SL/CA escolhido Arquitetura geral do Bacula Projeto Bacula ( devido aos seguintes fatores: Tempo de atividade: 10 anos; Segmento da aplicação: meio corporativo e infraestrutura; Documentação: completa, nivelada e atualizada; Comunidade formada: usuário, desenvolvedores, empresas; Comprometimento.

3 Antes do patch libdbi Após o patch libdbi Somente três SGBDs suportados (Mysql, Postgresql, Sqlite); Modular mas dependente de implementação e API de cada SGBD; Três códigos distintos para manter. Vários tipos de SGBDs podem ser suportados; Modular sem dependência de implementação e API; Ponto único para manutenção e refactoting. Coleta de dados Taxionomia Buscas no hyperespaço, Internet: Websites; Listas de públicas; IRC chats; Artefatos no repositório de controle de versão; Documentação oficial do projeto. dos artefatos levantados em três grupos: Estrutural, como são desenvolvidos e organizados; Conteúdo, tipos de artefatos e conteúdos; Padrões de utilização, interação do usuário, desenvolvedores, atualização.

4 Taxionomia, site do projeto Taxionomia, projetos ativos Taxionomia, documentação Taxionomia, bugtrack

5 Taxionomia, guia de desenvolvimento Taxionomia, testes de regressão Taxionomia, análise dos testes Taxionomia, listas de discussão

6 Taxionomia, threads da lista Taxionomia, resumo Desenvolvimento Dia a dia de trabalho Utilizado uma exploração arquitetural do XP; Utilizado um modelo de programação exploratória; Testes de regressão para validações, sempre. Testar; Documentar; Feedback; Explorar; Analisar. Implementação

7 Dia a dia de trabalho Dia a dia de trabalho Testes Análise Dia a dia de trabalho Dia a dia de trabalho Discussões Submissão

8 Timeline Aprendizado: Técnico Timeline do desenvolvimento Data Submissões Data Integração Revision Exploração Arquitetural Desenvolvimento Aprofundamento em C/C++; Atenção a refactoring; Leitura de código fonte aprimorado; Entendimento do domínio do problema; Conhecimento em ferramentas de suporte (autoconf, automake, libtool, Makefiles). Orçadas Trabalhadas Exploração Arquitetural: 64h 59.89h Desenvolvimento: 168h 118h Página 1 Aprendizado: Engenharia de Software Aprendizado: Pessoal Na prática: Testes de regressão; Construir para verificação; Aderência a padrões; Modularidade; Escrita e leitura em inglês; Exposição de idéias em inglês; Diálogos constantes com pessoas de outros países.

9 Processo geral de contribuição 1 Alguém reporta um bug ou solicita uma nova funcionalidade; 2 O item se torna prioridade, muitos usuários comentam, endoçam; 3 Há uma discussão sobre o item mais aprofundada; 4 Alguém posta um patch, levantando uma incerteza sobre o mesmo; 5 Desenvolvedores testam e comentam o patch, caso ele resolva o problema; 6 O patch é revisto e formalmente testado; 7 Quando o patch é considerado aceito, ele é integrado e liberado na próxima versão. Conclusões do Trabalho Cada projeto de SL/CA estabelece seus próprios meios. Mas existem similaridades entre eles: Discussões em listas de públicas; Gerenciamento do código fonte e configuração; Desenvolvimento próximo do usuário final. Os portais dos projetos apresentam muito sobre suas características e formas de organização; Existe um caminho pré suposto no qual o usuário necessita seguir para colaborar efetivamente. Conclusões Pessoais Dentro das comunidades de SL/CA As contribuições são aceitas em projetos de SL/CA. Mas é necessário bom senso, diálogo intenso, carisma, entendimento do problema e pró-atividade; Trabalhe sempre para não quebrar o código já funcional e com certeza a sua contribuição será aceita. Suporte e manutenção do patch libdbi para o projeto Bacula; Contribuições no framework libdbi: casos de testes, novos drivers, profiling e benchmarks; Continuar pesquisas relacionado a busca de padrões em projetos de SL/CA.

10 Contato