On Thu, Jan 05, 2017 at 03:34:37PM +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. > --- > 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> s/html/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.</p> > + </li> Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
