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 <bdobre...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev