On Mon, 2017-03-27 at 22:38 +0200, Jiri Denemark wrote: > > When reading release notes, patch summary is not always the best > > description of what users can expect in new version. I propose > > changing it slightly so that it describes what exactly happens and > > when. > > > > However, we do not have to add every single code change to the news > > file, that would be ridiculous and unreadable for users. If the patch > > subject needs changes like this one, I'm rather tempted to say that > > such changes should not be in the news file at all. So that would be > > the other way how to fix this. > > I agree, I think we should change the "Bug fixes" part to list only > important/critical bug fixes. It's not going to be perfect since a bug > importance is a subjective thing, but we could at least make developers > think about it :-) It's already supposed to work that way. And yes, it's always going to be subjective and imperfect :) I guess the criteria for documenting a bug fix in the release notes would include the impact the bug had, both in the sense of how many people are likely to be affected, and how easy it was to run into it; more criteria could be the amount of time the bug has been present (bugs that have remained unfixed for years are unlikely to be release notes material), whether or not it was possible to work around it and just how basic the feature broken because of it is. This one looks like it would qualify on several accounts, but it could also definitely use a description to flesh out exactly what was changed, something along the lines of <summary> Initialize volumes properly when building LVM storage pools </summary> <description> Volumes containing filesystem signatures need to have it wiped out before they can be used in an LVM storage pools. libvirt was unable to wipe out the signature for some filesystem (such as ext4) but that limitation has now been addressed. </description> -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
