Com três meses de atraso, mas está aqui em português a postagem do Bryant a cerca das diretrizes do projeto Asterisk. Pra quem não sabe o Russell Bryant é um dos homens chave conjuntamente com o engenheiro de projeto Kevin Fleming no projeto Asterisk dentro da Digium.
Apresentação de Atualização do Projeto Asterisk
Fonte Original do texto: http://blogs.asterisk.org/2009/11/10/asterisk-project-update-astricon-2009/, 10/11/2009
Autor: Russell Bryant
Nesses últimos três anos, Eu tive a oportunidade de fazer a apresentação de Atualização do Projeto Asterisk na AstriCon. Realmente é bom olhar para trás e ver o que realizamos no ano passado e compartilhar alguns dos destaques. Este ano, a exposição de Atualização do Projeto Asterisk foi uma apresentação conjunta entre Eu e o Kevin P. Fleming.
Para aqueles que não puderam comparecer à conferência, gostaria de partilhar o que Kevin e Eu tínhamos a dizer. Havia três temas principais que abordamos:
1. Crescimento da comunidade de Desenvolvedores do Asterisk;
2. Atualizações no processo de liberação do Asterisk;
3. Novas funcionalidades e melhorias na arquitetura.
1. Crescimento da Comunidade de Desenvolvedores
Tronco Asterisk é o ramo principal de desenvolvimento do Asterisk. Aqui é onde estamos preparando as novíssimas mudanças para a próxima grande liberação. Por exemplo, os novos recursos que entram no tronco Asterisk hoje estarão primeiro disponível no Asterisk 1.8 (espere aí um pouco, o que?! 1.8?! É, é isso mesmo. Eu voltarei a ele um pouco!) O tronco Asterisk está muito atarefado. Aqui estão alguns números importantes sobre a atividade no tronco durante o último ano:
* 2320 entregas;
* 825 arquivos alterados;
* 322.148 linhas de código adicionado;
* 53251 linhas de código removido.
Embora linhas de código não seja um número extremamente significativo por si só, ele pode ser usado junto com outros números para dar alguma luz. Por exemplo, se olharmos para o crescimento das linhas de código ao longo do tempo no tronco Asterisk, nós podemos perceber como a taxa de aumento no tamanho do código base tem crescido com o tempo de vida do projeto.
Gráfico 1 /trunk: Linhas de Código
Este crescimento não é resultado de uma única pessoa. No entanto, se alguém pode me ensinar como aumentar exponencialmente a minha produtividade ao longo do tempo, eu gostaria de falar com você! Um monte de pessoas contribui para o Asterisk. Entre os que escrevem código para o Asterisk, há um grupo seleto que tem acesso direto para fazer mudanças no código fonte (responsáveis). No início do projeto, havia efetivamente um único responsável, Mark Spencer. À medida que o projeto cresceu, foi preciso trabalhar duro com a escala em nossa comunidade de desenvolvimento de modo que pudéssemos processar mais código. O número de responsáveis hoje é superior a 50 (com o número de contribuidores muito maior do que isso). O gráfico seguinte mostra as linhas de código com o passar do tempo por responsável e ajuda a demonstrar como isso mudou ao longo da vida do projeto.
Gráfico 2 /trunk: Linhas de Código
Há inúmeras maneiras pelas quais nós podermos examinar o tamanho do grupo de pessoas que contribuem para o código do Asterisk. Uma maneira é olhar para quantidade de pessoas que já assinaram o contrato de licença de contribuidor ao longo do tempo. Anteriormente, isso era um formulário escrito gerenciado via fax. De algum tempo pra cá, a gestão desses acordos de licença é realizado eletronicamente. A partir desses dados, podemos ver que mais de 800 pessoas se inscreveram para contribuir com o Asterisk nos últimos dois anos.
Gráfico 3
2. Mudanças na Política de Liberação do Asterisk
Política de liberação é um acordo efetivo entre os desenvolvedores e as comunidades de usuários de como e quando as atualizações deverão ser entregues. Existem necessidades de satisfazer ambos os lados. A comunidade de desenvolvimento quer melhorar continuamente o projeto enquanto a comunidade de usuários precisa de software estável para que possam continuar operando de forma definida.
A história de lançamentos do Asterisk começou há 10 anos. Aqui estão algumas datas de liberações durante a primeira metade de vida do projeto:
• 0.1 – Dezembro de 1999
• 0.2 – Setembro de 2002
• 0.3 – Fevereiro de 2003
• 0.4 – Abril de 2003
• 0.5 – Setembro de 2003
• 0.7 – Janeiro de 2004
• 0.9 – Abril de 2004
Se você estiver lendo isso e já usa o Asterisk há bastante tempo se lembra dessas versões. Muito bom! Isso significa que você se envolveu com o projeto a mais cedo do que Eu. Eu me envolvi no projeto Asterisk em meados de 2004. Quando da primeira Astricon no outono de 2004, Mark Spencer decidiu liberar o Asterisk 1.0 e me pediu para mantê-lo.
Asterisk 1.0:
• Outono de 2004;
• Atualizações regulares 1.0.X com correções de bug somente;
• Finalmente entrou em manutenção de segurança somente, e hoje
não mais é mantido.
O desenvolvimento do Asterisk prosseguiu e continuou nos dois anos seguintes, foi então que nós lançamos o Asterisk 1.2 e o Asterisk 1.4. Fizemos algumas mudanças nos processos de desenvolvimento no que diz respeito a como e a quando portar correções de bugs e de como eles eram mesclados entre versões. No entanto, as políticas de liberação no que se refere ao que eram para atualizações e aproximadamente quantas vezes elas eram liberadas não sofreram alterações.
Asterisk 1.2:
• Liberado em Novembro de 2005;
• Ainda atualizado com correções de segurança somente.
Asterisk 1.4:
• Liberado em Dezembro de 2006;
• Ainda mantido completamente.
Neste ponto do projeto, nós identificamos alguns problemas e decidimos que gostaria de tentar algumas mudanças para melhorar nossas liberações. Nós decidimos modificar nossa abordagem para as liberações da série Asterisk 1.6.X. Nossos objetivos foram:
1. Liberar atualização de um recurso durante a série 1.6.X a cada 3 meses
ou em torno disso;
2. Entregar pequenos incrementos de recursos;
3. Manter a compatibilidade com versões anteriores;
4. Manter cada incremento pelo menos um ano com atualizações
regulares de correção de bug rotulado como 1.6.X.Y.
Os problemas identificados que queríamos atacar foram:
1. Asterisk 1.4 teve um início difícil. Tomou mais tempo do que deveria realmente
para estabilizar o código.
2. O caminho seguido para gerenciar nossas liberações deixou claro que
o tempo para disponibilizar novos recursos ao mercado foi maior do que
nós gostaríamos.
3. Algumas das nossas políticas no que diz respeito ao modo como as mudanças
foram implementadas mostraram que foi às vezes doloroso atualizações entre
versões principais.
Algumas dessas questões nós trabalhamos para resolver no planejamento das libertações da série 1.6.X. E outras, nós temos trabalhado na melhoria dos processos de desenvolvimento.
1. Qualidade da liberação
Nós melhoramos nossos processos de "release candidate". Agora fazemos um trabalho muito melhor para garantir essas liberações, incluindo atualizações de correção de bugs, se faz mais testes antes de serem liberadas.
Nós decidimos que precisaríamos encurtar nosso ciclo de liberação principal de sorte que, quando fosse hora de testar um novo conjunto de recursos, o objetivo fosse mais gerenciável.
Nós implementamos ferramentas e foram implementados processos para revisões mais rigorosas de código quando de alterações antes de serem consolidados.
Nós trabalhamos para educar a equipe de desenvolvimento sobre as melhores práticas e de como evitar problemas corriqueiros encontrados no Asterisk.
2. Tempo longo para disponibilizar ao mercado funcionalidades
Ao encurtar o ciclo de liberação, nós o fizemos de tal modo que os recursos estejam disponíveis o mais rápido possível do que era antes.
3. Atualizações Penosas
Nós abraçamos a retro-compatibilidade muito mais agressivamente do que no passado. Mesmo se houver uma nova maneira melhor de fazer algo, nós a manteremos no suporte se pudermos.
Nós documentamos cada mudança simples que atualizam os usuários entre versões devem estar cientes em UPGRADE.txt.
Na realidade, o Asterisk 1.6.X não funcionou exatamente como nós tínhamos imaginado. Ao passo que nós tínhamos planejado fazer atualizações a cada 3 meses, essas têm sido quase a cada 6 meses.
* Asterisk 1.6.0 - Outubro de 2008
* Asterisk 1.6.1 - Abril de 2009
* Asterisk 1.6.2 - Q4 de 2009
Outro ponto interessante que nós imaginávamos é que as mudanças entre as versões 1.6.X e 1.6.X 1 seria muito menor do que se mostrou na prática. O ciclo longo de liberação e o crescimento da comunidade de desenvolvimento demonstraram que as mudanças no Asterisk entre as atualizações geravam diferenças muito significativas.
Com toda essa história em mente, agora nós chegamos ao presente. Após revisar o modo como s nosso plano para Asterisk 1.6.X estava funcionando, nós decidimos propor algumas mudanças em nossa política de liberações. A primeira mudança foi à introdução do conceito de tipo de liberação na liberação de recursos. O objetivo disso foi passar aos usuários antecipadamente uma percepção mais clara de quanto tempo uma liberação importante do Asterisk vai durar. Existem dois tipos de liberação: a liberação Standard e a LTS.
1. Standard
o Mantida totalmente por 1 ano;
o Correções de segurança somente por mais 1 ano.
2. LTS
o Mantida totalmente por 4 anos;
o Correções de segurança somente por mais 1 ano.
A outra mudança nas políticas de liberação que nós gostaríamos de fazer era voltar ao nosso esquema original de versionamento. Nós começamos fornecendo atualizações de recursos rotuladas por 1.6.X porque as mudanças entre as liberações foi imaginado ser bem menor do que um salto entre 1.0 e 1.2, ou entre a 1.2 para a 1.4, etc. Assim, em vez de a próxima liberação ser chamada de 1.6.3, simplesmente vamos chamá-la de 1.8 para melhor refletir o que ela realmente é.
Aqui está a anatomia de um número de versão do Asterisk:
<Concept>.<Feature>.<Minor>[.Patch]
• Concept – Algo próximo de uma reescrita completa seria necessária
para alterar esse;
• Feature – Uma atualização para esse número indica uma mudança
para o conjunto de recursos;
• Minor – Esse número reflete uma atualização com correções de bugs somente;
• Patch – Mudanças Triviais (geralmente para uma liberação de segurança).
Aqui está uma tabela de liberações, seu tipo, e as datas associadas:
Tabela: Cronograma
Asterisk 1.8 está atualmente marcado para segundo trimestre de 2010, então ainda temos tempo para fazer alterações. Sinta-se livre para postar seus comentários aqui ou na lista de email Asterisk-dev se você tiver algum feedback!
3. Recursos do Asterisk
Um monte de código foi escrito esse ano. Algumas deles são muito visíveis aos usuários, enquanto outros são alterações de natureza arquitetônica e a fim de propiciar melhorias na implementação subjacente. Aqui está uma lista de algumas coisas legais que foram implementadas. Para obter uma lista completa dos novos recursos, veja o arquivo CHANGES no tronco do Asterisk.
1. Melhorias no Suporte a Fax (Todas as versões)
O suporte a negociação T.38 no Asterisk foi completamente reescrito para funcionar melhor;
Suporte completo para enviar/receber T.38 (suporte a gateway em andamento);
As opções de configuração adicionadas para melhorar a interoperabilidade com implementações em não-conformidade com T.38;
Muitas mudanças foram feitas em chan_dahdi e DAHDI para melhorar a estabilidade de FAX sobre a PSTN;
Centenas de horas foram postas em rigorosos testes de suporte a FAX no Asterisk.
2. Melhorias na Integração XMPP/Jabber (1.8+)
A função JABBER_RECEIVE() foi adicionada para lhe permitir receber mensagens XMPP no dialplan do Asterisk;
Há código em testes para usar XMPP como transporte para eventos distribuídos. Isso permitirá aos servidores Asterisk emparelhados via XMPP compartilhar o estado do dispositivo e informações MWI.
3. Suporte Party ID Connected/Redirecting (1.8+)
Controle total das atualizações ID da parte conectada. O display dos Telefones agora ficará correto após as transferências!;
Suporte ao redirecionando do party_ID significa que você pode ver quando a sua chamada foi encaminhada, ou quando você receber uma chamada que foi encaminhada;
Veja o vídeo da apresentação de Mark Michelson na AstriCon para mais informações sobre essa funcionalidade.
4. Serviços Suplementares de Estabelecimento de Chamada (Espera-se 1.8+)
“Camp on extensions”;
Suporte tanto para CCNR quanto para CCBS;
Suporte genérico no Asterisk, bem como suporte para fazer CCSS sobre SIP e sobre ISDN.
5. Integração de Calendário (1.8+)
Suporte para iCal, CalDAV, Exchange 2003;
Uso de informação de calendário como um provedor de estado de dispositivo;
Acessar estado de calendário no dialplan;
Originação de Chamadas baseados nas entradas de calendários;
Veja o vídeo da apresentação de Terry Wilson na AstriCon para mais informações a respeito dessa funcionalidade.
6. Framework para Eventos de Segurança (1.8+)
Essa infra-estrutura possibilita aos componentes do Asterisk reportar eventos que estão potencialmente relacionados a ataques no sistema;
Esse também inclui um módulo que escreverá eventos de segurança em um arquivo de log em um formato definido que pode ser usado por aplicações externas.
7. Melhorias no SIP TCP/TLS (1.6.X+)
Houve uma série de testes adicionais nessa funcionalidade;
As opções de configuração relacionadas foram melhoradas;
Há relatos de integração bem sucedida com o Microsoft OCS;
Há um trabalho contínuo em curso para tornar essa funcionalidade mais robusta em condições adversas de rede.
8. Atualização do Suporte PSTN
Houve muitas melhorias para suportar BRI via mISDN em todas as versões suportadas do Asterisk;
Suporte nativo BRI em LibPRI e em chan_dahdi foi adicionado ao Asterisk 1.6. Recursos foram trabalhados ativamente nesse código;
Suporte a sinalização MFC/R2 foi adicionado a chan_dahdi usando libopenr2 na versão 1.6.2 e posterior do Asterisk;
Suporte SS7 foi adicionado no Asterisk 1.6.0 e continua a amadurecer.
9. API do Núcleo de Bridging (1.6.2+)
Agora é muito mais fácil de escrever módulos para Asterisk que faz ponte com os canais;
Essa nova infra-estrutura de ponte pode estabelecer conferências entre canais sem precisar da biblioteca DAHDI instalada no sistema;
A nova aplicação de conferência (ConfBridge) foi fornecida, que permite fechar conferência usando essa nova infra-estrutura.
10. API do Núcleo de Temporização (1.6.1+)
Suporte para temporização no Asterisk foi abstraído em vez de depender diretamente de temporizadores DAHDI. Assim, a DAHDI não mais é necessária como fonte de temporização para o Asterisk.
11. Atualização da API do Núcleo de Canal (1.8+)
O gerenciamento da estrutura de dados usado muito amplamente no Asterisk, ast_channel, foi reescrita. Ela agora usa o modelo de objeto astobj2. O resultado é que menos travas atuando sobre esses dados são necessárias, e o código que faz interação nos canais ou buscas é mais eficiente.
12. Atualização da API do Núcleo do Escalonador (1.6.2+)
A API do escalonador é usada no Asterisk quando os componentes precisam escalonar alguma tarefa para acontecer no futuro. Por exemplo, isso é usado para retransmissões de mensagens e expiração dos temporizadores. É usado muito intensamente nos drivers de canal do Asterisk. A API do escalonador passou por duas rodadas de melhorias no desempenho do Asterisk 1.6 (1.6.1 e novamente no 1.6.2). Ao traçar o perfil, os resultados desse trabalho mostram que o escalonador chega perto do ápice da queda dos consumidores de CPU até sumir completamente do radar.
Enfim
Muita coisa aconteceu esse ano. Nossa comunidade de desenvolvimento continua crescendo em um ritmo saudável. Nossos processos de liberação estão mudando para melhor atender as necessidades dos usuários e desenvolvedores. Um monte de código bom está sendo realmente escrito.
Eu estou realmente ansioso com o próximo ano. Eu posso lhe prometer agora que ele será ainda mais emocionante do que esse.
Obrigado pela leitura.
