Re: Mezuro deixará de ser um plugin do Noosfero

[Bráulio Bhavamitra]

Em 19/07/2013 11:29, "Antonio Terceiro" <terceiro at colivre.coop.br> escreveu:
>
> On Thu, Jul 18, 2013 at 05:32:44PM -0300, Bráulio Bhavamitra wrote:
> > 2013/7/18 Antonio Terceiro <terceiro at colivre.coop.br>
> >
> > > On Thu, Jul 18, 2013 at 04:33:56PM -0300, Bráulio Bhavamitra wrote:
> > > > A esqueci do principal: há um comando no bundle que faz baixa as
gems
> > > > (incluindo o rails) dentro do código. Isto poderia ser feito antes
de
> > > gerar
> > > > o pacote debian.
> > > > Aí as dependências ficariam lá dentro, sem precisar baixar.
> > >
> > > ... o que faz com que updates nas dependências necessitem de um update
> > > no Noosfero - além de ser uma solução fuleira, é péssima prática em
> > > termos de segurança.
> > >
> >
> > > Dependências *precisam* poder ser atualizadas independente dos pacotes
> > > que dependem delas.
> > >
> > Fuleira? E o que é que tem no vendor/? Aliás, como não há referencia
> > nenhuma (seja via git ou gem), nem sabemos se houve problemas de
segurança.
>
> na minha opinião dependências no vendor/ são um problema. só porquê já tem
> algumas ali eu não acho que a gente deva colocar mais.
Elas nao ficariam lá (via git), apenas no pacote debian. Algo bem parecido
como foi com o solr.
>
> > Não é dificil atualizar a coisa quando se mantem a referência. Não
consigo
> > entender como pode ser tão ruim atualizar o pacote como um todo.
>
> a questão é que você só está vendo o lado do noosfero, e eu me preocupo
> com o ecossistema como um todo (sabe software livre, comunidade, essas
> coisas?).  Por exemplo quando eu faço um upload de segurança do Rails no
> Debian, tanto os usuários do Noosfero quanto usuários do Redmine são
> beneficiados.
Sim, isto mostra o casamento com o debian. As atualizações acontecem
naturalmente nos softwares ruby, e raríssimos sao os casos de aplicações
empacotadas debian. As comunidades ruby e rails estão longe, felizmente, de
apoiar uma única distribuição de um único SO.
>
> > No caso da falha de segurança do rails por exemplo, envolveu várias
> > atualizações do noosfero.
>
> Isso é outro assunto. Ocorreu um regressão, o que é uma exceção. O jeito
> certo de resolver isso é aumentar
>
> > Tem até um benefício: não precisa esperar o pacote com problema
atualizar,
> > o que pode demorar, pois nem sempre o mantenedor do pacote reage rápido
a
> > atualização do software.
>
> Na minha opinião o jeito certo de lidar com tempo de resposta alto do
> mantenedor é ajudá-lo, e *não* duplicar o trabalho dele internamente de
> forma que apenas os usuários do Noosfero de beneficiem, ao invés de
> beneficiar outras aplicações Rails.
Duplicar? A aplicação e o software não estão necessariamente atrelados ao
empacotamente. Mudar uma versão bugfix do pacote deve ser algo tão simples
quanto mudar a string 2.3.1 para 2.3.2, mas no debian se escolhe puxar os
patches em separado, o que realmente dá trabalho e cria versões do software
que só existem no debian.
>
> Essa discussão já está meio chata. Vamos concordar em discordar?
Sim. Resta torcer para que não deixem mais o noosfero, que as pessoas
aceitem o debian (mesmo que desgostem), que tenham paciência para aprender
algo novo e se adaptar e que as outras distribuições ofereçam alguma via
para que os usuários possam dar um jeito de instalar o noosfero de maneira
decente.
>
> --
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130719/d92edfaa/attachment.html>