Re: Sobre o "next" e outras reflexões (era Re: Ciclo de desenvolvimento da 1.5)

[Bráulio Bhavamitra]

Oi Leandro e demais,

Desculpe a demora em responder, essa semana foi super puxada.

De maneira resumida gostaria de expressar minha opinião:

1) Gostaria de realmente usar a Integração Contínua e ter o ambiente de
testes constantemente no ar (a cada commit via script) para testes de
usuário, o que tornaria o freeze desnecessário ou meramente simbólico (uma
semana por exemplo)
  - nesse esquema o next tb não se faria necessário
  - pelo que vejo o gitlab está muito bem integrado com o CI, então já
podemos ver se os MRs quebram testes antes de fazer merge
  - ainda frequentemente quebramos os testes no master: o último merge
quebrou testes de dois plugins
  - o gitlab-ci não testa os plugins que tem Gemfile (e isso é tão simples
quanto rodar o rake test:noosfero_plugins com a
variável BUNDLE_OPTS=install), mas infelizmente existe uma birra com as
gems (ligado ao ponto 3)
  - uma exceção é para modificações estruturais (atualizações grandes no
core, do rails, etc), que é claro deveriam ser feitas da maneira mais suave
possível.

2) O autoritarismo realmente ainda existe de várias formas, no email do
diguliu ela se disfarçou dentro do elogio a chatice, seguindo a tradição de
RM. Outro disfarce é através do abuso da meritocracia.

3) Concordo que a transferência de práticas e aderência ao Debian ainda
causa muito problemas. Não vejo outros software livres web mantendo
dramaticamente a relação entre dinamicidade/estabilidade que existe no
Debian, é algo que flui bem com testes automatizados e de usuário rolando
constantemente.
  - No entanto, por conta de ser um ambiente usado para deploy, concordo em
manter o melhor suporte possível, desde que não prejudique o noosfero como
um todo, como atualmente prejudica e vai prejudicar ainda mais pois o único
empacotador (Terceiro) está com menos tempo para o Noosfero. Uma solução
simples é colocar as dependências *ainda* não empacotadas durante a
construção do pacote dentro da pasta vendor/bundle (opção --deployment do
bundle).

abraços!
bráulio

On Tue, Mar 1, 2016 at 2:11 PM Leandro Nunes <leandronunes at gmail.com> wrote:

