propuesta para organizar la localización argentina
Este documento se refiere a la discusión que se centra en cómo organizar la Localización Argentina de Odoo en GitHub con los objetivos de:
- Aumentar la colaboración en el desarrollo de la localización.
- Optimizar el trabajo en grupo, formando pequeños grupos especializados en cada módulo y funcionalidad.
- Reducir los tiempos de merge de los desarrollos que vayan ocurriendo en la localización.
- Aumentar las funcionalidades disponibles para los usuarios.
Esta propuesta surge de la necesidad de liberar la colaboración en forma ordenada. La propuesta tiene en cuenta las siguientes dimensiones en donde la localización puede encontrar discrepancias entre los colaboradores, de manera tal de poder manejarlas formalmente eficiente y reduciendo los conflictos entre ellas.
- Evolución/Desarrollo/Compatibilidad/Colaboración
- Funcionalidad.
- Requerimientos.
- Procesos.
- Implementación.
- Arquitectura de datos.
- Optimización del código.
GitHub nos permite trabajar con la dimensión Evolución/Desarrollo/Compatibilidad en forma de ramas (branchs) y el uso de bifurcaciones (forks). Ver introducción a GitHub
Odoo propone el manejo de las funcionalidades a partir de los módulos (addons).
Lo que no queda claro es cómo manejar las Implementaciones. En este punto propongo separarlas en sabores (flavors).
Un ejemplo es la implementación de la factura argentina. Las propuestas existentes son la representación de los documentos fiscales con un nuevo tipo Documento, o utilizando el Diario (journal) propio de Odoo.
Suponiendo que existen dos formas de implementar una funcionalidad, hay que diferenciarlas de alguna manera. Se presenta una opción.
- Utilizar colores.
Recomiendo utilizar por orden de aparición de las implementaciones el mismo orden del color del [arcoíris] (http://es.wikipedia.org/wiki/Arco_iris) Por lo tanto la implementación que funciona en la versión 7.0 actualmente l10n_ar_invoice podría llamarse l10n_ar_red_invoice y l10n_ar_orange_invoice la nueva propuesta.
La utilización de colores permite determinar dependencias de forma organizada, ya que una funcionalidad implementada para 10n_ar_red_invoice no va a funcionar sobre l10n_ar_orange_invoice, por lo tanto el nuevo módulo debería llamarse con el mismo color. Un ejemplo sería la relación de la factura con la factura electrónica.
- El desarrollo sobre la los módulos precedentes beneficia a los distintos sabores.
- Los módulos pueden convivir en un mismo servidor sin pisarse.
- La migración impacta negativamente entre diferentes sabores, pero no entre diferentes versiones de Odoo.
- Es difícil identificar que sabor es el más conveniente por usuario. Los sabores deberían tener una buena explicación del porqué existen para simplificar la vida a los implementadores/funcionales.
- Agrega complejidad a la instalación. Esto se resuelve con un buen wizard que solo pregunte que sabor quiere instalar.
- Podrían combinarse sabores en una misma instancia. Hay que tener en cuenta esta restricción!
Esta propuesta recomienda usar un repositorio por módulo de la localización. Todos los módulos deben tener su trunk en el grupo de la localización. El desarrollo debe ser en forks de los usuarios, y solo los merges deben ser trabajados en el trunk del grupo. Por lo tanto, esto implica tener varios repositorios:
- l10n_ar_generic_chart
- l10n_ar_account_check_debit_note
- l10n_ar_base_vat
- l10n_ar_invoice
- l10n_ar_reports_samples
- l10n_ar_vat_reports
- l10n_ar_wsafip_fex
- l10n_ar_account_check_duo
- l10n_ar_chart_generic
- l10n_ar_partner_title
- l10n_ar_sale
- l10n_ar_wsafip
- l10n_ar_wsafip_puc
- l10n_ar_bank
- l10n_ar_fpoc
- l10n_ar_receipt
- l10n_ar_states
- l10n_ar_wsafip_fe
Nota: estos son ejemplos.