A atualização do brasil.gov.portal não roda todos os upgrades steps: deveríamos deixar de escondê-los e mostrar no painel de controle ou continuar com a atualização deles no upgrade do brasil.gov.portal?

[hvelarde]

Pelo que testamos ao rodar a atualização do brasil.gov.portal os seguintes pacotes ficam sem se atualizar:

• brasil.gov.barra
• brasil.gov.portlets

esses podem se atualizar diretamente no painel de controle, mas tem outros que só ficam visíveis no portal_setup:

• brasil.gov.tiles
• plone.app.blocks
• plone.app.tiles

[idgserpro]

Estou revendo o issue que fez essa implementação de pacotes de terceiros em https://github.com/plonegovbr/brasil.gov.portal/issues/218 e cheguei à conclusão que o correto teria sido adicionar uma documentação sobre como atualizar entre versões no portal_setup e não ter feito a implementação disso em primeiro lugar.

Ao rever "se o brasil.gov.portal decidiu atualizar todas as dependências, ele passa a ter a responsabilidade de garantir a consistência de todas as instalações" é exatamente o que estamos enfrentando agora com esse relato aberto.

A observação de plone.app.blocks ou plone.app.tiles por exemplo a gente tinha previsto em "como agir com dependências de dependências" (onde ficou definido que deixaríamos como está) e sobre ter que ainda acessar o portal_setup nesse contexto também. Tivemos inclusive efeitos colaterais (1 e 2) que nem tínhamos previsto e que, se os upgradeSteps tivessem sido aplicados manualmente, não aconteceriam. Em resumo: não estamos querendo apontar "dedos" nem nada, mas apenas reafirmar que, exatamente por esse tipo de problema não ter uma solução muito "elegante" de se resolver, que éramos contra essa implementação. Achamos que o esforço dispendido pelo benefício fornecido não vale a pena.

Quando esse relato de executar upgrades dos outros foi atendido, o mauritis ainda não tinha efetuado as melhorias no GenericSetup de apenas mostrar os profiles que possuem atualização pendente: com essa melhoria que ele fez achamos ainda mais irrelevante e contraproducente continuarmos seguindo por esse caminho de atualizar produtos de terceiros. Não reclamamos do que foi feito, foi interessante, foi uma prova de conceito que foi útil para definirmos como seguir pra frente.

De qualquer forma, não quer dizer que não temos proposta de solução, nós temos: votamos por melhorar a documentação de atualização entre releases e usar o que está pronto no portal_setup: é o processo tradicional de usar upgradeSteps, a documentação será a mesma para todo novo release, está testado e não tenho o overhead de:

• para cada novo release, ficar vasculhando qual dependência e qual dependência da dependência tem o upgradeStep (correndo o risco de esquecer alguma);
• escrever código para atualizar essa dependência (com risco de efeitos colaterais);
• escrever teste pro código de atualização da dependência;
• teste manual exploratório da atualização da dependência.

Achamos a intenção de simplificar esse processo louvável, mas o esforço não vale a pena e achamos o direcionamento incorreto. Se há o interesse de tornar mais "intuitivo" qualquer um desses processos (ou "evitar ZMI"), achamos que isso deveria ser feito pelo Plone e não pelo IDG, e é exatamente por esse motivo que questões desse tipo a gente sempre leva pra lá, como por exemplo o fato de ficarmos escondendo profiles.

[hvelarde]

eu não estou muito por dentro disso ai, mas continuo acreditando que seria interessante ter uma atualização centralizada e única no IDGB.

a vantagem é que com o tempo isso vai ficar mais estável e fácil de administrar, pois na verdade a ordem em que se rodam os upgrade steps não deveriam afetar na maioria dos casos.

de qualquer jeito, isso pode ser discutido com mais membros da comunidade para chegar em um consenso.

[idgserpro]

mas continuo acreditando que seria interessante ter uma atualização centralizada e única no IDGB.

Nós também achamos interessante, só achamos que o esforço pra se fazer não compensa quando basta adicionar uma documentação que será a mesma para todos os release, "entre no portal_setup e os profiles que aparecerem pra atualizar você atualiza" depois da melhoria que o maurits fez.

Se quiser seguir por esse caminho, a gente pode revisar os seus PRs assim como você faz com os nossos. Fico aqui nosso agradecimento aliás. :)

[idgserpro]

Se for seguir por esse caminho, não esquecer do relato https://github.com/plonegovbr/brasil.gov.portal/issues/239

[idgserpro]

Acho que o caminho ideal seria:

• Parar de esconder pacotes que hoje são escondidos no brasil.gov.portal (se for seguir por esse caminho, https://github.com/plonegovbr/brasil.gov.portal/issues/296 pode ser fechado);
• A documentação de atualização de release simplesmente informar "acesse o Painel de Controle do portal, opção Complementos, e execute a atualização de todos os pacotes que pedirem atualização.";

Dessa forma, continua centralizado, é a tela que o usuário já está acostumado, não precisamos fazer mais código e segue o padrão Plone.

Enquanto isso não é feito, ficamos com a documentação de forma temporária criada em https://github.com/plonegovbr/brasil.gov.portal/issues/332.

[hvelarde]

lembrem que Plone, por padrão, também oculta alguns profiles e toma conta da atualização de algumas dependências.

[idgserpro]

Sim, mas o próprio Plone toma conta disso na opção de atualizar quando você entra na ZMI.

Se tiver alguma situação, entre releases, do IDG, de uma dependência que não aparece no painel de controle mas tem upgradeStep, precisamos tratar isso em brasil.gov.portal: mas o interesse agora é que isso seja exceção, e não a regra para evitar retrabalho e os erros que tivemos com esse tipo de abordagem.

De qualquer forma, isso precisa ser documentado para que em todo release seja verificado, então criamos o lembrete em https://github.com/plonegovbr/portalpadrao.release/issues/20