Re: Mezuro deixará de ser um plugin do Noosfero

[Bráulio Bhavamitra]

2013/7/18 Antonio Terceiro <terceiro at colivre.coop.br>

> On Thu, Jul 18, 2013 at 03:36:11PM -0300, Bráulio Bhavamitra wrote:
> > > a propósito fazer atualizações em scripts de inicialização não é uma
> boa
> > > idéia porque a inicialização acontece muitas vezes sem supervisão de
> uma
> > > pessoa.
> > >
> > Disse (veja acima) scripts de instalação e atualização. Inicialização é
> > outro processo...
>
> Verdade, foi mal.
>
> > O BBB é feito em parte em rails e roda o bundle install/update na
> > instalação/atualização do pacote debian.
>
> o que faz com que quando há uma atualização do rails também seja
> necessária uma atualização do BBB ... não é uma boa solução.
>
> > O flash e outros programas baixam dados em tempo de pós-instalação do
> > pacote.
>
> flash faz isso porquê o flash em si não pode ser redistribuído, não há
> outra opção. Se pudesse ser redistribuído, viria dentro do pacote.
>
> baixar dados é uma coisa, baixar código de dependências que deveriam
> estar codificadas explicitamente no sistema de pacotes e reinventar a
> lógica de autenticação dos pacotes é outra coisa.
>
> > > Vamos discutir um meio termo: eu abro mão de seguir o Debian stable
> > > estritamente, mas não abro mão de um deploy são usando apt-get.
> > >
> > > O que vocês acham do seguinte:
> > >
> > > - depois do upgrade pra rails3/ruby1.9/debian7, se você (ou qualquer
> > >   outra pessoa) me apontar um branch do noosfero funcionando com rails
> 4
> > >   de uma forma satisfatória, eu me comprometo a fazer backport dos
> > >   pacotes necessários.
> > >
> > > - Com essa coisa funcionando a gente discute a possibilidade de passar
> a
> > >   manter esses backports e tirar a obrigação de depender da versão do
> > >   Rails do Debian stable oficial.
> > >
> > Não disse qual o lado da balança é mais pesado. Tanto ficar desatualizado
> > por dois anos (ou mais) quanto ficar super atualizado (com versões rc
> como
> > no caso do mezuro) potencialmente geram problemas.
> > A questão é que no caso do noosfero vejo que está realmente pendendo
> forte
> > para um lado da balança.
> >
> > Rails 4 não toparia não. Toda nova versão demora um tempo para se
> > consolidar. Iria no rails 3.2 mesmo.
> > Agora este tempo sem dúvida é, no caso do rails, menor que o ciclo de
> > desenvolvimento do debian.
>
> Não precisa ser *imediatamente* depois que estivermos no rails 3.2, pode
> ser quando você achar que é a hora. Bota o Noosfero pra funcionar que eu
> me comprometo de atualizar o empacotamento.
>
É um avanço poder contar com isso. A migração para o Rails 4/ruby-2.0 é
também menor do que em relação ao Rails 3.
Estou considerando que posso contar também com gems transformadas em
pacotes debian. :)
Ando pensando bastante no oauth para webservices.

>
> --
> Antonio Terceiro <terceiro at colivre.coop.br>
> Colivre - Cooperativa de Tecnologias Livres
> http://www.colivre.coop.br/
>
>
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
>


-- 
"Lute pela sua ideologia. Seja um com sua ideologia. Viva pela sua
ideologia. Morra por sua ideologia" P.R. Sarkar

EITA - Educação, Informação e Tecnologias para Autogestão
http://cirandas.net/brauliobo
http://eita.org.br
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130718/bc2a9455/attachment.html>