[openstack-dev] [kolla] Backport policy for Liberty
Fox, Kevin M
Kevin.Fox at pnnl.gov
Fri Oct 9 18:09:05 UTC 2015
As an Op, that sounds reasonable so long as they aren't defaulted on. In theory it shouldn't be much different then a distro adding additional packages. The new packages don't affect existing systems unless the op requests them to be installed.
With my App Catalog hat on, I'm curious how horizon plugins might fit into that scheme. The App Catalog plugin would need to be added directly to the Horizon container. I'm sure there are other plugins that may want to get loaded into the container too. They should all be able to be enabled/disabled though via docker env variables though. Any thoughts there?
From: Steven Dake (stdake) [stdake at cisco.com]
Sent: Thursday, October 08, 2015 12:47 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [kolla] Backport policy for Liberty
Kolla operators and developers,
The general consensus of the Core Reviewer team for Kolla is that we should embrace a liberal backport policy for the Liberty release. An example of liberal -> We add a new server service to Ansible, we would backport the feature to liberty. This is in breaking with the typical OpenStack backports policy. It also creates a whole bunch more work and has potential to introduce regressions in the Liberty release.
Given these realities I want to put on hold any liberal backporting until after Summit. I will schedule a fishbowl session for a backport policy discussion where we will decide as a community what type of backport policy we want. The delivery required before we introduce any liberal backporting policy then should be a description of that backport policy discussion at Summit distilled into a RST file in our git repository.
If you have any questions, comments, or concerns, please chime in on the thread.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev