Cómo Desarrollar

TL;DR
Clona el repositorio:

$ hg clone https://foss.heptapod.net/tryton/tryton
$ cd tryton
$ hg topic my-change

Consulta la configuración enREADME.

Realiza tu modificación.

$ hg commit
$ hg push -r my-change

Haz clic en el enlace para crear la solicitud de integración.

Enviar un cambio

El proyecto usamercurialcomo sistema de control de versiones conhg-evolve extension.

  • Sigue eldirectrices.
  • Solicitar acceso to the proyecto(en el menú desplegable de acciones junto al título del grupo).
  • Envía tu cambio con unsolicitud de integraciónque te asignas a ti mismo.
  • Asegúrate de no romper las pruebas ejecutándolas y agrega pruebas si es necesario.
  • Resuelve todos los hilos abiertos por los revisores.
  • Una vez aceptada, tu solicitud de integración será fusionada por un publicador de Mercurial.

No es necesario cambiar la base de las solicitudes de fusión con demasiada frecuencia, incluso cuando hay conflictos, ya que esto suele ser solo para las entradas CHANGELOG.

Para facilitar el proceso de revisión, evite presionar la rebase y las modificaciones al mismo tiempo y establezca una nota al modificar un conjunto de cambios.

Para evitar consumir recursos de CI, marque la solicitud de combinación como borrador hasta que esté lista.

Guías

El proyecto Tryton tiene guías tanto para código como para documentación.

Código

Documentación

Hay varios lugares diferentes donde se puede encontrar la documentación de Tryton. Esto es para garantizar que esté disponible en el formato correcto, en el momento adecuado, para diferentes casos de uso.

Entonces, para evitar duplicaciones y mantener la documentación organizada y mantenible, existen varios conjuntos de pautas:

Mensaje de commit

  • Usa un título corto que empiece con mayúscula.
    • Usa el modo imperativo.
      De modo que complete la frase "Con este cambio, el proyecto…".
    • Usa nombres humanos de objetos en lugar del nombre técnico.
      Como "Factura" en lugar de "account.invoice".
  • Agrega detalles adicionales en el cuerpo del mensaje (opcional).
    • Menos de 80 caracteres por línea.
    • ExplicarWHATel cambio es, pero lo más importanteWHYel cambio es necesario.
    • Deja una línea en blanco entre el cuerpo y el título.
    • Separa los párrafos del cuerpo con líneas en blanco.
    • Usa un guion (-) para viñetas si es necesario.
    • Usa sangrías colgantes si es necesario.
  • Incluye elpattern to closeincidencias vinculadas (opcional).

Requisitos

Tu contribución debe cumplir los siguientes requisitos:

Debe

  • Al enviar un cambio, el contribuidor acepta elCertificado de origen del desarrollador.
  • El correo del contribuidor debe ser una dirección válida.
  • El dominio del correo del contribuidor no debe contener tryton.
  • The usernamede un conjunto de cambios mercurial debe tener la forma:
    Full Name <email>

Deseable, pero no obligatorio

  • El nombre del colaborador debe ser el nombre real de la persona física que envía el código.
  • El correo del contribuidor debe estar vinculado a un solo nombre de contribuidor.

Reglas

Si el contribuyente tiene una cantidad significativa de código, puede agregarse a sí mismo alCOPYRIGHTarchivo de los paquetes modificados.

En caso de desacuerdo, se debe llegar a un consenso. Como último recurso, el líder del proyecto (Cédric Krier) tomará la decisión.

Roles

  • Los desarrolladores pueden crear solicitudes de integración.
  • Los publicadores de Mercurial pueden fusionar solicitudes en la rama predeterminada.
  • Los mantenedores pueden hacer push directamente en todas las ramas para publicar versiones.

Publicar un cambio

Esta parte es solo para publicadores de Mercurial

Prefiere publicación sin merge (fast-forward).

Aplasta los commits de corrección que el desarrollador haya hecho en lugar de enmendar.

Ensure commit message contains proper pattern to closeincidencias vinculadas.

Retroportado

El mantenedor retroportará una corrección a series anteriores a su criterio mediante una solicitud de integración de backport. La decisión se basa en la importancia del error, la disponibilidad de una solución alternativa y la viabilidad.

Esas reglas no se aplican a los errores de seguridad que se aplican a la vez a todas las series afectadas y seguidos de un lanzamiento.