Queremos Saber - Pré-lançamento

[Pedro Markun]

Caros,

depois de um intensivo de 3 dias... acho que o www.queremossaber.org.br já esta bom prum pré-lançamento :)

Tem muita coisa que a gente só vai conseguir entender como e se funciona... quando botar pra rolar.

Então tá ai, testem o sistema :)

Por enquanto temos alguns orgãos do executivo federal (scrapeados pela Dani) e quase todas as prefeituras (no arquivo do Fabiano Angélico) ainda falta muita coisa... e se alguém tiver afim de ajudar a compilar novos contatos o formato padrão de importar os dados é esse aqui ó:

https://docs.google.com/spreadsheet/ccc?key=0AgIAm6PdQexvdDJKdzlNdXEtdjBETi1SLVhoUy1QM3c&hl=en_US

Pra quem achar problemas e inconsistências na tradução:

https://www.transifex.net/projects/p/alaveteli/

E quem achar bugs no código e quiser ajudar:

https://github.com/pmarkun/alaveteli

e

https://github.com/pmarkun/queremossaber-theme

abs,

Pedro Markun

[Fabiano Angélico]

Sensacional!! Belo trabalho, parabéns. Eu só trocaria "faça um novo
pedido de acesso a informação" por "faça um novo pedido de informação"

On Nov 2, 1:23 pm, Pedro Markun <pe...@esfera.mobi> wrote:
> Caros,
>
> depois de um intensivo de 3 dias... acho que owww.queremossaber.org.brjá
> esta bom prum pré-lançamento :)
>
> Tem muita coisa que a gente só vai conseguir entender como e se funciona...
> quando botar pra rolar.
>
> Então tá ai, testem o sistema :)
>
> Por enquanto temos alguns orgãos do executivo federal (scrapeados pela
> Dani) e quase todas as prefeituras (no arquivo do Fabiano Angélico) ainda
> falta muita coisa... e se alguém tiver afim de ajudar a compilar novos
> contatos o formato padrão de importar os dados é esse aqui ó:
>

> https://docs.google.com/spreadsheet/ccc?key=0AgIAm6PdQexvdDJKdzlNdXEt...

[udntkwi]

Na página principal na parte direita abaixo de: Que informações foram publicadas, por exemplo: Prefeitura de Araras - SP respondeu um pedido sobre Informações referentes aos projetos sociais Há aproximadamente 1 hora.

Ao invés de respondeu não seria responde? já que o pedido ainda não foi respondido.

Erro de tradução?

>
> abs,
> Pedro Markun

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para thac...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para thackday+u...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/thackday?hl=pt-BR.

[Everton Zanella Alvarenga]

Parabéns ao pessoal que trabalho forte para o site sair em tão pouco tempo!

Pessoal que está achando erro nas traduções, vocês podem ajudar aqui:

https://www.transifex.net/projects/p/alaveteli/resource/apppot/

*Qualquer um* pode contribuir (é um pouco chatinho ter que cadastrar).
Ainda me parece que há muita coisa para melhorar, então ajudaria
usarmos os sistemas colaborativos que temos em mãos.

Se não tiverem paciência para entrar e navegar pelo site de tradução,
sugiro colocar os erros que acharem aqui

http://ietherpad.com/thacker-alaveteli

Abraços!

Tom

[Lilian Starobinas]

Show, gente, parabéns pela rapidez!
bjs
Lilian

Em 2 de novembro de 2011 15:25, Everton Zanella Alvarenga
<evert...@gmail.com> escreveu:

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.
> Para postar neste grupo, envie um e-mail para thac...@googlegroups.com.
> Para cancelar a inscrição nesse grupo, envie um e-mail para thackday+u...@googlegroups.com.
> Para obter mais opções, visite esse grupo em http://groups.google.com/group/thackday?hl=pt-BR.
>
>

--
Lilian Starobinas
http://discursocitado.blogspot.com
@liliansta

