[Rdo-list] OPM downstream patches

[Ivan Chavero]

> I think we would gain of having each Openstack Puppet module to extend
> its current branch structure in a 'distro sub-branch' way, such as:
> 
>   master
>     + +
>     | |
>     | +--> RDO9 +--> OSP9
>     |
> back|port
>     |
>     +--> stable/liberty +--> RDO8 +--> OSP8
>     |
>     |
>     +--> stable/kilo +--> RDO7 +--> OSP7

This should be done already for the official OpenStack puppet modules

> 
> 
> The structural complexity could be reduced by benefiting from limiting
> forks, as describe above, using branch for each related Openstack distro
> (RDO/OSP/etc). If this is not possible then each Opentack installer has
> to fork every Openstack modules it needs.
> 
> For, the non Openstack puppet modules, because there isn't any link to
> Openstack branches. A correspond fork has to be created.
> 
> Hence, a solution #3:
> 
> - For each installer
>  - Create a meta/wrapper package
>  - For each required/desired Openstack Puppet module
>    - If no 'distro sub-branches' available
>      - Module's source repo is forked
>      - Openstack equivalent branches structure are created
>    - A RPM package is created
>      - Non Puppet patches are applied if needed
>    - Add module to list of meta/wrapper package
>  - For each required/desired non Openstack Puppet module
>    - Module's source repo is forked
>    - Openstack equivalent branches structure are created
>    - Puppet patches are applied in correspond branch if needed
>    - A RPM package is created
>      - Non Puppet patches are applied if needed
>    - Add module to list of meta/wrapper package


There should be only one OPM package and the installers should be modified
to work with it. To maintain an OPM package for earch installer would be
a burden for the installer developers  and could generate confusion for the
people that uses only OPM without any installer.
Also, taking in account that every eight months or so there are  new 
iniciative to create a new installer we will end up maintaining a slightly
different OPM package for who knows how many installers we will end up with

Cheers,
Ivan