On Thu, Jan 05, 2017 at 11:03:51AM +0100, Martin Kletzander wrote:
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>
Oh, and you forgot to regenerate HACKING again ;)
Attachment:
signature.asc
Description: Digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
