[libvirt] [PATCH v3 3/3] docs: Document the release notes process for contributors

Now that we have built a fairly solid process for dealing with release notes, we should start pushing for contributors to provide the relevant information along with their code: documenting the process is clearly a requirement for this to happen. --- Changes from v2: * Address review comments - Point to the source file in user documentation - Phrasing Changes from v1: * Address review comments - Remove ambiguity between merely documenting changes and adding entries to release notes - Move from "should" to "must" - Move new information to a separate <li> - Regenerate HACKING file HACKING | 7 +++++++ docs/hacking.html.in | 10 ++++++++++ 2 files changed, 17 insertions(+) diff --git a/HACKING b/HACKING index c2cb037..ff545a8 100644 --- a/HACKING +++ b/HACKING @@ -226,6 +226,13 @@ to "tests/.valgrind.supp" in order to suppress the warning: (10) Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program. +(11) Don't forget to update the release notes <news.html> by changing +"docs/news.xml" if your changes are significant. All user-visible changes, +such as adding new XML elements or fixing all but the most obscure bugs, must +be (briefly) described in a release notes entry; changes that are only +relevant to other libvirt developers, such as code refactoring, don't belong +in the release notes. + There is more on this subject, including lots of links to background reading on the subject, on Richard Jones' guide to working with open source projects <http://people.redhat.com/rjones/how-to-supply-code-to-open-source-project...;. diff --git a/docs/hacking.html.in b/docs/hacking.html.in index 47475a2..c7bbcbd 100644 --- a/docs/hacking.html.in +++ b/docs/hacking.html.in @@ -294,6 +294,16 @@ <p>Update tests and/or documentation, particularly if you are adding a new feature or changing the output of a program.</p> </li> + + <li> + <p>Don't forget to update the <a href="news.html">release notes</a> + by changing <code>docs/news.xml</code> if your changes are + significant. All user-visible changes, such as adding new XML elements + or fixing all but the most obscure bugs, must be (briefly) described + in a release notes entry; changes that are only relevant to other + libvirt developers, such as code refactoring, don't belong in the + release notes.</p> + </li> </ol> <p> -- 2.7.4