[okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas
Luiz Armesto
luiz.armesto em gmail.com
Quinta Abril 9 21:12:02 UTC 2015
JFYI gitlab.com usa a enterprise edition que é proprietária. Para usar a
versão 100% SL teria que ser a community edition. Aí teria que ou instalar
e manter em um servidor próprio ou achar alguém que a disponibilize e que
seja confiável.
On Apr 9, 2015 6:00 PM, "Andres MRM" <andres em inventati.org> wrote:
>
> Acho que não se trata de usar um "programa que o usuário está habituado e
> já possui acesso". Mas sim obrigar as pessoas a usar o GitHub. Pode ser que
> algumas já tenham contas lá e estejam acostumadas e felizes com ele, mas há
> pessoas que estão mais habituadas com GitLab, Gitorius, SourceForge,
> Bitbucket, Launchpad, etc, e há ainda pessoas (a maioria) que ainda não se
> cadastraram em nenhum desses serviços e podem vir a se cadastrar para poder
> participar da OK-Br.
> Se é para obrigar a usar algum serviço, que seja pelo menos um de código
> aberto.
>
> Acho que o que o Raneire quis dizer com a analogia dele é para não nos
> deixarmos levar apenas pelo efeito rede, mas também por aquilo que a OK-Br
> defende: conhecimento aberto.
> Ou seja, concordo com o Luiz, é um motivo ideológico. Mas acredito que
> seguir
> motivos ideológicos é o que caracteriza uma organização que defende uma
> ideologia, afinal, não somos uma organização sem fins lucrativos à toa.
>
> > Sobre o motivo ideológico, que é o caso, não poderíamos ficar restritos
> a um
> > único caso. Se decidimos que não queremos usar serviços que não são
> totalmente
> > livres então não é só em relação ao GitHub que temos que pensar. Os
> serviços de
> > Continuous Integration e Continuous Deployment que usamos em algum
> projeto são
> > 100% livres? Se não forem teremos que mudar também para manter a
> coerência.
> > Serviços de monitoramento? Armazenamento? Hospedagem? Algum deles usa
> código
> > proprietário? Então teremos que migrar. E assim por diante.
>
> Oba!!! =D
>
> Na minha opinião nós atualmente já não estamos sendo totalmente coerentes
> com
> o que defendemos. O que de certa forma é normal... tod em s têm suas
> contradições
> uma hora ou outra. É praticamente inevitável nos seres humanos e,
> consequentemente, nas organizações. Mas, acredito, as contradições precisam
> ser trabalhadas com o tempo. Adotando software livre nesse ponto seriamos,
> na
> minha opinião, um pouco menos contraditórios.
>
> Da última vez que tivemos uma discussão do tipo, sobre o GDocs, o fim foi
> meio
> "até curtimos software livre, mas não existe opção livre equivalente ao
> GDocs". Agora, "até curtimos software livre, mas no GitHub tem mais gente".
> Me pergunto que esforço a OK-Br está disposta a fazer para optar por
> software
> livre...
> Escolhê-lo quando é superior em todos os aspectos é fácil, mas é na
> situação
> contrária que a preferência se revela.
>
>
> Apesar de todo esse "blah, blah, blah", que o Tom chamaria de "masturbação
> mental", mas que acho importante para termos um momento de reflexão, no fim
> acho que isso vai ficar a cargo de cada projeto decidir, não? Como quase
> tudo
> na OK-Br (para o bem e para o mal).
> E, para eu mesmo não cair em mais uma contradição, o repositório do
> Cuidando
> 2.0 terá de ser no GitLab... Logo devo criar uma OK-Br em breve no GitLab
> para abrigar o projeto do Cuidando 2.0.
> Ah não ser que, dessa vez, decidam centralizar a decisão aqui e obrigar
> todos
> os projetos a usar o GitHub...
>
>
> Agora, mais especificamente sobre a integração "LabHub":
> Acho que o fato dela permitir o repositório aparecer na busca do GitHub já
> é
> algo bem bacana. Uma forma de permitir que o repositório seja mais
> facilmente
> encontrado, apresentar o GitLab para quem não conhece e advogar o uso de
> tecnologias abertas. Uma opção bem interessante.
> Mas, o que acontece se eu postar uma issue no GitHub do Noosfero? Ele vai
> parar no GitLab? E se eu fizer um pull request?
>
>
> Abraços!
>
>
> Quoting Luiz Armesto (2015-04-09 16:44:29)
> > Uma questão que quero levantar é: Há dois motivos para se decidir migrar
> de
> > serviço, um prático e outro ideológico.
> >
> > O prático é se as funcionalidades do serviço não atendem as espectativas
> ou se
> > o conteúdo que geramos fica preso ao serviço e não podemos levar junto se
> > quisermos sair, junto com a existencia de uma alternativa melhor. Neste
> caso
> > avalia-se serviço por serviço e escolhe-se o melhor.
> >
> > O ideológico é se apesar de na prática atender bem as necessidades existe
> > alguma característica, como no caso usar algum código proprietário, que é
> > contra os princípios do grupo. Nesse caso já se impõe um pré-requisito
> que
> > elimina automaticamentes vários serviços sem nem os avaliar.
> >
> > Em relação ao motivo prático não teriamos muito o que discutir nesse
> sentido.
> > Seria uma decisão bem mais objetiva e fácil de ser feita.
> >
> > Sobre o motivo ideológico, que é o caso, não poderíamos ficar restritos
> a um
> > único caso. Se decidimos que não queremos usar serviços que não são
> totalmente
> > livres então não é só em relação ao GitHub que temos que pensar. Os
> serviços de
> > Continuous Integration e Continuous Deployment que usamos em algum
> projeto são
> > 100% livres? Se não forem teremos que mudar também para manter a
> coerência.
> > Serviços de monitoramento? Armazenamento? Hospedagem? Algum deles usa
> código
> > proprietário? Então teremos que migrar. E assim por diante.
> >
> >
> > Pessoalmente tendo a ser mais pragmático. O que produzimos é 100% livre?
> > Estimulamos que terceiros adotem a postura de liberar conteúdo de forma
> livre?
> > Esse tipo de mudança vai afetar, e se for será positiva ou
> negativamente, os
> > objetivos e princípios da OK? É uma mudança prioritária e relevante para
> o
> > atual momento? É isso que importa.
> >
> > Mas no final vai depender da visão geral do grupo, e o que for decidido
> ok.
> >
> >
> > []'s
> >
> >
> > 2015-04-09 16:17 GMT-03:00 Yasodara Cordova <yasodara.cordova em gmail.com
> >:
> >
> > Outra observação crítica?
> >
> > Isso é realmente relevante agora? Nao seria melhor a gente cuidar dos
> > projetos e se isso decolar a gente pensa em mudar? Migrar do github
> nao eh
> > dificil.
> >
> >
> > Eu continuaria no github por hora, ja q ja estamos la.
> >
> > Frictionless, a la OK
> >
> >
> >
> >
> > ∞ w3c.br
> > ∞ ingraxa.eu
> >
> >
> > 2015-04-09 16:06 GMT-03:00 Diego Rabatone <diraol em diraol.eng.br>:
> >
> >
> > Pergunta/reflexão:
> >
> > Mudar do github para o gitlab vai impedir algum novo(a)
> desenvolvedor
> > (a) de colaborar com o projeto, efetivamente falando?
> > Este é o "ponto-crítico" no processo de conseguir mais pessoas
> > colaborando?
> >
> >
> > --------------------------------
> > Diego Rabatone Oliveira
> > diraol(arroba)diraol(ponto)eng(ponto)br
> > Identica: (@diraol) http://identi.ca/diraol
> > Twitter: @diraol
> >
> > Em 9 de abril de 2015 16:04, Thiago Gomes Veríssimo <
> > verissimotgv em gmail.com> escreveu:
> >
> > Olá lista,
> >
> > É a primeira vez que escrevo nesta lista, mas a acompanho
> como
> > "ouvinte" há um tempo.
> >
> > Eu já me coloquei essa questão (github X gitorious (agora
> gitlab))
> > muitas vezes. Acabei ficando com github (até o momento) pois
> lá
> > estão vários projetos não desenvolvidos por mim, mas que
> > eventualmente preciso enviar Pull Request. Assim por
> facilidade
> > estou no github.
> >
> > Acabei de fazer uma importação dos meus repositórios do
> github para
> > o gitlab (usando a própria ferramenta de importação do
> gitlab.com)
> > e as issues foram importadas. Uma possível migração no
> futuro para
> > o gitlab não demandaria muito esforço.
> >
> > Portanto, dando minha contribuição, se a ideia é abarcar mais
> > desenvolvedores, acho que ficar no github é a melhor opção no
> > momento, mas que pode ser reconsiderada num outro momento.
> >
> > --
> > Thiago Gomes Veríssimo
> >
> >
> >
> > Em 9 de abril de 2015 14:44, Luiz Armesto <
> luiz.armesto em gmail.com>
> > escreveu:
> >
> > Eu vejo mais como:
> >
> > A OKBr prefere
> >
> > (A) Que os dados orçamentários, que já são em CSV
> (livres),
> > sejam editados e visualizados em programas que o usuário
> está
> > habituado e já possui acesso.
> >
> > ou
> >
> > (B) que se troque o programa usado por uma alternativa
> livre,
> > fazendo com que todos que já editam esses dados ou
> quiserem
> > editar migrem.
> >
> >
> > Em ambas as alternativas os dados (dados orçamentários na
> > analogia, ou código fonte na discussão em si) já são
> abertos e
> > acessíveis.
> >
> > 2015-04-09 14:32 GMT-03:00 Raniere Silva <
> raniere em riseup.net>:
> >
> > > Ou seja, antes de pensar no "custo" de transferir
> ou
> > manter espelho, etc.
> > > do Github para outro lugar, há que se debater o
> dilema,
> > sobre o que a OKBr
> > > prefere,
> > >
> > > (A) aproveitar do "efeito de rede" já alcançado
> com o uso
> > do Github.
> > >
> > > ou
> > >
> > > (B) usar uma solução mais livre e ideologicamente
> > compatível com a OKBr.
> >
> > Deixa eu escrever a pergunta de "outra forma". A OKBr
> > prefere,
> >
> > (A) que dados orçamentários sejam disponibilizados
> em PDF
> > porque todo mundo sabe abrir um PDF.
> >
> > ou
> >
> > (B) que dados orçamentários sejam disponibilizados
> em CSV
> > (ou algo similar)
> > porque é um formato mais livre que possibilita
> mais
> > pessoas utilizar
> > esse dado.
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe:
> https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> >
> >
> >
> > --
> > Luiz Armesto
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe:
> https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> >
> >
> >
> > --
> > Thiago Gomes Verissimo
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> >
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> >
> >
> > _______________________________________________
> > okfn-br mailing list
> > okfn-br em lists.okfn.org
> > https://lists.okfn.org/mailman/listinfo/okfn-br
> > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
> >
> >
> >
> >
> >
> > --
> > Luiz Armesto
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20150409/ef187b06/attachment-0005.html>
Mais detalhes sobre a lista de discussão okfn-br