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 01:17:35PM -0300, Bráulio Bhavamitra wrote:
> > Em 18/07/2013 11:27, "Antonio Terceiro" <terceiro at colivre.coop.br>
> escreveu:
> > >
> > > On Tue, Jul 16, 2013 at 07:52:57AM -0300, Bráulio Bhavamitra wrote:
> > > > Também sou mais do casamento noosfero-rails do que do atual
> > noosfero-debian.
> > > > Enquanto o noosfero estiver subjugado ao debian estaremos sempre
> > (muitos)
> > > > passos para trás do Rails...
> > >
> > > Até parece que é fácil portar um aplicação do tamanho do Noosfero para
> > > novas versões do Rails toda hora ... :-)
> > A questao é que nem se cogita upgrade dentro de um ciclo de dois anos do
> > debian. Quando se pode atualizar uma dependencia a hora que se quer (com
> os
> > testes passando), as atualizações sao mais frequentes e suaves.
>
> com novas versões vêm junto novos bugs também. Nem tudo são flores.
>
Veja ao final.

>
> > > Acho que já expliquei isso várias vezes, mas um dos principais motivos
> > > pra seguir o debian é que problemas de segurança no Rails são tratados
> > > de forma automática e consistente com o resto do Debian, e portanto
> fica
> > > mais fácil pra todo mundo estar atualizado.
> > >
> > > Se a gente usasse Rubygems, cada update de segurança exigiria que cada
> > > administrador de uma instalação Noosfero executasse passos de
> > > atualização manual, fora do workflow padrão que todo administrador de
> > > sistemas Debian já conhece de trás pra frente.
> > Errado, atualizando o Gemfile todos podem ter a ver nova versão das
> > dependencias com um comando: bundle update. Este comando pode ser
> incluido
> > em diversos scripts de instalação.
>
> ou seja passos de atualização manual, fora do workflow padrão que todo
> administrador de sistemas Debian já conhece.
>
> 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...

O BBB é feito em parte em rails e roda o bundle install/update na
instalação/atualização do pacote debian.
O flash e outros programas baixam dados em tempo de pós-instalação do
pacote.

>
> > > Além disso tem o fator do custo de migração. Cada nova versão do Rails
> é
> > > incompatível com a anterior, e no cado do Noosfero exige um esforço
> > > razoável pra adaptar a uma nova versão. Então na minha opinião seguir o
> > > Rails edge não é factível.
> > Isto tem a ver com a primeira resposta sobre atualizações.
> > >
> > > Eu não tenho dúvidas de que usar a versão mais nova de tudo é muito
> mais
> > > divertido. Mas no mundo real, com sistemas não-trivais e recursos
> > > limitados, estar na ponta o tempo todo não é fácil nem barato.
> > Sem dúvidas há custo. Mas não se pode se esquecer que os benefícios de
> usar
> > novas versões ou novas dependências são enormes. É uma balança a se
> > equilibrar. Agora estar preso ao debian faz com que esta balança mude
> > completamenre.
>
> mas descobrir qual lado da balança é mais pesado sem ser na base do achismo
> é bem difícil. assumir que "estar preso" ao debian necessariamente piora
> a situação me parece ser meio forçação de barra.
>
> De qualquer forma, acho que essa é uma questão importante para a
> comunidade.
>
> 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.

abraços,
bráulio

>
> --
> 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/44f9a717/attachment-0001.html>