[Bruno Antunes]

Gostei muito da ideia, está bom e vai ficar ainda melhor.
Pra tentar ajudar criei um aplicativo, que funciona como um atalho no
Google Chrome, não é lá muita coisa mas está aqui: http://migre.me/632yi
Video ensinando como instalar: http://www.youtube.com/watch?v=J25mcuhrOZI
Eu fiz o arquivo CRX, quando vou instalar em máquinas diferentes da
minha apresenta problema.

[Deda]

Ficou excelente mesmo. Quero trabalhar isso na coluna - O Coro da
Multidão. Quem me dá entrevista?

On 2 nov, 13:21, udntkwi <udnt...@gmail.com> wrote:
> Na página principal na parte direita abaixo de: Que informações foram
> publicadas, por exemplo: Prefeitura de Araras -

> SP<http://queremossaber.org.br/pt/body/prefeitura_de_araras_sp>respondeu

> um pedido sobre Informações
> referentes aos projetos

> sociais<http://queremossaber.org.br/pt/request/informaes_referentes_aos_projeto>Há

> aproximadamente 1 hora.
>
> Ao invés de respondeu não seria responde? já que o pedido ainda não foi
> respondido.
>
> Erro de tradução?
>
> Em 2 de novembro de 2011 14:56, Fabiano Angélico

> <fabianoangel...@gmail.com>escreveu:

[Pedro Markun]

Deda,

topa uma entrevista pela lista? :P

abs,
Pedro Ma

2011/11/3 Deda <rhodri...@gmail.com>

[Patrícia Cornils]

E se a gente fizer relatos de bugs aqui na lista, também? Fica registrado, a gente vai arrumando.

Patrícia Cornils
11 3124-7444 ou 8372-7473

[Pedro Markun]

Pati,

acho que aqui na lista é meio ruim, pq fica registrado mas fica desordenado.

Acho que podemos reunir aqui por enquanto:
https://github.com/pmarkun/alaveteli/issues

Tem que ter conta no git. Mas acho que é uma experiência legal o pessoal non-tech da lista começar a brincar com git ;)

Como disse o Friederich, da OKFN, é um o Orkut dos desenvolvedores.

abs,
Pedro Markun

2011/11/3 Patrícia Cornils <patrici...@gmail.com>

[Everton Zanella Alvarenga]

Concordo com o Pedro.

Estou trabalhando em projeto em que algumas pessoas de humanas estão lidando bem com Trac e Redmine, por exemplo. Temos que perder o medo dos orkuts dos desenvolvedores. : )

Se encontrarem dúvidas ao usar esses sistema, aí sim sugiror vir aqui na lista.

[Everton Zanella Alvarenga]

Pedro,

um dúvida. Vi agora que fez um fork do código original.

Será que o ideal não seria criarmos um branch (teríamos que falar com o Seb) e eventualmente, se formos aprimorar o código do Alaveteli, darmos um merge com o master?

Minha preocupação é o nosso fork divergir do master original...

[Pedro Markun]

Tom,

pode ser também. Mas é isso, temos que falar com o Seb e o Seb esta meio fora de área.

O fork tem pouca coisa divergente, na verdade. Estou concentrando a maioria das mudanças no tema. As poucas coisas que tem são relativas a tradução (ou a falta delas).

abs,
Pedro Markun

2011/11/3 Everton Zanella Alvarenga <evert...@gmail.com>

[Daniela B. Silva]

Super bacana, Bruno!!! :D

2011/11/2 Bruno Antunes <antun...@gmail.com>

[Águida Aparecida Gava]

Pessoal! bom dia!

alguém tem uma luz de quando terminará a análise dos projetos inscritos no festival?
receberemos emails?

A complicação está em nos organizarmos( junto aos nossos chefes de trabalho) e termos a permissão de ir meio em cima da hora. Fora a ansiedade natural da espera.

