[okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas

• Mensagem anterior: [okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas
• Próxima mensagem: [okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas
• Mensagens classificadas por: [ date ] [ thread ] [ subject ] [ author ]

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>

• Mensagem anterior: [okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas
• Próxima mensagem: [okfn-br] GitLab vs GitHub ... dilema das opcoes ideologicas
• Mensagens classificadas por: [ date ] [ thread ] [ subject ] [ author ]