On 11/30/2015 05:14 PM, Doug Hellmann wrote:
Excerpts from Dmitry Tantsur's message of 2015-11-30 10:06:25 +0100:
On 11/28/2015 02:48 PM, Doug Hellmann wrote:
Excerpts from Doug Hellmann's message of 2015-11-27 10:21:36 -0500:
Liaisons,
We're making good progress on adding reno to service projects as
we head to the Mitaka-1 milestone. Thank you!
We also need to add reno to all of the other deliverables with
changes that might affect deployers. That means clients and other
libraries, SDKs, etc. with configuration options or where releases
can change deployment behavior in some way. Now that most teams
have been through this conversion once, it should be easy to replicate
for the other repositories in a similar way.
Libraries have 2 audiences for release notes: developers consuming
the library and deployers pushing out new versions of the libraries.
To separate the notes for the two audiences, and avoid doing manually
something that we have been doing automatically, we can use reno
just for deployer release notes (changes in support for options,
drivers, etc.). That means the library repositories that need reno
should have it configured just like for the service projects, with
the separate jobs and a publishing location different from their
existing developer documentation. The developer docs can continue
to include notes for the developer audience.
I've had a couple of questions about this split for release notes. The
intent is for developer-focused notes to continue to come from commit
messages and in-tree documentation, while using reno for new and
additional deployer-focused communication. Most commits to libraries
won't need reno release notes.
This looks like unnecessary overcomplication. Why not use such a
convenient tool for both kinds of release notes instead of having us
invent and maintain one more place to put release notes, now for
In the past we have had rudimentary release notes and changelogs
for developers to read based on the git commit messages. Since
deployers and developers care about different things, we don't want
to make either group sift through the notes meant for the other.
So, we publish notes in different ways.
Hmm, so maybe for small libraries with few changes it's still fine to
publish them together, what do you think?
The thing that is new here is publishing release notes for changes
in libraries that deployers need to know about. While the Oslo code
was in the incubator, and being copied into applications, it was
possible to detect deployer-focused changes like new or deprecated
configuration options in the application and put the notes there.
Using shared libraries means those changes can happen without
application developers being aware of them, so the library maintainers
need to be publishing notes. Using reno for those notes is consistent
with the way they are handled in the applications, so we're extending
one tool to more repositories.
developers? It's already not so easy to explain reno to newcomers, this
idea makes it even harder...
Can you tell me more about the difficulty you've had? I would like to
improve the documentation for reno and for how we use it.
Usually people are stuck at the "how do I do this at all" stage :) we've
even added it to the ironic developer FAQ. As to me, the official reno
documentation is nice enough (but see below), maybe people are not aware
of it.
Another "issue" (at least for our newcomers) with reno docs is that
http://docs.openstack.org/developer/reno/usage.html#generating-a-report
mentions the "reno report" command which is not something we all
actually use, we use these "tox -ereleasenotes" command. What is worse,
this command (I guess it's by design) does not catch release note files
that are just created locally. It took me time to figure out that I have
to commit release notes before "tox -ereleasenotes" would show them in
the rendered HTML.
Finally, people are confused by how our release note jobs handle
branches. E.g. ironic-inspector release notes [1] currently seem to show
release notes from stable/liberty (judging by the version), so no
current items [2] are shown.
[1] http://docs.openstack.org/releasenotes/ironic-inspector/unreleased.html
[2] for example
http://docs-draft.openstack.org/18/250418/2/gate/gate-ironic-inspector-releasenotes/f0b9363//releasenotes/build/html/unreleased.html
Doug
Doug
After we start using reno for libraries, the release announcement
email tool will be updated to use those same notes to build the
message in addition to looking at the git change log. This will be
a big step toward unifying the release process for services and
libraries, and will allow us to make progress on completing the
automation work we have planned for this cycle.
It's not necessary to add reno to the liberty branch for library
projects, since we tend to backport far fewer changes to libraries.
If you maintain a library that does see a lot of backports, by all
means go ahead and add reno, but it's not a requirement. If you do
set up multiple branches, make sure you have one page that uses the
release-notes directive without specifing a branch, as in the
oslo.config example, to build notes for the "current" branch to get
releases from master and to serve as a test for rendering notes
added to stable branches.
Thanks,
Doug
__________________________________________________________________________
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
__________________________________________________________________________
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
__________________________________________________________________________
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