Abs.

[Pedro Markun]

Caros,

alguém ai manja de postfix? O sistema do Alaveteli usa ele para gerenciar todos os emails e isso esta ok. Mas precisavamos criar algumas outras contas e configurar o servidor de email - para o contato por exemplo.

Eu posso fuçar por aqui, mas se alguém tiver experiência e segurança pra fazer isso sem quebrar a instalação... é sempre uma mão na roda (e se quiser documentar depois como fazer, seria lindo).

Por enquanto estou direcionando os contatos para o meu email pessoal. Mas esse modelo não é muito escalavel ;)

(E nessa onda, precisamos de voluntários que topem fazer manutenção dos conteúdos e dos pedidos. Vou marcar uma oficina na casa essa semana pra ensinar quem quiser a mexer no sistema, k? :)

abs,

Pedro Markun

2011/11/3 Daniela B. Silva <daniel...@gmail.com>

[Geração de Calebe]

Tenho tido pouco tempo para acessar esse importante fórum de debates, estamos envolvidos na CONSOCIAL, mais especificamente no projeto CONLIRO (Conferências Livres de Roraima),em trabalho conjunto, movimentos sociais, sociedade civil organizada, conselhos e poder público, estão realizando dezenas de conferências livres em Roraima  a capital Boa Vista, recebe a maior parte das conferências, posto que há 50 bairros e 60 escolas públicas estaduais, onde ser realizam as atividades. Assim, a Central Única dos Trabalhadores (CUT), Central dos trabalhadores e Trabalhadoras do Brasil (CTB), Secretaria de Estado de Educação, Cultura e Desporto (SECD), Confederação Nacional das Associações de Moradores (Conam), Universidade Federal de Roraima (UFRR), Universidade do Estado de Roraima (UERR), Controladoria Regional da União no Estado de Roraima (CGU-R/RR), Secretaria de Fazenda do Estado de Roraima (SEFAZ), Receita Federal do Brasil (RFB), Rede de Educação Cidadã(RECID), Movimento Nós Existimos, Movimento Mulheres Camponesas (MMC), Equipe Itinerante da Diocese de Roraima, Sindicato dos Trabalhadores Municipais (SITRAM), Grupo de Educação Fiscal (GEFE) de Roraima, entre outros; iniciaram a execução do projeto, em Boa Vista, no dia 24/10/2011, na Escola Estadual Hélio Campos, estendendo-se até o dia 15/12/2011 nas demais escolas da rede estadual de ensino. Ainda estão previstas a realização de conferências livres no município de Cantá, com a participação de munícipes de Normandia, Amajari, Iracema, Bonfim, Pacaraima, Mucajaí e Boa Vista; bem como, nas Universidades, e nos territórios indígenas, acampamento dos sem terra e sem teto.Acompanhem pelo sítio http://conliro.blogspot.com as propostas aprovadas e registro fotográficos.

Celso Duarte

CGURR-NAP

--

Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.
Para postar neste grupo, envie um e-mail para thac...@googlegroups.com.
Para cancelar a inscrição nesse grupo, envie um e-mail para thackday+u...@googlegroups.com.
Para obter mais opções, visite esse grupo em http://groups.google.com/group/thackday?hl=pt-BR.

--
a verdade está lá fora.

[Caio Cardoso Lucena]

Parabens!!!
Otima ideia
Como adiciono o Secretaria de Estado da Cultura de São Paulo para pedido?
Abraço a todos
Caio

2011/11/3 Geração de Calebe <cyber...@gmail.com>:

[Pedro Markun]

Oi Caio,

você pode passar as informações de contato por aqui mesmo, ou em:

http://www.queremossaber.org.br/pt/help/contact

O cadastro das organizações é feito manualmente pela equipe.

abs,

Pedro Markun

2011/11/3 Caio Cardoso Lucena <snp...@gmail.com>

[Duke]

