On Wed, Jun 03, 2015 at 04:30:17PM -0400, Sean Dague wrote: > The closer we can get logic about what a service should look like on > disk back into that service itself, the less work duplicated by any of > the installers, and the more common OpenStack envs would be. The fact > that every installer / package needs to copy in a bunch of etc files > (because the python packages don't do it) has always seemed rather odd > to me.
I agree with this, and given the disparate and seemingly contradictory goals driving these discussions, I think it will be exceedingly difficult to make everyone happy. So here's my suggestion: 1. Maintain all important data for packaging as first-class members of the respective repositories. Initscripts, systemd service files, licensing (SPDX?), and so on should be in the master branch of each project. Just enough glue should be present such that functional packaging can be programmatically generated from HEAD with debdry or similar tooling, and this is how test jobs should operate (f.ex.: run debdry, mangle version number to something unique, build package in chroot or equivalent, store output for use in other testing). 2. Create a single repository, with one subdirectory per "source package", in which overrides or patches to third-party packaging can be committed and used to trigger builds. This way OpenStack could - produce and consume its own package artifacts for testing changes of varying complexity - get early warning of changes which will break packaging, insanity in dependency graphs, and so on - be a central point of collaboration without introducing a bunch of repo duplication or bypass of code review Distributors could - clone the upstream repos and branch to add any special tweaks, then potentially run the same automation to get source/binary packages - collaborate upstream to fix things of common utility __________________________________________________________________________ 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