Ciclo de desenvolvimento da 1.5

[Rodrigo Souto]

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/

-------------- Pr�xima Parte ----------
Um anexo n�o-texto foi limpo...
Nome: signature.asc
Tipo: application/pgp-signature
Tamanho: 473 bytes
Descri��o: OpenPGP digital signature
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20160229/043fbaf4/attachment.pgp>