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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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-projects/>.
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

--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list



[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]
  Powered by Linux