Markun não acho certo os seus commit no Alaveteli no seu repositório, 

Primeiro por que você já tem problemas para seguir o master deles, por exemplo:

Se o arquivo crontab deles mudam, fudeu, vc tera conflitos necessariamente

O GeneralController e aquele numero magico no método perform_search deveria ser configuração e não hardcode, exatamente para que se mude uma instancia da app apenas

No RequestController não tem mais o medium_cache, acho que tinha que ser configuração da app isso tambem, esse conflito é pequeno pelo menos

O InfoRequest model tem texto hardcode, já teremos problemas de tradução ai, que na verdade já tinhamos antes com um request no meio do modelo :/

O alert-tracks cron já esta conflitado

 O partial correspondence da view request esta conflitado

Outra coisa as mensagens de commits não são claras, e não temos como reverter apenas o que esta zuado para concertar, perderemos a tradução, o git fica meio inutel assim, por que digo isso:

eu faço: 'git show 0d105c3d'

vejo o commit 'portuese timestamp locale added'

eu vejo que tem algo errado nele, eu deveria poder fazer 'git revert 0d105c3d' e 

não perder as mudanças que ele tem no .gitignore

E como eu faço isso? não usando git add .

a ideia é fazer pequenos commits que faça sentido e que seja isolado, vc corrigi algo e manda, adiciona algo e manda, ou seja, o git hoje ai é só uma ferramenta de diff de dias de trabalho.

Eu não curto o Alaveteli como programador, pode se bonito e até funcionar, entendo que os caras começaram a um tempo, mas poderia mudar muita coisa, tirar muitas coisas, ter um controle de dependências como o bundler e não depender tanto do servidor, não é um projeto que cadastra coisas no banco e mostra? por que preciso de tanta coisa no servidor, tem algo, do ponto de vista tecnico, errado ai. 

Precisarem só gritar ai!

[Everton Zanella Alvarenga]

Em 5 de novembro de 2011 21:29, Duke <du...@riseup.net> escreveu:
> Markun não acho certo os seus commit no Alaveteli no seu repositório,
> Primeiro por que você já tem problemas para seguir o master deles, por
> exemplo:

Por isso que eu sugeri criar um branch. É só sugerir para o Seb, ele
está ativo na lista do Alaveteli.

Já cometi o erro de fazer um fork no master de um código (quando eu
estava aprendendo git), aí depois para dar o merge com o projeto
principal foi uma dor de cabeça.

Com um branch, depois é só darmos o merge do master com um branch thacker.

[Duke]

Everton com um branch vc tera os mesmos problemas
A diferença é que o merge vem de um branch local e não do remoto.
Eu acho que essas coisas não deveria mudar, não hardcode, deveria ser internacionalizado, ter como configurar, etc.

[Everton Zanella Alvarenga]

Eu falei um branch remoto. Então no nosso branch sempre vamos fazendo
merge com o master do repositório original do alaveteli, não correndo
o risco do código divergir.

Se melhorarmos o código, podemos até sugerir um merge do master com
nosso branch.

[Vítor Baptista]

Everton,

O que facilita, para seguir o upstream, usar uma branch ao inves de um fork?

Ate onde eu sei, nao tem diferenca. Tem?

Abracos,
Vitor.

[Duke]

Exato Eveton,
mas o problema é que hoje não podemos mandar pull request com nosso fork,
vai ir coisas que ñ são legais para eles no meio,
e os commits do markun foram feitos por motivos validos,
seria interessante no lugar de corrir nosso fork criar uma solucão que podemos mandar para eles e outras pessoas usarem isso.

Vitor, branch e fork são coisas diferente,
Normalmente faz fork para colaborar ou seguir caminho diferente no projeto,
Nesse caso foi para suprir algumas necessidades, o problema é que a solução serve apenas para esse caso, o que fica difícil da rebase do upstream, não é impossível pode da conflitos que com mergetool se resolver fácil, mas ainda assim não é trivial como acredito que deveria ser.

