Open Stack

Hi,

one of cons: there might be delay in time when we need to apply a patch to
upstream project and thus fork some project (needs some time to prepare
patch to projects, get reviews and approves, etc). Having said that I vote
for "lazy downstreaming".

Regards,
Alex

On Fri, Jan 29, 2016 at 10:12 AM, Bogdan Dobrelya <bdobrelia at mirantis.com>
wrote:

> This is a continuation of the forked discussion [0].
>
> The idea is to relax Fuel-library downstream policy and implement a
> "lazy downstreaming", which is to not create a downstream fork of a
> puppet module referenced in the librarian Puppetfile unless we have to
> do so.
>
> The relaxed policy would unblock an upstream switching of the rabbitmq
> [1] and corosync [2] modules as well.
>
> Pros:
> - Reduced costs of maintaining downstream forks because of the laziness
> of the forking process. This much better distributes load to Fuel
> engineering and HW resources in time. Even though related tasks may be
> one-time, HW resources and network bandwidth shall not be wasted for
> keeping and cloning unnecessary forks (unless we have no choice but to
> fork things)
> -  A module might remain as direct upstream reference in the Puppetfile
> for quite a while. This as well shows an amount of the hidden technical
> debt in much more clean representation - downstream vs upstream refs in
> the Puppetfile.
> - Some generic, non OpenStack puppet modules will barely require
> backporting of separate patches by older tags as they work just
> straightforward and the latest version works for every supported Fuel
> release as well. Those would save resources because of the laziness of
> the relaxed process will never require to create downstream forks for
> such modules!
>
> Cons:
> - I see none. For "unlucky" modules, the *same* amount of work shall be
> done anyway, although with the lazy process in place it will be
> distributed in time much better.
>
> [0]
> http://lists.openstack.org/pipermail/openstack-dev/2016-January/085249.html
> [1] https://review.openstack.org/#/c/271217
> [2] https://review.openstack.org/#/c/273036/
>
> --
> Best regards,
> Bogdan Dobrelya,
> Irc #bogdando
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160129/33ec545f/attachment.html>