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 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 | 6 ++++++
docs/hacking.html.in | 9 +++++++++
2 files changed, 15 insertions(+)
diff --git a/HACKING b/HACKING
index c2cb037..b2c0fc1 100644
--- a/HACKING
+++ b/HACKING
@@ -226,6 +226,12 @@ 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> 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-projects/>.
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 47475a2..3605055 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -294,6 +294,15 @@
<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>
+ 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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
