Bom, lá vou eu fazer papel de advogado do diabo :-)<br><br><div class="gmail_quote">2012/6/3 breno <span dir="ltr"><<a href="mailto:breno@rio.pm.org" target="_blank">breno@rio.pm.org</a>></span></div><div class="gmail_quote">
[...]<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div>Acho que são problemas distintos. O Dist::Zilla foi criado para<br>
facilitar a criação de novas distribuições do zero, bem como a<br>
atualização dessas distribuições dentro do seu workflow (git, cpan,<br>
etc). Isso envolve a geração automática de um montão de coisas,<br>
inclusive de um Makefile.PL usando o builder que você escolher no seu<br>
~/.dzil/profile, o que é *muito* legal. Mas...<br></blockquote><div><br></div><div>Acho que a parte de criar distribuições do zero veio até depois, se não me falha a memória. Até porque já havia o Module::Starter. Eu pessoalmente acho que a melhor parte do Dist::Zilla não são essas, mas sim o fato de que você não tem de fazer "boilerplate maintenance" - coisas que estão aparecendo neste thread como escrever README, escrever Changelog, etc.. - toda vez que for soltar uma versão nova da sua distribuição.</div>
<div> </div><div>Antes de entrar nos detalhes abaixo, apenas um comentário: todo o comportamento do Dist::Zilla é configurável, então nenhum dos comportamentos descritos abaixo é obrigatório.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Minhas críticas quanto ao Dist::Zilla são muito simples:<br>
<br>
* Ele altera o seu código fonte, o que para mim dificulta a<br>
depuração de bugs ("erro na linha X" e lá vamos nós abrir a versão<br>
instalada pra achar o bug e o original para consertá-lo);<br></blockquote><div><br></div><div>"dzil build" gera um build da sua distro no subdiretorio ./Sua::Distrib-versao, onde você pode testar e debulhar seus arquivos.</div>
<div><br></div><div>nos meus módulos com Dist::Zilla, até onde lembro, não tem alteração de código-fonte Perl (e seus números de linha). A seção de POD no fim do arquivo é quase toda gerada, entretanto.</div><div><br></div>
<div>Minto, lembrei-me depois aqiu que eu uso o plugin PerlTidy, que executa o Perl::Tidy em todo o código. Apesar de isso potencialmente dificultar a colaboração de outros autores, eu acho que:</div><div><br></div><div>
1) Não custa nada, de vez em quando eu rodar um Perl::Tidy contra todo o meu código e dar um commit.</div>
<div>2) Se eu não fizer isso, o meu códigio vai sair bem formatado mesmo assim</div><div>3) A facilidade de leitura que o código bem formatado dá supera, na minha opinião, a dificuldade em encontrar uma linha de código</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * Com arquivos auto-gerados (incluindo testes e Makefile.PL), ele<br>
dificulta a colaboração de autores, que precisam instalar o Dzil e<br>
todos os plugins que você usa no seu projeto, do contrário não vão<br>
conseguir testar o patch que fizeram pois não dá pra montar a sua<br>
distribuição. Isso é facilmetne resolvido distribuindo o Makefile.PL<br>
auto-gerado junto com a sua distribuição, mas não vejo isso acontecer;<br></blockquote><div><br></div><div>"dzil authordeps | cpanm" instala tudo o que você precisa.</div><div><br></div><div>O que talvez ajudasse mais seria, au rodar o dzil e encontrar um Plugin ou Bundle que não está instalado no sistema, ao invés de dar erro, perguntar se quer instalar e já resolver tudo.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * A geração de stubs de documentação genérica aparentemente<br>
desestimula autores a escrever documentação decente; Há um módulo<br>
muito bacana chamado Pod::Plexus sendo desenvolvido pelo Rocco Caputo,<br>
mas ainda assim o problema persiste;<br></blockquote><div><br></div><div>O dzil não gera stubs de documentação de subs ou do código em si. O que ele gera de stubs são as seções de um POD de Perl, e algumas das seções "boilerplate" são preenchidas automagicamente, por exemplo:</div>
<div><br></div><div>NAME</div><div>VERSION</div><div>SUPPORT</div><div>AUTHOR</div><div>COPYRIGHT</div><div>DISCLAIMER OF WARRANTY</div><div><br></div><div>Ele não gera documentação de um método para o qual você não escreveu nada. Assim, a decência ou indecência da documentação depende, como sempre dependeu, somente do programador. Não vejo como isso esteja sendo estimulado ou desestimulado pelo Dist::Zilla.</div>
<div><br></div><div>Muito pelo contrário, com o uso de alguns plugins no Dist::Zilla, alguns testes são incluídos na distribuição para melhorar a qualidade da mesma, incluindo o testes de POD, que verificam se existe documentação gerada para cada subrotina, caso não haja, ele não permite o release da distrbuição.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * A quantidade boçal de plugins e configurações acaba estimulando a<br>
criação de bundles com plugins específicos de um autor. Se vc vai<br>
contribuir num projeto do Russo e vê um dist.ini contendo [@RUSSOZ], o<br>
que que isso faz? E se um dos plugins (que são específicos de cada<br>
autor) não funcionar no seu sistema? Temos aí um caso em que o próprio<br>
Dist::Zilla foi vítima de facilitadores para criação de configurações<br>
padrão;<br></blockquote><div><br></div><div>O bundle faz aquilo que o autor da distribuição considerou importante que fosse feito. Sou totalmente a favor de se ter alguns Bundles padronizados, mas não sei se isso altera a crítica. Os bundles são módulos por si só, então é possível abrir o mesmo e verificar o que eles fazem - não que você precise saber para usar.</div>
<div><br></div><div>se um dos plugins não funcionar no seu sistema, faz-se aquilo que sempre se faz quando um módulo não funciona no sistema: se você estiver de bom humor, investiga e manda um patch, se estiver mais ou menos voce apenas manda um bug report para o owner, e se estiver de mal humor, desencana de fazer o patch da distribuição-que-usa-o-dist-zilla, manda um report pro owner e fala pra ele corrigir, e se estiver muito puto da vida desencana de tudo isso e dane-se.</div>
<div><br></div><div>lembrando que o dist-zilla (e seus plugins em quantidades boçais) não são necessários para voce instalar o módulo, são usados APENAS para fazer o build do pacote de distribuição, isto é, só será realmente necessário pelo autor ou se você quiser fazer algum patch para o autor.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> * O dzil é muito voltado para subir módulos no CPAN e de fato é<br>
literalmente um comando para subir a nova versão. Mas isso acaba, do<br>
meu ponto de vista, facilitando a publicação equivocada de módulos, o<br>
que é particularmente preocupante se vc não quer essa distribuição no<br>
CPAN ou se ela é uma distribuição delicada/popular e vc precisa de uma<br>
certa garantia de qualidade ou pode quebrar sem querer o código dos<br>
outros. Tudo isso pode ser resolvido tomando cuidado e com boas<br>
práticas de desenvolvimento, mas exigem treinamento e disciplina.<br></blockquote><div><br></div><div>O dzil automatiza testes também, então toda a "garantia" de qualidade que você poderia ter sem ele, você pode ter com ele. Na verdade, uma vez que eu criei o meu bundle de plugins, que inclui varios testes para qualidade de código, eu tenho tantas garantias quanto eu sempre tive sem ele.</div>
<div><br></div><div>Seguindo a sua lógica, o script de cpan-upload é tão ruim quanto. But then again, eu acho que você está atirando no mensageiro. O CPAN é, por sua natureza, um repositório aberto, que aceita tantos e quantos módulos houverem para se publicar. Se eu, num ataque de loucura insana, decidir fazer um Denial-of-service no CPAN, eu poderia simplesmente gerar distribuições aleatórias e subí-los com o cpan-upload - não sei qual seria o limite até onde eu poderia fazer isso, mas em algum momento o indexador e/ou o ftp do CPAN iriam abrir o bico (imagine os mirrors puxando milhares de módulos a mais, da noite pro dia). O *** CPAN *** permite que módulos sejam subidos facilmente, não é o Dist::Zilla.</div>
<div><br></div><div>Não exatamente, mas seguindo emuma linha parecida com a que conversamos no outro dia, se houvesse um **outro** repositório, onde neguinho não pode sair colocando qualquer coisa, isso sim daria alguma garantia.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Para o problema em questão ("como gerar uma distribuição perl"), a<br>
criação do Makefile.PL usando a API do Module::Install me parece ser<br>
mais fácil e com uma curva de aprendizado muito menor que a<br>
criação/configuração do dzil.ini. Mas podemos concordar em discordar<br>
:P<br></blockquote><div><br></div><div>Podemos, e continuamos assim. :-)</div><div><br></div><div>Ao usar o Module::Install, você tem de gerar Makefile.PL e mais um monte de outras coisas, CADA VEZ que for soltar uma versão nova da distribuição. Com o Dist::Zilla, você automatiza essa parte - inclusive depois de dominar os Bundles, você automatiza a inclusão de incontáveis suítes de teste prontas nas suas distribuições.</div>
<div><br></div><div>my $two_cents;</div><div><br></div><div>[]s,</div><div>Russo</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dito isso, continuo afirmando que o Dist::Zilla é uma ótima solução<br>
para quem tem os problemas que ele se propõe a corrigir. Da minha<br>
parte, prefiro usar a combinação "module-starter" e "cpan-upload" =)<br>
<br>
<br>
[]s<br>
<span class="HOEnZb"><font color="#888888"><br>
-b<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
>><br>
>><br>
>> ABS()<br>
>><br>
>><br>
>><br>
>><br>
>> 2012/6/3 Alexei Znamensky <<a href="mailto:russoz@gmail.com">russoz@gmail.com</a>><br>
>>><br>
>>><br>
>>> 2012/6/3 breno <<a href="mailto:breno@rio.pm.org">breno@rio.pm.org</a>><br>
>>>><br>
>>>> Ao contrário do Stan, eu não recomendo o Dist::Zilla. Ou pelo menos<br>
>>>> não pra vc que está começando. Pode ser uma ótima ferramenta para<br>
>>>> alguns autores, mas se vc não entende a "mágica" que acontece por<br>
>>>> trás, pode se confundir e te deixar mais tempo configurando/depurando<br>
>>>> as ferramentas em vez de trabalhando no(s) seu(s) próprio(s)<br>
>>>> módulo(s).<br>
>>><br>
>>><br>
>>> Ao contrário do Garu, eu não des-recomendo o Dist::Zilla. Eu acho que é<br>
>>> uma ferramenta fantástica para esconder do desenvolvedor de distribuições os<br>
>>> detalhes de um build. Ao invés de tentarmos difundir ao máximo os detalhes,<br>
>>> para que todos - teoricamente - saibam o que fazer quando houver um<br>
>>> problema, acho que é muito mais saudável para todos que os detalhes sujos<br>
>>> fiquem o mais escondidos e automatizados o possível, simplificando a vida de<br>
>>> todos, mas principalmente de quem está começando.<br>
>>><br>
>>> Filosofando um pouco mais sobre o assunto, na rabeira de uma longa<br>
>>> conversa que eu e o Breno tivemos por telefone outro dia, eu fico pensando<br>
>>> que "More Than One Way To Do It" é muito bom como possibilidade, como para<br>
>>> ser usado em caso de exceção. Não deveria ser a regra. É muito bom que haja<br>
>>> 2,3,4, 5 formas diferentes de expressar orientação a objeto, contanto que<br>
>>> uma delas fosse uma "regra" e as outras fossem casos de exceção, aplicados<br>
>>> para necessidades específicas (e de preferência bem definidas, se não for<br>
>>> pedir muito). É muito bom estarmos todos produzindo e usando código livre, e<br>
>>> se eu quiser mudar algo eu posso simplesmente alterar e fazer o que eu<br>
>>> quiser, mas ó céus cada módulo que eu for fuçar é uma caixinha de surpresas.<br>
>>> Uns são feitos em Moose, outros em Mouse, tem um novo agora que eu nem<br>
>>> gravei o nome, tem os caras que fazem o bless na mão, e tem os caras que<br>
>>> fazem magia negra. Ou seja, se eu quiser ser um bom (=bondoso, cooperativo,<br>
>>> ativo, colaborativo, etc..) programador Perl, eu preciso ser fluente em uns<br>
>>> 5 ou 6 tipos diferentes de expressar a mesma idéia. Ao invés de poder contar<br>
>>> que algo vai ser de um jeito (ou de outro), e seguir adiante, e produzir 5<br>
>>> ou 6 idéias novas.<br>
>>><br>
>>> Fala-se, volta e meia, sobre produtividade em Perl e em Java, o<br>
>>> boilerplate code em Java é muito grande, etc.., mas toda vez que eles<br>
>>> (javeiros) precisam mexer em código dos outros, existe um padrão mínimo de<br>
>>> consistência esperado (claro, sempre há quem ferre com isso, em qualquer<br>
>>> idioma). Enquanto que, mexer em código dos outros, em Perl, como eu disse, é<br>
>>> um Kinder Ovo. You never know what you gonna get. Talvez esse seja o motivo,<br>
>>> na minha humirde opinião, pelo qual, eu percebo mais programadores Perl no<br>
>>> perfil "lobo solitário" do que em Java, por exemplo. É mais fácil às vezes<br>
>>> fazer um novo que entender o dialeto que o outro cara utiliza.<br>
>>><br>
>>> my $0.02;<br>
>>><br>
>>>><br>
>>>> Respondendo a sua pergunta, os arquivos Makefile.PL existem para a<br>
>>>> criação de "distribuições", que podem conter um ou mais módulos (além<br>
>>>> de scripts e outros arquivos). Quando vc faz uma distribuição, não tem<br>
>>>> problema se os módulos dentro dela dependerem de outro, contanto que<br>
>>>> esse outro também esteja dentro da distribuição (mas tenha cuidado com<br>
>>>> dependências circulares!).<br>
>>>><br>
>>>> Há 3 construtores populares:<br>
>>>><br>
>>>> * ExtUtils::MakeMaker, a.k.a. EUMM (que vc já citou)<br>
>>>> * Module::Build, a.k.a MB<br>
>>>> * Module::Install, a.k.a. MI<br>
>>>><br>
>>>> Embora o EUMM esteja no core, o M:I tem uma DSL bem fácil de usar e é<br>
>>>> utilizado em projetos de grande porte como Catalyst.<br>
>>>><br>
>>>> Digamos que vc tenha a seguinte estrutura de módulos:<br>
>>>><br>
>>>> lib/<br>
>>>> lib/MeuModulo.pm<br>
>>>> lib/MeuModulo<br>
>>>> lib/MeuModulo/Modulo1.pm<br>
>>>> lib/MeuModulo/Modulo2.pm<br>
>>>><br>
>>>> e queira criar uma distribuição chamada "Minha-Dist" contendo isso<br>
>>>> tudo. A sintaxe do seu Makefile.PL é muito simples:<br>
>>>><br>
>>>> ---------------8<---------------<br>
>>>> use inc::Module::Install;<br>
>>>><br>
>>>> name 'Minha-Dist';<br>
>>>> all_from 'lib/MeuModulo.pm';<br>
>>>><br>
>>>> WriteAll;<br>
>>>> --------------->8---------------<br>
>>>><br>
>>>> Pronto. Fácil, não? Ao rodar "perl Makefile.PL" ele vai gerar alguns<br>
>>>> arquivos pra vc. Depois digite "make manifest" e "make dist" e vc terá<br>
>>>> um Minha-Dist-0.01.tar.gz te esperando, pronto pra ser instalado =)<br>
>>>><br>
>>>> Algumas observações sobre o Makefile.PL acima:<br>
>>>><br>
>>>> * "name" indica o nome da distribuição. A convenção é que vc use o<br>
>>>> mesmo nome do seu módulo base, o principal da sua distribuição (e que<br>
>>>> provavelmente a maioria das pessoas vai usar primeiro). No seu caso,<br>
>>>> suponho que o melhor "name" para a sua distribuição seria "MeuModulo".<br>
>>>><br>
>>>> * "all_from" indica de onde o Makefile.PL deve extrair informações<br>
>>>> como versão, licença, autor, resumo, etc. Ele extrai essa informação<br>
>>>> de variáveis especiais de módulos (como "our $VERSION") e da<br>
>>>> documentação - então não esqueça de incluir os campos pertinentes na<br>
>>>> documentação (sempre uma boa prática!) ou terá que inclui-los<br>
>>>> explicitamente no Makefile.PL.<br>
>>>><br>
>>>> Digamos que os módulos da sua distribuição dependam dos seguintes<br>
>>>> módulos EXTERNOS: File::Spec e Carp. Digamos ainda que, embora não<br>
>>>> seja uma dependência direta, se o usuário tiver instalado o módulo<br>
>>>> Data::Printer o seu programa consegue fazer alguma outra coisa bacana,<br>
>>>> então embora não seja obrigatório vc gostaria de recomendar o<br>
>>>> Data::Printer. Adicionar essas dependências no Makefile.PL é simples,<br>
>>>> ele fica assim:<br>
>>>><br>
>>>> ---------------8<---------------<br>
>>>> use inc::Module::Install;<br>
>>>><br>
>>>> name 'Minha-Dist';<br>
>>>> all_from 'lib/MeuModulo.pm';<br>
>>>><br>
>>>> requires 'File::Spec' => 0;<br>
>>>> requires 'Carp' => 0;<br>
>>>><br>
>>>> recommends 'Data::Printer' => 0.3;<br>
>>>><br>
>>>> WriteAll;<br>
>>>> --------------->8---------------<br>
>>>><br>
>>>> O número depois da "=>" indica a versão mínima do módulo, usamos zero<br>
>>>> (0) para indicar que qualquer versão serve.<br>
>>>><br>
>>>> Com isso acho que vc já tem o suficiente. Não esqueça de criar um<br>
>>>> diretório "t" na raiz da sua distribuição para colocar os testes de<br>
>>>> seus módulos!! Mais sobre o M:I vc encontra na documentação<br>
>>>> (<a href="https://metacpan.org/module/Module::Install" target="_blank">https://metacpan.org/module/Module::Install</a>)<br>
>>>><br>
>>>> Obs: quando criamos um novo módulo, há alguns "boilerplates" que criam<br>
>>>> as estruturas e documentações básicas para vc. Eu particularmente<br>
>>>> gosto do Module::Starter, com o plugin Module::Starter::PBP (mas eu<br>
>>>> modifico os templates em ~/.module-starter/PBP para conter o esqueleto<br>
>>>> que uso). Assim, basta escrever na linha de comando:<br>
>>>><br>
>>>> $ module-starter --module="Meu::Novo::Modulo"<br>
>>>><br>
>>>> e ele cria tudo para mim.<br>
>>>><br>
>>>> Quando vc estiver acostumado a criar suas distribuições e entender o<br>
>>>> processo, vai começar a ficar preguiçoso. Aí sim, dê uma olhada no<br>
>>>> Dist::Zilla e veja se ele é para vc =)<br>
>>>><br>
>>>><br>
>>>> []s<br>
>>>><br>
>>>> -b<br>
>>>><br>
>>>> 2012/6/2 Stanislaw Pusep <<a href="mailto:creaktive@gmail.com">creaktive@gmail.com</a>>:<br>
>>>> > A resposta é: Dist::Zilla.<br>
>>>> > Pode parecer chatinho de aprender, mas, uma vez sabendo o básico,<br>
>>>> > criar<br>
>>>> > módulo com Makefile.PL completo e suíte de testes é dois palitos!<br>
>>>> > Recomendo:<br>
>>>> ><br>
>>>> > <a href="http://sao-paulo.pm.org/artigo/2011/OhnoItsDistZilla" target="_blank">http://sao-paulo.pm.org/artigo/2011/OhnoItsDistZilla</a><br>
>>>> > <a href="http://sao-paulo.pm.org/equinocio/2011/set/2" target="_blank">http://sao-paulo.pm.org/equinocio/2011/set/2</a><br>
>>>> ><br>
>>>> > ABS()<br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > 2012/6/2 Aureliano Guedes <<a href="mailto:guedes_1000@hotmail.com">guedes_1000@hotmail.com</a>><br>
>>>> >><br>
>>>> >> Ola,<br>
>>>> >> Monges.<br>
>>>> >><br>
>>>> >> Eu estou tentando gerar um MakeFile.PL mas estou com um problema.<br>
>>>> >> Eu andei lendo, inclusive alguns materiais do Hernan Lopes mas ficou<br>
>>>> >> uma<br>
>>>> >> pergunta.<br>
>>>> >><br>
>>>> >> Quando eu tenho varios modulos que na verdade sao dependencia de<br>
>>>> >> outro<br>
>>>> >> modulo.<br>
>>>> >> exemplo:<br>
>>>> >> MeuModulo.pm,<br>
>>>> >> MeuModulo/Modulo1.pm,<br>
>>>> >> MeuModulo/Modulo2.pm.<br>
>>>> >><br>
>>>> >> Como faco?<br>
>>>> >><br>
>>>> >> Nao achei nenhuma opcao no ExtUtils::MakeMaker.<br>
>>>> >><br>
>>>> >> Desde ja, obrigado.<br>
>>>> >> Att,<br>
>>>> >><br>
>>>> >> Aureliano Guedes<br>
>>>> >><br>
>>>> >> PS: Desculpem a falta de acentos, o teclado esta desconfigurado.<br>
>>>> >><br>
>>>> >> _______________________________________________<br>
>>>> >> Rio-pm mailing list<br>
>>>> >> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>>> >> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>>> ><br>
>>>> ><br>
>>>> ><br>
>>>> > _______________________________________________<br>
>>>> > Rio-pm mailing list<br>
>>>> > <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>>> > <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>>> _______________________________________________<br>
>>>> Rio-pm mailing list<br>
>>>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | <a href="http://russoz.org" target="_blank">http://russoz.org</a><br>
>>> GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C<br>
>>> <a href="http://www.flickr.com/photos/alexeiz" target="_blank">http://www.flickr.com/photos/alexeiz</a> | <a href="http://github.com/russoz" target="_blank">http://github.com/russoz</a><br>
>>> "I don't know... fly casual!" -- Han Solo<br>
>>><br>
>>> _______________________________________________<br>
>>> Rio-pm mailing list<br>
>>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> Rio-pm mailing list<br>
>> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
>> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Alexei "RUSSOZ" Znamensky | russoz EM gmail com | <a href="http://russoz.org" target="_blank">http://russoz.org</a><br>
> GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C<br>
> <a href="http://www.flickr.com/photos/alexeiz" target="_blank">http://www.flickr.com/photos/alexeiz</a> | <a href="http://github.com/russoz" target="_blank">http://github.com/russoz</a><br>
> "I don't know... fly casual!" -- Han Solo<br>
><br>
> _______________________________________________<br>
> Rio-pm mailing list<br>
> <a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
> <a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
_______________________________________________<br>
Rio-pm mailing list<br>
<a href="mailto:Rio-pm@pm.org">Rio-pm@pm.org</a><br>
<a href="http://mail.pm.org/mailman/listinfo/rio-pm" target="_blank">http://mail.pm.org/mailman/listinfo/rio-pm</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Alexei "RUSSOZ" Znamensky | russoz EM gmail com | <a href="http://russoz.org" target="_blank">http://russoz.org</a><br>GPG fingerprint = 42AB E78C B83A AE31 7D27 1CF3 C66F B5C7 71CA 9F3C<br>
<a href="http://www.flickr.com/photos/alexeiz" target="_blank">http://www.flickr.com/photos/alexeiz</a> | <a href="http://github.com/russoz" target="_blank">http://github.com/russoz</a><br>"I don't know... fly casual!" -- Han Solo<br>