Precisamos mesmo ter varias branchs?

[mileo]

Não seria melhor só a master?

[rvalyi]

Hum eu diria depende um pouco. En principio sim so master seria bom. Agora, existe a possivel vontade de botar o repo electronic documents dentro da OCA certo? Hoje eu diria que pelas dependencia nao poderia ser assim, porque realmente o pysped esta longe hoje dos padroes OCA (e tem bibliotecas Java ou em outras linguagem com mais qualidade e se se imagina uma arquitetura cliente-server que faria mais sentido do que cada worker carregar tudo isso na RAM para cada request na importaria tanto a lingagem). Ou seja do meu lado, eu diria que poderiamos imaginar que o electronic documents chega na OCA na v9 ou 10, mas na condicao que o pysped chega la primeiro (poderia ser na v9 de repente se o codigo ser limpado muito). Nessa perspetiva teria mudancas e teria que adotar os padroes da OCA e ai sim justificaria varias branches.

Resumindo eu acho que hoje pode ser so master, mas daqui 6 meses / 1 ano poderia ser reconsiderado caso ainda tenha vontade de accrescentar o scope da localizacao na OCA.

[danimaribeiro]

No caso deixaria a 8.0 que eh a mais completa.
👍

[mileo]

Vou fazer o merge da 8.0 na master e apagar as outras, mas manter a 8.0 por questões de compatibilidade.

Fiz esse buildout hoje https://github.com/odoo-brazil/odoo-brazil-buildout/blob/master/default.cfg#L21

Baseado no da camp2camp para ver se conseguimos padronizar algumas coisas.

[mileo]

Lembrando que tem alguns PR que dependem delas, então vai ficar pra depois =(

[mileo]

@danimaribeiro @rvalyi @renatonlima

Estou dando uma revisa no pysped hoje e proponho o que tenhamos somente duas branchs:

• Master: rebase from ARY
• Odoo: Com as nossas modificações.

[renatonlima]

@mileo

👍 Eu diria que poderia deixar estas duas mesmo a master do upstream (branch do Ari) e a Odoo com os nossos PR, vale a pena deixar a branch Odoo como padrão para facilitar para o pessoal baixar.

[rvalyi]

👍

ourtra coisa @mileo: Nos estamos pensando que a localizacao OCA poderia sim ate assumir usar o o pysped para a serializacao xml e txt (sendo uma evolucao para o txt). Digamos como padrao explcitamente isolado no codigo e que seria ainda possivel de trocar se for preciso.

Agora seria bom mesmo deixar as partes de transmissao e impressao de DANFE plugaveis mesmo porque sao as partes mais ariscadas do pysped: as partes chatas de manter, chatas de migrar para python 3 etc... Por outro lado serializar um objeto Odoo em XML de Nfe sempre vai precisar de um mapping, mesmo se usar uma lib atras de um webservice (para chamar o webservice entao). Entao nesse ponto de serializacao XML nao tem muito a se ganhar de usar algo alternativo e parece que isso e o minimo que temos que manter na OCA de qualquer jeito.

Nisso talvez a gente consegue fazer modificacoes simples do projeto pysped para que as dependencias para transmissao e impressao sejam opcionais apenas. Eu ainda nao olhei se e facil de se fazer ou nao. A gente poderia ate propor de modularisar mais o pysped no uptsream do ary. So nao sei se o projeto e ativo suficente no upstream para isso.