Re: Processo de Decisão e Congelamento

Tue Mar 15 20:22:00 BRT 2016

Outra coisa em relação ao RM: hoje vejo ele com dois trabalhos ainda
exclusivos:
1) anunciar a nova release, o que envolve organizar e descrever as novas
funcionalidades para os usuários finais
Aqui acredito que também podemos dividir o trabalho, ainda é necessário
pensar como.

2) fazer o empacotamento e testar o deploy no debian: este trabalho
considero ser útil para os ambientes que usam este sistema de deploy
(acredito que softwarepublicos e outras redes da Colivre), mas não é de
interesse de outros atores (como o participa, blogoosfero, cirandas, etc).
Aqui acredito que o trabalho deve ser dividido apenas entre os usuários
desse sistema de deploy, uma vez que outros também tem custos com seus
respectivos deploys.

PS: deixei de lado coisas menores, como a criação da tag e branches no git,
mas também poderia ser delegado pelo RM caso necessário, ou feito via
script (como provavelmente já o é)

att,
bráulio

On Tue, Mar 15, 2016 at 8:12 PM Bráulio Bhavamitra <brauliobo at gmail.com>
wrote:

> De acordo Leandro, vamos colocar isso no development.md.
>
> Vale apenas frizar que o cargo de RM não é o de cristo que carrega a cruz
> do noosfero e não vejo ele tendo nenhuma obrigação além de qualquer outro
> commiter de corrigir testes.
> A obrigação de corrigir os testes é do commiter que clicou no Accept para
> integrar o código.
>
> Não gostaria de ver ninguém fazendo trabalho voluntário ou de maneira
> forçada e sim que o fizesse tendo o devido tempo e recursos alocados,
> sobretudo no caso do RM. Ou seja, o RM não tem nenhuma obrigação a mais de
> integrar código se comparado com qualquer outro commiter.
>
> Não queremos transformar o RM e a organização que o sustenta em burro de
> carga.
>
> Aliás, a última integração quebrou testes, Rafael está precisando de ajuda
> para corrigí-los. Por favor reverter se tomar muito tempo.
>
> abraços!
> bráulio
>
> On Tue, Mar 15, 2016 at 6:40 PM Leandro Nunes <leandronunes at gmail.com>
> wrote:
>
>> Olá pessoal,
>>
>> Na última sexta-feira dia (11/03/2015) boa parte da comunidade de
>> desenvolvedores do Noosfero (Leandro, Victor, Joenio, Daniela e Rodrigo )
>> teve a oportunidade de se encontrar e nós aproveitamos este momento para
>> realizar algumas discussões sobre o andamento do projeto Noosfero, mais
>> especificamente sobre o processo de congelamento de código e também sobre o
>> processo de tomada de decisão da comunidade.
>>
>> A discussão foi bastante rica e proveitosa e ao final nós chegamos a
>> alguns consensos sobre estes dois pontos:
>>
>>   1 - Processo de Congelamento de Versão (freeze)
>>
>> O objetivo maior do freeze era direcionar toda a comunidade para se
>> esforçar para que o lançamento saísse o mais rápido possível. Apesar da
>> motivação ser muito boa ao longo da história dos releases o fato de existir
>> o congelamento do master não foi determinante para que o lançamento
>> ocorresse mais rápido.
>>
>> Nós notamos também que o fator que mais impactava na demora do lançamento
>> da versão era que o código tinha bastante teste falhando e o RM acabava
>> tendo muito trabalho para ajeitar todos os testes e lançar a versão. Apesar
>> desta não ser a obrigação somente do RM ele acabava tendo este encargo.
>>
>> Depois de muito tempo conseguimos ter novamente uma versão lançada com
>> 100% dos testes passando e vamos nos esforçar para que essa situação não
>> mude e isso é o pressuposto básico para que a proposta aqui apresentada
>> funcione.
>>
>> Pode parecer redundante, mas a ideia é que a partir da aprovação destas
>> ideias pela comunidade todos os commiters passem a ser responsáveis por
>> manter todos os testes sempre passando então um commiter só deve aceitar um
>> MR caso ele não quebre nenhum teste. É também fortemente recomendável que o
>> commiter não faça mais commits diretamente no master por mais simples que
>> seja a modificação. A ideia é utilizarmos os runners do gitlab ao nosso
>> favor e para os casos mais simples utilizar a opção de fazer merge
>> automaticamente quando a build for construída com sucesso. A ideia é que
>> qualquer commit feito diretamente para o master que quebre um teste seja
>> revertido por qualquer um dos commiters.
>>
>> Uma vez garantido este procedimento nós teremos o master sempre rodando
>> com todos os testes passando (em tese pronto para produção a qualquer
>> momento) então isso não será mais um blocker para o lançamento de uma
>> versão.
>>
>> Chegamos a um consenso de que iríamos experimentar ter o período de
>> freeze, mas isso não significaria mais congelar o master. O master
>> continuaria tendo atualização no período de freeze e seria criada uma nova
>> branch para a versão que será congelada. Neste período todos os commiters
>> continuarão sendo fortemente encorajados a auxiliar o lançamento mais
>> rápido possível da versão, mas novas funcionalidades poderiam ser
>> incorporadas no master normalmente. As correções de bugs que por ventura
>> venham a existir na versão congelada serão primeiro incorporadas no master
>> depois do branch estável da mesma forma que é hoje. Será responsabilidade
>> do commiter que corrige o bug garantir que este procedimento ocorra desta
>> forma e ele será cobrado pela comunidade para tal.
>>
>>   2 - Processo de tomada de decisão
>>
>> Nós concordamos que em alguns momentos nós entramos em deadlock numa
>> discussão e em alguns momentos algumas coisas precisam ser decididas, mas
>> não são.
>> Neste ponto não chegamos a fechar uma proposta, mas levantamos que não
>> deveríamos burocratizar muito o processo, mas ao mesmo tempo precisamos
>> garantir uma maturidade mínima nas discussões para não tomar decisões de
>> forma açodada.
>> Diante disso a minha proposta é a seguinte:
>> Quando algum membro (developer, commiter, RM etc..) da comunidade sentir
>> a necessidade de discutir algum assunto que seja pertinente a todos os
>> membros da comunidade e necessite de uma decisão este deverá abrir uma
>> issue no gitlab com label 'discussion' para que todos os membros possam
>> discutir. Cada commiter possui o poder de 1 voto para aprovar (+1) ou
>> rejeitar (-1) tal proposta. A proposta será considerada aprovada caso esta
>> tenha a maioria dos votos dos commiters considerando o quorum de votação
>> mínimo de 50% dos commiters. Quem tem interesse na aprovação da proposta
>> deve provocar os commiters (@nikcname na issue do gitlab que trata do
>> assunto) a se posicionarem sobre o tema discutido. Uma vez passado o prazo
>> de 1 semana e no mínimo 50% dos commiters já tenham explicitamente votado a
>> issue será fechada e a discussão sobre o assunto será encerrada.
>>
>> Eu preferi primeiro passar essas informações aqui na lista para depois
>> fazer as adaptações necessárias no arquivo "DEVELOPMENT.md"
>>
>> Caso alguém tenha alguma consideração a feita sinta-se à vontade para
>> fazê-la.
>>
>> Abraços,
>>
>> --
>> Dois Axé!!!
>>
>> -----
>> "Comece fazendo o que é necessário, depois o que é possível e de repente
>> você estará fazendo o impossível."
>>                                    São Francisco de Assis
>> Leandro Nunes
>> _______________________________________________
>> 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/20160315/b07127c7/attachment.html>