Updating docs/news.xml in the same commit that performs the
documented change makes backports needlessly complicated,
both for mainteinance branches and downstream distributions,
because it introduces additional potential for merge
conflicts.

Document in the contributor guidelines that the release notes
should be updated in a separate commit instead, so that it's
easy to backport just the code change.
---
 docs/hacking.html.in | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/docs/hacking.html.in b/docs/hacking.html.in
index c7bbcbd..b1bb149 100644
--- a/docs/hacking.html.in
+++ b/docs/hacking.html.in
@@ -302,7 +302,8 @@
         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>
+        release notes. Note that <code>docs/news.xml</code> should be updated
+        in its own commit not to get in the way of backports.</p>
       </li>
     </ol>
 
-- 
2.7.4

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

On Fri, Feb 03, 2017 at 10:22:03 +0100, Andrea Bolognani wrote:
> Updating docs/news.xml in the same commit that performs the
> documented change makes backports needlessly complicated,
> both for mainteinance branches and downstream distributions,
> because it introduces additional potential for merge
> conflicts.
> 
> Document in the contributor guidelines that the release notes
> should be updated in a separate commit instead, so that it's
> easy to backport just the code change.
> ---
>  docs/hacking.html.in | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

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