[Vítor Baptista]

Duke, pode resolver isso usando duas branches: uma com mudancas especificas da mudanca da thacker e outra com melhorias gerais, que possam ser enviadas pro upstream.

Acho interessante manter repositorios separados pq assim o Pedro pode adicionar colaboradores.

[Tiago Cardieri]

Pedro, é avancado ou cabe leigo nesse aprendizado?

[Everton Zanella Alvarenga]

Essa aqui foi a solução proposta pelo povo do Alaveteli

"@everton137 if you are making a theme, use the branch with refactored
CSS, which I will be merging when back from paternity leave :)
30 Oct via web"

http://twitter.com/#!/alaveteli_foi/status/130608432351952896

Em 6 de novembro de 2011 07:48, Vítor Baptista
<vi...@vitorbaptista.com> escreveu:

[Fabiano Angélico]

Entrevista do ministro Jorge Hage, da CGU:

"Cada ministério terá que ter um "Serviço de Informação ao Cidadão", o
SIC. Nós estamos neste momento montando o modelinho de como vai ser o
SIC.
Para não ser muito custoso, nós imaginamos montar esse serviço ou
dentro da própria ouvidoria do órgão, com um, ou dois, ou três
funcionários encarregados do recebimento e da tramitação das
informações, ou então na Superintendência de Orçamento e Administração
que cada ministério tem. Ou na diretoria de pessoal de cada órgão. Ou
seja, em alguma unidade já existente especializar um pequeno grupo de
servidores para serem o primeiro contato do cidadão que vai pedir."
integra: http://www.informacaopublica.org.br/node/1943

On Nov 6, 2:17 am, Duke <d...@riseup.net> wrote:
> Exato Eveton,
> mas o problema é que hoje não podemos mandar pull request com nosso fork,
> vai ir coisas que ñ são legais para eles no meio,
> e os commits do markun foram feitos por motivos validos,
> seria interessante no lugar de corrir nosso fork criar uma solucão que podemos mandar para eles e outras pessoas usarem isso.
>
> Vitor, branch e fork são coisas diferente,
> Normalmente faz fork para colaborar ou seguir caminho diferente no projeto,
> Nesse caso foi para suprir algumas necessidades, o problema é que a solução serve apenas para esse caso, o que fica difícil da rebase do upstream, não é impossível pode da conflitos que com mergetool se resolver fácil, mas ainda assim não é trivial como acredito que deveria ser.
>
> On Nov 5, 2011, at 10:05 PM, Everton Zanella Alvarenga wrote:
>
>
>
>
>
>
>
> > Eu falei um branch remoto. Então no nosso branch sempre vamos fazendo
> > merge com o master do repositório original do alaveteli, não correndo
> > o risco do código divergir.
>
> > Se melhorarmos o código, podemos até sugerir um merge do master com
> > nosso branch.
>

[Pedro Markun]

Opa,

legal demais :)

abs,
Pedro Markun

2011/11/7 Fabiano Angélico <fabiano...@gmail.com>

[Fabricio Zuardi]

On Nov 5, 2011, at 10:05 PM, Everton Zanella Alvarenga wrote:

> Eu falei um branch remoto. Então no nosso branch sempre vamos fazendo
> merge com o master do repositório original do alaveteli, não correndo
> o risco do código divergir.
>

Voce pode fazer isto com um fork tb.

> Se melhorarmos o código, podemos até sugerir um merge do master com
> nosso branch.
>

Voce pode fazer isto com um fork tb.

[]s

[Everton Zanella Alvarenga]

Fabricio, como? (não sou o guru do git e sempre aprendo algo - além de
ainda apanhar às vezes : )

Em 7 de novembro de 2011 12:14, Fabricio Zuardi
<fabr...@fabricio.org> escreveu:

