INTRODUCCIÓN
En muchos casos, un desarrollador ha realizado la migración de un módulo, el código ha pasado los tests automáticos de github y funciona correctamente, pero al no terminarse el proceso de aprobación, no está disponible para la comunidad.
Esta guía quiere visibilizar cómo se realiza este proceso, para que se pueda llevar a cabo con la calidad necesaria y en el menor tiempo posible.
LOCALIZACIÓN ESPAÑOLA
Su repositorio en github se llama l10n-spain y el estado completo de la migración a v13 se publica en el issue#1184 . Esta página se actualiza constantemente y puedes consultarla cada vez que quieras saber si algún módulo en concreto se ha migrado o si está en proceso.
Para que un módulo se publique en una versión nueva, debe publicarse (merge) el PR (Pull Request) que lo contiene su migración.
Y para que el PR se publique debe cumplir los siguientes requisitos:
-
Pasar los test automáticos y
-
Alguna de las siguientes 2 opciones:
-
En menos de 5 días: aprobación por 3 colaboradores.
-
En más de 5 días: aprobación por 2 colaboradores.
En ambos casos, al menos uno de los colaboradores debe ser PSC o Core maintainer.
En nuestro caso, tenemos 3 PSCs: Pedro Baeza (Tecnativa), Ignacio Ibeas (Acysos) y Harald Panten (Sygel).
Para ayudar a agilizar las aprobaciones, sería interesante ampliar la lista de PSCs, por lo que si alguien quiere presentarse, que lo notifique a la Asociación escribiéndonos un email a
hola@aeodoo.org
. Como es lógico, hay que tener conocimientos técnicos y/o funcionales importantes sobre la localización española.
TÚ PUEDES AYUDAR
De lo anterior se deduce que CUALQUIER COLABORADOR miembro de OCA y con cuenta en github, puede realizar aprobaciones de PRs.
Y fíjate que sólo con tu aprobación y la de un PSC, ¡el PR quedará aprobado!
Así que ya ves que tu esfuerzo tendrá una rápida repercusión una vez que cuente con el ok de un PSC. Puedes sugerirles hacer su revisión una vez que tú has dado tu conformidad, aportando la información que consideres relevante para ayudarles en el proceso de revisión.
Si todavía no eres miembro de OCA, este es un buen momento para
darse de alta
. Basta con pagar su cuota de 50€/año y firmar el contrato de licencia CLA.
¿CÓMO?
1) Primero selecciona de la
lista de módulos
, aquellos que estén sin publicar (estado “Open”) y cuyo funcionamiento conozcas.
2) Pulsa en el enlace de la derecha (p.ej. #1352) y te llevará a su PR.
3) Cuando el desarrollador crea el PR, github pasará unos tests automáticos.
Si los ha pasado correctamente, al final del PR verás un cuadro similar a este con los 4 tests en verde:
Esto quiere decir que ya puedes hacer tus comprobaciones.
4) Para ello, pulsa en el enlace indicado que te llevará a una instancia de Runbot como esta:
5) Pulsa en el botón azul indicado y te llevará a la instancia en la que puedes hacer las pruebas.
6) Haz prueba exhaustivas, hasta donde conozcas la funcionalidad del módulo que estás probando. Ten en cuenta que la calidad del módulo final depende de que tus pruebas cubran todos los casos de uso posibles. Es una labor que requiere una buena concentración.
Si detectas errores, publica un mensaje en el PR con la información necesaria, para que los desarrolladores lo corrijan. Recuerda que en este repositorio nos podemos comunicar en español.
Si crees que el README del módulo está incompleto u obsoleto, sugiere los cambios (recuerda que el README debe especificar la configuración y uso para que cualquiera sepa como usar el módulo).
Si ha ido todo bien, desde la pestaña “Files changed”, pulsa en “Review changes” y en “Approve” escribiendo un mensaje con la información que consideres, especificando si es una revisión funcional (en runbot, como acabamos de ver), técnica (del código), o ambas.
¡Y ya está! Sólo queda esperar unas horas o días a que el PR quede aprobado o te respondan con algún comentario o propuesta.
Por último, no te olvides de suscribirte al PR para recibir un email con cualquier cambio que se produzca. Busca el botón en la columna derecha, en la pestaña “Conversation”.
MÁS INFORMACIÓN
¿Qué es un PSC ? Son las siglas de “Project Steering Committee” y es el equipo responsable de un área funcional o de una localización. Normalmente tiene varios miembros que son elegidos por votación.
Coloquialmente decimos que un colaborador es un PSC si es miembro del PSC de ese repositorio.
En estos momentos hay 52 equipos por áreas funcionales, 11 equipos en conectores, 3 equipos en proyectos generales y uno más (unos 48) por cada localización.
“PSCs” en l10n-spain. Para ayudar a agilizar las aprobaciones, sería interesante ampliar la actual lista de 2 miembros de este PSC, por lo que si alguien quiere presentarse, que lo notifique a la Asociación, que será bienvenido. Como es lógico, hay que tener conocimientos técnicos y/o funcionales importantes en la localización española.
¿Qué es un Core maintainer ? En estos momentos, son 16 colaboradores con una responsabilidad similar a los miembros de los PSC, pero con una cobertura global.
OCA, Review modules - And improve their quality
OCA, Code your module - And share it