On 07/29/2015 03:48 PM, Alex Schultz wrote: > Hello everyone, > > I have put together a wiki describing the proposed interactions between > fuel-library and upstream modules based on previous talks around > librarian-puppet[0]. Please take some time to > review https://wiki.openstack.org/wiki/Fuel/Library_and_Upstream_Modules. > This page provides a brief history of this change, details of the > changes, best practices, and workflows for dealing with upstream modules. > > I have updated this page based on the feedback previously solicited > around my suggestion to use librarian-puppet to manage the inclusion of > upstream modules into fuel-library. During the implementation, we found > that packaging librarian-puppet and the dependency management became > burdensome. As a substitute, we have packaged librarian-puppet-simple > and will only be using git repository references for inclusion of > upstream modules. Also based on our build requirements, we are also > leveraging a fuel-infra mirror of upstream repositories to allow for > local builds and CI to not have to fetch modules continuously from > upstream github repositories. > > I have also taken the time to update the proposed patches[1] with the > librarian-puppet-simple configurations so they they are ready to merge > if there is an agreement on this process. > > Thanks, > -Alex > > [0] http://lists.openstack.org/pipermail/openstack-dev/2015-June/067806.html > [1] > https://review.openstack.org/#/q/topic:bp/fuel-puppet-librarian+project:stackforge/fuel-library,n,z >
This is a very good initiative and I'm happy to see that happening. It reflects what I was asking in our collaboration request. Though I have one suggestion for "Custom Upstream Module Changes" section. I suggest you: 1/ first submit the change in the upstream module 2/ cherry-pick the commit in Fuel custom branch 3/ keep track of upstream patch (address reviews, etc), and establish a sort of scoring to evaluate the debt [1] between downstream (Fuel) and upstream (OpenStack). It will make sure a maximum of code is upstream and downstream patches won't be forgotten. 4/ when an upstream patch is merged, drop the cherry-pick by rebasing. This is the workflow I try to push at Red Hat (in RDO) and to me, this is the way to go for having Puppet modules the closest as possible from upstream with the freedom to have custom patches downstream. Best, [1] https://github.com/redhat-cip/debtor -- Emilien Macchi
signature.asc
Description: OpenPGP digital signature
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