[Capi Etheriel]

tom, o git é um repositório descentralizado.

o que importa nele são as modificações (mais precisamente, os commits).

um branch é um histórico de modificações. eu posso ter mais de um histórico no mesmo repositório, é o que nós chamamos de branches.

um clone é uma cópia do repositório. ela é idêntica ao repositório original, quando criada.

mas provavelmente ele terá modificações diferentes. é portanto um histórico diferente (branch), mas chamamos de fork porque no repositório original essas modificações e esses históricos não existem.  

mas é a mesma coisa. existem comandos (git remote, git fetch) que trazem modificações de outros repositórios pro seu repositório.

[Everton Zanella Alvarenga]

Capi,

o que você falou eu sabia. O que não estou conseguindo entender é como
vamos manter o master do fork atualizado com o master do original.

Se tiver como um dar um merge entre o seb/master e o markun/master de
forma fácil, então sussa. Pois meu receio é justamente o markun/master
ficar parado enquanto o seb/master continua progredindo.

Apenas tinha pensando em trabalhar num branch remoto, sei lá
seb/thacker, e depois darmos um merge no seb/master. O próprio pessoal
do Alaveteli sugeriu via twitter criar um branch, como falei num post
anterior. Mas talvez isso seria o ideal para apenas uma pessoa
(confiável) trabalhando no branch.

[]'s,

Tom

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo
> "Transparência Hacker" dos Grupos do Google.

> Para ver esta discussão na web, acesse
> https://groups.google.com/d/msg/thackday/-/DwqeSVdU_WYJ.

[Everton Zanella Alvarenga]

Em 7 de novembro de 2011 16:54, Everton Zanella Alvarenga
<evert...@gmail.com> escreveu:

> Capi,
>
> o que você falou eu sabia. O que não estou conseguindo entender é como
> vamos manter o master do fork atualizado com o master do original.
>
> Se tiver como um dar um merge entre o seb/master e o markun/master de
> forma fácil, então sussa. Pois meu receio é justamente o markun/master
> ficar parado enquanto o seb/master continua progredindo.

Ou, pior ainda, modificarmos o código principal e depois ter que ficar
corrigindo. Mas, como falei, se houver um jeito de deixar o
markun/master sempre atualizado com o seb/master, não é preciso se
preocupar com isso, basta sempre atualizarmos o markun/master.

Falei alguma bobagem? : )

[Fabricio Zuardi]

É só dar um pull ou fetch do seb/master regularmente, e resolver eventuais conflitos a cada pull/merge.

É claro que o ideal é avisar o seb para puxar de vcs tb caso alguma contribuicao de vcs seja relevante para eles. É mais ou menos este o espírito, cada um trabalha no seu e puxa o que interessar dos outros...

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.

[Tiago Cardieri]

Capi, linda explicação! Leigos daqui agradecem!

--
Tiago Cardieri

Skype
Voxer
Cel.
     

[Daniela B. Silva]

(outra) oficina de git: eu preciso \o/

2011/11/7 Tiago Cardieri <tiago.c...@gmail.com>

[Thiago Carrapatoso]

Ah, falei do projeto aqui, ó:

http://planetasustentavel.abril.com.br/blog/paisagem-fabricada/2011/11/07/queremos-saber-acesso-as-informacoes-publicas/

</jaba>

2011/11/7 Tiago Cardieri <tiago.c...@gmail.com>

[Fabiano Angélico]

Ótimo texto, Carrapatoso, mas só uma correção: a lei entra em vigor
180 dias após a sanção da presidente (e não 120 dias). Como ela deve
sancionar ainda este mês, a lei vale a partir de maio de 2012.

On 7 nov, 18:43, Thiago Carrapatoso <thiago.carrapat...@gmail.com>
wrote:

> Ah, falei do projeto aqui, ó:
>