> Olá pessoal,
>
> Diguliu não concordo com a não existência do branch "next" ou outra
> solução que evite a necessidade de se congelar o master abaixo explico os
> meus motivos.
>
> Antes de falar de outras motivações irei pontuar a existência do branch
> next e a sua história na comunidade.
>
> O branch next surgiu na release 0.45.0 criado quando Diguliu era o RM. (
> http://listas.softwarelivre.org/pipermail/noosfero-dev/2013-December/000895.html
> )
> Naquele momento a decisão se deu para permitir que pudesse haver
> incorporação de features novas independente do trabalho de correção de bugs
> da release. Observem o histórico de release abaixo:
>
> Características da release 0.45.0: (nesta release o branch next foi criado)
> RM: Diguliu
> Planejado: 2013
>   - 04/11/2013 Freeze and RC1 Release
>   - 11/11/2013 RC2 Releas
>   - 18/11/2013 Final Release
> Executado:
>   - 11/11/2013 Freeze and RC1 Release
>   - 02/12/2013 RC2 Release
>   - 09/12/2013 Final Release
> Resumo: 28 dias entre o freeze e o lançamento da versão
>
> Características da release 0.46.0
> RM: Diguliu
> Planejado
>   - Não encontrei
> Feito
>   - 17/01/2014 Freeze
>   - 10/02/2014 Release
> Resumo: 24 dias entre o freeze e o lançamento da versão
>
> Características da release 0.47.0
> RM: Diguliu
> Planejado
>   - 17/03/2014 Freeze
>   - 14/04/2014 Release
> Feito
>   - 20/03/2014 Freeze
>   - 22/04/2014 Release
> Resumo: 33 dias entre o freeze e o lançamento da versão
>
> Características da release Noosfero 1.0: (migração rails 3)
> RM: Terceiro
> Planejado
>   - 15/08/2014 Freeze
>   - 5/09/2014 Release
> Feito
>   - 15/08/2014 Freeze
>   - 22/12/2014 Release
> Resumo: 129 dias entre o freeze e o lançamento da versão
>
> Características da release 1.1
> RM: Terceiro
> Planejado
> - 01/03/2015 Freeze
> - 30/03/2015 Release
> Feito
> - 01/03/2015 Freeze
> - 04/05/2015 Release
> Resumo: 64 dias entre o freeze e o lançamento da versão
>
> Características da release 1.2 (neste moment houve a remoção do branch
> next)
> RM: Terceiro
> Planejado
>   - não encontrei
> Feito
>   - 17/06/2015 Freeze
>   - 07/08/2015 release
> Resumo: 51 dias entre o freeze e o lançamento da versão
>
> Características da release 1.3
> RM: Terceiro
> Planejado
>   - não encontrei
> Feito
>   - 09/10/2015 Freeze
>   - 06/11/2015 release
> Resumo: 28 dias entre o freeze e o lançamento da versão
>
> Características da release Noosfero 1.4
> RM: Terceiro
> Planejado
>   - não encontrei
> Feito
>   - 19/01/2015 Freeze
>   - 18/02/2015 release
> Resumo: 30 dias entre o freeze e o lançamento da versão
>
>
> Observem que no email enviado por Terceiro comunicando a remoção do branch
> next eu argumentei sobre a remoção do branch next (
> http://listas.softwarelivre.org/pipermail/noosfero-dev/2015-July/003626.html)
> e a resposta que tive foi.
>
>    "Você e os outros são livres para fazer o que quiser, mas não vou
> ajudar com qualquer coisa que não seja o lançamento mais rápido possível da
> próxima versão."
>
> Como eu li: Ok faça o que você quiser, mas não conte comigo para isso.
> Como eu sou o RM (quem mando neste momento) será da forma que eu quero.
>
> Como poderia ser: Pessoal sugiro não ter o branch next por este, este e
> este outro problema alguém tem alguma objeção? Se ninguém comentar em x
> dias a decisão está tomada.
>
> O papel do RM não é determinar como as coisas serão de forma unilateral,
> mas sim envolver commiters e usuários para buscar algum tipo de acordo
> sobre o planejamento e escopo de cada release.
>
> Neste momento irei abrir um parênteses para abrir uma outra reflexão para
> a comunidade...
>
> Na minha opinião este tipo de postura (é inegável que já aconteceram
> algumas vezes) não agrega em nada para a criação/sustentação de uma
> comunidade e é justamente essa postura que geram, ou contribuem, para as
> cisões nas comunidades de software livre. E isso não é uma crítica
> específica para Terceiro, mas sim a comunidade que tolera este tipo de
> postura (omissão é uma forma de se posicionar).
> Não estou aqui com o objetivo de demonizar Terceiro, ou quem quer seja. Eu
> (e outros) mesmo já tive postura semelhante em alguns momentos, mas
> comumente estes conflitos eclodiam de posicionamentos tomados de forma
> unilateral pela Colivre (na minha visão esse é o problema real). Eu sei que
> alguns vão dizer que isso não é o posicionamento da Colivre, mas do ponto
> de vista fático a Colivre tem a maior quantidade de commiters no projeto  e
> quando um membro da Colivre toma uma decisão e os outros não emitem opinião
> as pessoas que não convivem no dia  a dia da Colivre assume que é o
> posicionamento da organização, mesmo que isso não seja verdade. O mesmo
> ocorre quando vocês supõem que o meu posicionamento é o do Serpro algumas
> vezes sem que isso seja verdade. Este é o motivo de eu incentivar as
> pessoas pessoas daqui a se posicionarem sobre os assuntos.
> Por favor, não enxerguem isso como se eu também quisesse demonizar a
> Colivre. Eu fui membro da Colivre e sempre apoiei (e apoio) a organização
> quando pude/posso e tenho um carinho especial por quase todas as pessoas
> que fazem (ou fizeram) parte da organização. Considero muitos deles meus
> amigos. Agora a organização precisa refletir sobre algumas posturas e para
> que o Noosfero cresça (isso é bom para organização) é preciso "largar o
> osso" (decidir algumas coisas enquanto comunidade).
>
> Não estou aqui dizendo que não podemos discordar e também não estou
> querendo impor meu ponto de vista a ninguém só quero que ao menos as
> opiniões divergentes sejam respeitadas e discutidas por toda a comunidade e
> devemos ao máximo evitar decisões unilaterais ignorando as divergências
> existentes.
>
> Eu sei que com a nossa cultura brasileira normalmente tendemos a evitar os
> conflitos e na verdade o que acaba acontecendo é que estes conflitos são
> jogados para debaixo do tapete e eclodem em outra situações que não
> deveriam nem aparecer.
> Então gostaria que os commiters se manifestassem sobre o assunto e
> trouxessem argumentos para sustentar essa forma de trabalho e de
> preferência que isso fosse feito de forma respeitosa para trabalharmos de
> fato como uma comunidade saudável
>
> Espero que um dia que a nossa comunidade possa ter um código de conduta
> semelhante a este:
>
>
> https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
>
> Segue alguns trechos para quem estiver com preguiça de ler.
>
> "As contributors and maintainers of any Taiga.io project, and in the
> interest of fostering an open and welcoming community, we pledge to respect
> all people who contribute..."
>
> "Examples of unacceptable behavior by participants include:
>   - Personal attacks
>    - Trolling or insulting/derogatory comments"
>
> "Project maintainers have the right and responsibility to remove, edit, or
> reject comments, commits, code, wiki edits, issues, and other contributions
> that are not aligned to this Code of Conduct..."
>
> "...Project maintainers who do not follow or enforce the Code of Conduct
> may be permanently removed from the project team."
>
> "This code of conduct applies both within project spaces and in public
> spaces when an individual is representing the project or its community
> (like our mailing list, Google Groups, in Twitter, Facebook, etc.)."
>
> Como já ouvi algumas vezes esta comunidade se comparar com a comunidade do
> Linux espero que o código de conduta da comunidade também não seja o do
> Linux.
>
> http://lkml.iu.edu/hypermail/linux/kernel/1510.3/02866.html
>
> Segue alguns trechos para quem está com preguiça.
>
> "Christ people. This is just sh*t."
>
> "So I really see no reason for this kind of complete idiotic crap."
>
> "And it's a f*cking bad excuse for that braindamage."
>
> "I'm sorry, but we don't add idiotic new interfaces like this for idiotic
> new code like that."
>
> Fechando o parênteses e voltando ao assunto inicial.
>
> Muito provavelmente a escolha de Terceiro por este modelo (freeze) tem por
> motivação sua experiência com o Debian. Entretanto um o sistema operacional
> completo é bastante diferente de um software como o Noosfero e ainda que
> fosse algo conceitualmente comparável cada comunidade tem sua dinâmica a
> algumas coisas que funcionam para uma não funcionam para outra, pois as
> pessoas que compoem cada comunidade são diferentes. Pessoas diferentes
> tendem a dar soluções diferentes para o mesmo problema. Não estou querendo
> dizer com isso que devemos ignorar o que acontence ao redor do mundo, mas
> na minha visão este formato poderia ser diferente para o Noosfero e está
> brecando a evolução do produto.
>
> Eu entendo que a motivação inicial de se eliminar o branch "next" foi
> focar os esforços da comunidade para fechar logo a release, mas a adoção
> deste novo modelo não facilitou este processo. Basta observar que os
> motivos que levaram a não ter mais o next não se observou historicamente.
> Se isso fosse verdade todas as releases depois da remoção do "next"
> deveriam ser entregues antes do período que eram entregues antes da criação
> do "next" e a release 1.2 (primeira sem next) levou quase 2 meses para sair
> e no período que Diguliu era RM entregávamos em aproximadamente 1 mês.
> Pelo amor de Deus não quero criar intriga e dizer que não entregamos antes
> por causa de Terceiro até porque ser RM não significa ser faz tudo, mas me
> recordo que no período dos atrasos Terceiro estava com bastante limitação
> de tempo para se dedicar ao projeto, algumas mudanças no sotfware foram
> muito grandes e infelizmente boa parte do trabalho de empacotamento Debian
> ficou na mão de Terceiro por todos nós não o termos o ajudado a contento
> para lançar logo a versão. Observe que nestes últimos meses Terceiro está
> conseguindo se dedicar bem mais ao projeto e voltamos a ter lançamentos
> mais curtos.
> Resumindo não concordo com a premissa que fundamentou a decisão de que o
> branch "next" estava atrapalhando o lançamento das versões. As pessoas vão
> se comprometer, ou não, com o lançamento da versão por outras questões e
> não pelo fato do não congelamento do master. Infelizmente nem sempre todos
> da comunidade vão poder focar no lançamento da release e hoje a comunidade
> perde não ter essa incorporação de novas funcionalidades logo no master.
> Imagina termos 10 novos desenvolvedores fazendo codigo de coisa nova por 1
> mês (tempo mínimo que levamos para sair do freeze historicamente) o quanto
> de coisa não se faz em um mês, começa uma coisa depender de outra
> complicando excessivamente o trabalho de incorporação de conflitos depois
> do período da freeze e desestimulando a devolução do código para a
> comunidade. Eu sei que o ideal seria focar em lançar a versão e isso deve
> ser estimulado, mas nem sempre isso é possível por n motivos.
>
> A minha proposta na verdade é a mesma proposta que Terceiro já havia feito
> no passado e não me recordo de termos experimentado de verdade.
>
>
> http://listas.softwarelivre.org/pipermail/noosfero-dev/2013-December/000896.html
>
> Basta não congelar o master e criar um branch para a nova versão que será
> lançada e congelada. Na medida que correções de erros forem feitas na
> versão congelada quem fizer a correção se compromete em aplicá-la também no
> master. Fazendo desta forma não ocorreria o que Diguliu falou "... por
> experiência, a incorporação do branch next de volta ao master nunca é suave
> como se pressupõe ser." uma vez que não teremos um next para ser mergeado
> no master no futuro.
>
> Acredito que o nosso maior problema em relação aos lançamentos é não
> termos um ambiente de CI de verdade para garantir de verdade que código não
> quebre os testes que estão passando. Esse normalmente é o motivo dos
> atrasos das releases (acredito que esta é a primeira vez nos últimos 2 anos
> que temos todos os testes passando no master). Já nos colocamos a
> disposição para ajudar a comunidade neste sentido tanto que iríamos tocar
> alguma solução para resolver o problema entretanto estamos aguardando a
> decisão do caminho a ser seguido, pois não queremos que aconteça o que
> ocorreu com Braulio onde o mesmo fez todo um trabalho relacionado com o
> plugin responsive que foi validado pela comunidade e a percepção que tenho
> hoje é que "o trabalho será todo jogado fora", uma vez que a comunidade não
> vai seguir este caminho para a refatoração da interface do Noosfero.
>
> Outro ponto é que concordo com a "Lei do Cão" proposta por terceiro num
> email de título "Noosfero 1.1 delayed, and thoughts for the 1.2 cycle" (não
> encontrei o link) onde ele propôs:
>
>   - no MR can be merged without a passing CI run
>      - this will involve a certain effort to setup proper CI runners that
> integrate with gitlab (yes I am aware of the tests the Braulio recently did
> but still didn't have the chance of setting up a runner)
>   - commits that break the tests get imediately reverted, no matter what.
>   - people who break the tests twice in less than N days lose their commit
> rights
>
> Observe que isso irá se aplicará a todos e acredito que temos que ter
> posições deste tipo para "forçar" as pessoas a se preocuparem de verdade
> com isso. Talvez com um CI de verdade onde ninguém dá commit no master
> somente um robô depois de rodar todos os testes já resolva os problemas.
>
> Enfim, espero que a comunidade veja esse email com o objetivo a que ele
> foi feito que foi causar uma reflexão sobre a sua postura em recorrentes
> situações e a forma como alguns momentos as coisas são decididas sem
> considerar todos os stackeholders da comunidade.
>
> Peço desculpas a todos pelo tamanho do email, mas as vezes é preciso
> escrever muito para evitar ser mau interpretado.
>
> Abraços,
>
>
> 2016-02-29 13:55 GMT-03:00 Rodrigo Souto <rodrigo at colivre.coop.br>:
>
>> Olá pessoal,
>>
>> Como dito no e-mail anterior de Terceiro, estou assumindo o RM do
>> Noosfero e, como um bom RM, espero ser tão chato quanto Terceiro foi (ou
>> pelo menos próximo, já que chato igual a Terceiro é muito difícil).  ;)
>>
>> Peço a colaboração de todos nesse processo de transição e como primeira
>> lição de casa, sugiro a todos (re)lerem o:
>> https://gitlab.com/noosfero/noosfero/blob/master/DEVELOPMENT.md
>>
>> Seguem abaixo algumas considerações sobre o próximo release e alguma
>> regras de organização.
>>
>> == Cronograma
>>
>> Depois de uma mega release como foi a 1.4 e do parto que foi colocar ela
>> no mundo, nada mais natural do que voltarmos a nosso ciclo curto e
>> saudável de lançamento de 2 meses para assentar as coisas. O cronograma
>> de release da 1.5 será o seguinte:
>>
>> 31/03 - [FREEZE] Fim do período de incorporação de novas funcionalidades
>> 01/04 - Release RC1
>> 07/04 - Deadline para incorporação ou alteração de strings
>> 08/04 - Chamada para traduções:
>> https://hosted.weblate.org/projects/noosfero/
>> 15/04 - Release RC2
>> 22/04 - Release RC3 (caso necessário)
>> 02/05 - Release 1.5
>>
>> Todas as releases (incluindo RCs) terão disponibilizadas instâncias de
>> testes que serão divulgadas aqui na lista.
>>
>> Esse mesmo cronograma pode ser visto e acompanhado aqui:
>> https://gitlab.com/noosfero/noosfero/milestones/4
>>
>> == Freeze
>>
>> Houveram alguns conflitos nos últimos releases em relação ao freeze,
>> especialmente no que diz respeito a existência ou não do branch "next".
>> A razão de se existir um freeze não é somente para evitar que novos
>> problemas sejam incorporados e a release seja atrasada. Faz parte do
>> freeze também a mobilização da comunidade em prol do lançamento da
>> versão. Dentro desse objetivo, a manutenção de um branch "next" não é
>> viável, ao meu ver, pois a energia para tal deveria ser direcionada para
>> o fechamento do release, o que, por sua vez, viabilizaria a
>> revisão/incorporação mais cedo das funcionalidades que entrariam no
>> branch "next" de qualquer forma. Além disso, por experiência, a
>> incorporação do branch "next" de volta ao master nunca é suave como se
>> pressupõe ser.
>>
>> Ainda assim, imagino que essa necessidade irá se expressar
>> inevitavelmente no futuro. Para evitar conflitos desnecessários, sugiro
>> que os commiters que sentirem essa necessidade monitorem os
>> merge-requests que já revisaram e que pretendem incorporar pós-freeze
>> incluindo-os na milestone da versão seguinte. Dessa forma, a comunidade
>> como um todo não precisa assumir o compromisso da manutenção do branch
>> "next" e a responsabilidade de incorporação de cada merge-request
>> pós-freeze, junto com os problemas atrelados a ele, recai sobre o
>> commiter que o adotou.
>>
>> == Milestones
>>
>> O uso das milestones têm sido meio confuso na minha cabeça. Não existe
>> nenhum critério claro de quando uma issue ou um merge-request deve ser
>> incorporado na milestone. Para resolver isso, quero definir o uso das
>> milestones da seguinte forma:
>>
>>   * Uma issue ou merge-request deve ser alocado para uma milestone
>> somente quando um desenvolvedor se compromete em garantir a resoloção da
>> issue ou um commiter a incorporação do merge-request, ambos dentro do
>> tempo hábil da milestone alocada.
>>   * Não aloque uma issue ou um merge-request a uma milestone se não cabe
>> a você a solução/incorporação da solução.
>>   * Desta forma, toda issue alocada a uma milestone terá um
>> desenvolvedor de referência como o responsável pela solução do problema
>> e todo merge-request terá um commiter responsável pela revisão e
>> incorporação.
>>   * Ser o responsável pela issue/mr não implica em fazer o trabalho
>> sozinho, mas em mobilizar esforços e responder pelo cumprimento ou não
>> da atividade.
>>
>> Desculpa pela redundância, mas é melhor do que pecar pela ambiguidade!
>>
>> == Merge Requests
>>
>> Nós temos uma lista gigantesca de merge-requests aberto e eu não tenho
>> nenhuma esperança de reduzir esse valor a zero. Ainda assim, acredito
>> que existem muitas coisas importantes pendentes de incorporação.
>> Tentarei fazer uma geral, dentro da medida do possível, para fazer um
>> levantamento das coisas prioritárias e incorporá-las. Peço que os demais
>> commiters façam o mesmo.
>>
>> No mais, é isso,
>> Qualquer dúvida vocês já sabem onde me encontrar!  o/
>>
>>
>> _______________________________________________
>> Noosfero-br mailing list
>> Noosfero-br at listas.softwarelivre.org
>> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>>
>>
>
>
> --
> 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/20160305/5ef42772/attachment-0001.html>