Open Stack

Emilien, debtor looks like an interesting tool, thanks for the link.

As far as tracking upstream branches from local forks and carrying local
patches, we've had good luck with using the git-upstream tool on stack
forge: https://github.com/stackforge/git-upstream

It allows you to merge in upstream changes on a regular basis and will
automatically drop local changes if there is a matching Change-Id field in
the upstream branch.  It also allows you to manually tag specific changes
to drop.  We have this setup to run as a regular job and the merge commit
for the changes gets pushed to our internal Gerrit instance for review and
all our normal CI tools run against that so we can gauge the impact of the
merge.



On Wed, Jul 29, 2015 at 6:16 PM, Emilien Macchi <emilien at redhat.com> wrote:

>
>
> 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
>
>
> __________________________________________________________________________
> 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/20150730/33873edf/attachment.html>