> http://planetasustentavel.abril.com.br/blog/paisagem-fabricada/2011/1...
>
> </jaba>
>
> 2011/11/7 Tiago Cardieri <tiago.cardi...@gmail.com>

>
>
>
>
>
>
>
> > Capi, linda explicação! Leigos daqui agradecem!
>

> > Em 7 de novembro de 2011 18:28, Fabricio Zuardi <fabri...@fabricio.org>escreveu:
>
> >> É só dar um pull ou fetch do seb/master regularmente, e resolver
> >> eventuais conflitos a cada pull/merge.
>
> >> É claro que o ideal é avisar o seb para puxar de vcs tb caso alguma
> >> contribuicao de vcs seja relevante para eles. É mais ou menos este o
> >> espírito, cada um trabalha no seu e puxa o que interessar dos outros...
>
> >> On Nov 7, 2011, at 4:56 PM, Everton Zanella Alvarenga wrote:
>
> >> > Em 7 de novembro de 2011 16:54, Everton Zanella Alvarenga

> >> > <everton...@gmail.com> escreveu:

> > *Tiago Cardieri
>
> > Skype
> > Voxer
> > Cel.
>
> > *

[Everton Zanella Alvarenga]

Em 7 de novembro de 2011 18:43, Thiago Carrapatoso
<thiago.ca...@gmail.com> escreveu:

> Ah, falei do projeto aqui, ó:
> http://planetasustentavel.abril.com.br/blog/paisagem-fabricada/2011/11/07/queremos-saber-acesso-as-informacoes-publicas/
> </jaba>

Muito bom, mesmo, parabéns!

Sobre o nome Fundação do Conhecimento Livre, antes estou com uma
discussão mais básica (talvez menor no momento : ), sobre o uso da
palavra "livre" ou "aberta"

http://lists.okfn.org/pipermail/okfn-help/2011-November/001669.html

E um amigo sugeriu "Fundação pelo Conhecimento Livre", que também acho
legal, mas vou por para discutir na lista da okfn-br depois.

[Everton Zanella Alvarenga]

Em 7 de novembro de 2011 18:28, Fabricio Zuardi
<fabr...@fabricio.org> escreveu:
>

> É só dar um pull ou fetch do seb/master regularmente, e resolver eventuais conflitos a cada pull/merge.
>
> É claro que o ideal é avisar o seb para puxar de vcs tb caso alguma contribuicao de vcs seja relevante para eles. É mais ou menos este o espírito, cada um trabalha no seu e puxa o que interessar dos outros...

OK, mas uma dúvida bem básica. Se eu estiver com a clone markun/master
na minha máquina, como dou o pull na minha instância das atualizações
no seb/master? (por isso eu sugeri o branch, pois eu estaria no
seb/meu_branch e conseguiria sempre continuar atualizando o seb/master
- ou seja, é o jeito que sei fazer, hehe)

Eu achava que não dava, mas se der, ótimo! (eu só não sei como)

[Thiago Carrapatoso]

Opa!

Valeu! :)

Trocado lá!

2011/11/7 Fabiano Angélico <fabiano...@gmail.com>

[Duke]

Capi, acho que existem coisas que não estão de acordo no seu texto:

clone é um comando para trazer todos o histórico da um servidr remoto. Que necessariamente clona :P o remoto e que possivelmente pode virar um fork.

O comando remote manipula os servidores remotos mas não pegas os dados, o fetch traz as modificações de um remoto mas não aplica, quem aplica é o rebase onde vc diz o remoto e o branch.

Então, o que complica é o esquema de remotos e esse esquema de branch.

