<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Feb 26, 2016 at 6:34 AM, Doug Hellmann <span dir="ltr"><<a href="mailto:doug@doughellmann.com" target="_blank">doug@doughellmann.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I've had a few conversations recently about "appropriate" content for<br>
release notes, so I thought it was worth starting a separate thread here<br>
to clarify.<br>
<br>
We have 3 potential audiences for release notes:<br>
<br>
1. Developers consuming libraries or other code directly.<br>
2. Deployers and operators.<br>
3. End-users.<br>
<br>
We implemented reno for this cycle to replace the old wiki-based<br>
system for writing release notes for deployers, operators, and<br>
end-users. We have in-tree developer documentation for Developers. The<br>
two sets of documentation are meant for different purposes, so we need<br>
to think about what information we publish in each.<br>
<br>
As you are writing release notes using reno to be published under<br>
<a href="http://docs.openstack.org/releasenotes" rel="noreferrer" target="_blank">docs.openstack.org/releasenotes</a>, please keep in mind the audience<br>
is *not* someone who is necessarily going to be looking at code or<br>
writing apps based on libraries we produce. Highlight information<br>
that deployers and operators will need, like changes to configuration<br>
options or service behaviors. Describe REST API changes that an<br>
end-user may need to know about.<br>
<br></blockquote><div><br></div><div>python-keystoneclient doesn't provide config options, so there should never be release notes for it. Probably best to disable releasenote generation for most of the python-*client libraries.<br><br></div><div>-- Brant<br><br></div></div></div></div>