Consul PRs flow

Situación actual:

Existen PR's creadas en Consul que no han partido del fork de Madrid, y basado en la experiencia suelen aparecer los siguientes problemas:

• En ocasiones tras mergear una PR de Consul pueden pasar días o semanas hasta que se mergeen esos commits en madrid#master generando:

  • Conflictos con nuevas PR's basadas en consul#master que intentan ser llevadas a madrid
  • Un diff entre consul y madrid que aumenta hasta ser una gran perdida de tiempo su resolución.

• A veces probando una feature enn Madrid encontramos mejoras/errores que solucionar, y al haber ya sido mergeada la PR original en Consul... acabamos haciendo 2-3 PR's más en Consul para "completar" una funcionalidad (a veces incluso commits furtivos en master). Sería mucho más elegante y sobre todo comprensible para alguien que se lea un Changelog o las release notes... que toda funcionalidad/mejora/cambio pudiese estar encapsulada en un único PR.

Solución sugerida

La forma correcta de trabajar para evitar estos problemas (tanto internos en Madrid como de cara al resto de forks) es trabajar como un fork más: https://github.com/consul/consul/wiki/Contributing-to-Consul-from-a-fork

Cómo solucionar PR's creadas en Consul "a la vieja usanza"

1. Creamos una rama en Madrid y hacemos cherry-pick de todos sus commits de la rama de la PR de Consul

2. Abrimos PR en Madrid, esperamos a que pase Travis y la probamos en PRE (y PRO si es necesario) hasta mergearla

3. [OPCIONAL] Si se hacen modificaciones/mejoras en la PR de Madrid... deberán ser cherry-pickeadas a la rama original de la PR de Consul

4. La PR original de Consul se mergea, añadiendo un comentario de que ha sido probada en Madrid. Y comprobando tras ello que el diff entre consul y madrid esta limpio de conflictos