Respondendo ao Tom, não é comun ter um branch lá, isso custa muito, no sentido de que precisa ter uma pessoas com acesso de commits no repositório, isso é ruim, como acontece no open-source, cria-se um fork e manda-se pull request, isso é feito facilmente no github, basicamente eu crio alguns commits(alterações) e digo para o remoto do alaveteli, tenho commits aqui, eles aceitam ou não, os branchs não são para o que vc esta propando, o ideal é o markun/alaveteli/master esta de acordo com o seb/alaveteli/master, como o Fabiano disse fazemos contribuições e alterações com forks, o problema do markun/master é que os commits dele não são contribuições  o que o norma um fork de fato, ou seja, estamos seguindo para outra direção do que estava indo(pensem em um fork com um Y ;) )

O esquema de repositórios  descentralizado do git e muito fácil de explicar na pratica e com algumas imagens, vou ver se acho a apresentação que deu sobre git, fiz umas imagens. Se eu não achar vou tentar criar uma mostrando como seria uma receita de bola open-source no git usando os branchs, remotes, commits, fetch, rebase, pulls e pull request é muito simples isso é só pegar a manha.

Sent from my iPhone

--
Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.

Para ver esta discussão na web, acesse https://groups.google.com/d/msg/thackday/-/DwqeSVdU_WYJ.

[Everton Zanella Alvarenga]

Em 8 de novembro de 2011 00:37, Duke <du...@riseup.net> escreveu:

> Respondendo ao Tom, não é comun ter um branch lá, isso custa muito, no
> sentido de que precisa ter uma pessoas com acesso de commits no repositório,
> isso é ruim, como acontece no open-source, cria-se um fork e manda-se pull
> request, isso é feito facilmente no github, basicamente eu crio alguns
> commits(alterações) e digo para o remoto do alaveteli, tenho commits aqui,
> eles aceitam ou não, os branchs não são para o que vc esta propando, o ideal
> é o markun/alaveteli/master esta de acordo com o seb/alaveteli/master, como
> o Fabiano disse fazemos contribuições e alterações com forks, o problema do
> markun/master é que os commits dele não são contribuições  o que o norma um
> fork de fato, ou seja, estamos seguindo para outra direção do que estava
> indo(pensem em um fork com um Y ;) )

Aaho que gora saquei! Valeu, Duke! (ainda mais por ter digitado tudo
isso de um iphone, haha!) Não sabia que podíamos submeter o meu master
no deles, esse era o ponto dúbio (apenas colaborei com várias pessoas
sempre num mesmo projeto git, com vários branches).

Havia entendido o fork com um Y que estava possivelmente ocorrendo e
esse é meu medo, pois dependendo da divergência, será difícil eles
aceitarem nosso código.

E se tivermos o markun/alaveteli/master rodando em paralelo com o
seb/alaveteli/master (sempre atualizando), trabalhamos num branch
markun/alaveteli/thacker, mas sempre tentamos dar o merge desse branch
markun/alaveteli/thacker com o markun/alaveteli/master, enviando
quando conveniente o markun/alaveteli/master para o
seb/alaveteli/master? Isso não pode ajudar a não fugirmos do código
principal?

[Everton Zanella Alvarenga]

Puts, eu deveria ter lido a sugestão do pai da criança antes! (tá no
guia para desenvolvedores do Alaveteli)

* A successful Git branching model
<http://nvie.com/posts/a-successful-git-branching-model/>

Aí estão os desenhinhos, Duke!

A seção que me parece importante é "Supporting branches". Depois volto
com calma, só terei tempo de eventualmente mexer no código do
Alaveteli depois do dia 20.

Bem mais profissional que o jeito que trabalhei, hehe.

Em 8 de novembro de 2011 00:48, Everton Zanella Alvarenga
<evert...@gmail.com> escreveu:

[Duke]

Vou criar um thacker/master (a thacker tem um github) e fazer as atualizações do markun de forma que não desvie do que eles tem, ai é só ficar mexendo nas tradução mesmo e cada problema que tivemos que mexer no código mandamos para eles.

Sent from my iPhone

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "Transparência Hacker" dos Grupos do Google.

[Pedro Markun]

yes! :D

2011/11/8 Duke <du...@riseup.net>