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

Tue Mar 1 14:11:25 BRT 2016

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 em 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 em 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
-------------- Pr�xima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20160301/598ad60f/attachment-0001.html>