On Wed, Jan 04, 2017 at 04:49:09PM +0100, Andrea Bolognani wrote:
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.
---
docs/hacking.html.in | 8 ++++++++
1 file changed, 8 insertions(+)
diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index 47475a2..f6e9d7a 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -293,6 +293,14 @@
<li>
<p>Update tests and/or documentation, particularly if you are adding
a new feature or changing the output of a program.</p>
+
+ <p>If your changes are significant, you should also document them
+ in the <a href="news.html">release notes</a>. The rule of
thumb is
+ that user-visible changes, such as adding new XML elements or fixing
+ all but the most obscure bugs, should be documented properly; changes
"documented" doesn't necessarily mean "documented in release
notes", I
would like to have this clarified here.
+ that are only relevant to other libvirt developers, such as
code
+ refactoring, should not.
+ </p>
Don't be afraid of "must" here, as in RFC 2119, or just do what the
previous paragraph does and say: "Update release notes when ..."
Maybe this can be in its own list item.
</li>
</ol>
--
2.7.4
--
libvir-list mailing list
libvir-list(a)redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list