<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Tue, 3 Oct 2017 at 18:15 Doug Hellmann <<a href="mailto:doug@doughellmann.com">doug@doughellmann.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Excerpts from Jesse Pretorius's message of 2017-10-03 15:57:17 +0000:<br>
> On 10/3/17, 3:01 PM, "Doug Hellmann" <<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>> wrote:<br>
><br>
> >> Given that this topic has gone through several cycles of discussion and has never gone anywhere, does it perhaps merit definition as a project interface so that we can define the problem this is trying to solve and set a standard formally once and for all?<br>
><br>
> >    Maybe a couple of the various packaging projects can agree and just<br>
> >    set a de facto rule (and document it). That worked out OK for us<br>
> >    with the doc reorganization when we updated the docs.o.o site<br>
> >    templates.<br>
><br>
> I’m happy to facilitate that. Is there some sort of place where such standards are recorded? Ie Where do I submit a review to and is there an example to reference for the sort of information that should be in it?<br>
><br>
<br>
The docs team put that info in the spec for the migration. Do we<br>
have a packaging SIG yet? That seems like an ideal body to own a<br>
standard like this long term. Short term, just getting some agreement<br>
on the mailing list would be a good start.</blockquote><div><br></div><div>Bah - missed the start of this thread but here's my tuppence</div><div><br></div><div>1) +1 for a consistent approach across projects - /usr/share/<module> sounds like a sensible location - avoiding any complexity with managing changes made by users in /etc/<project> for deploy from source use-cases, and allowing packagers to know where to expect reference/sample config files to appear during the package build-out/install process.</div><div><br></div><div>2) Looking at the Ubuntu packaging for OpenStack projects, we have quite a few places where oslo-config-generator or oslo-policy-generator is used to generate sample configuration files as part of the package build; I might have missed it in my read through of this thread but it would be awesome if those could be integrated as part of this process as well as the originating project would then be able to provide some level for assurance to the content of generated files in downstream distributions.</div><div><br></div><div>I'd also be +1 on a packaging SIG; I don't think it will ever be a high overhead SIG but it sounds like there are common challenges for deployment projects and distributors which would benefit from shared focus.</div><div><br></div><div>Cheers</div><div><br></div><div>James</div></div></div>