On Mon, 2018-07-09 at 14:43 +0200, Michal Privoznik wrote: I think adding a new element for it would definitely be the way to go, since the whole point of using XML as the source format is storing structured information instead of free-form text. Recording the Bugzilla link was also suggested in the past, which I feel would be a great idea - just never got around to it :) That said, for git commits specifically there are at least two issues I can think of: * most of the time, features and bugfixes happen over the span of several commits; having a "starting point" could be nice, but you're still going to have to look around a bit; * most importantly, when release notes are updated as intended, ie. along with the changes they're documenting, you don't know the commit hash yet. So you'd have to take your branch, rebase it on top of master, merge it into master, amend the last commit to include the hash for the commit you feel can best represent the change in the release, and only then you can push... Assuming, of course, nobody pushed anything in the meantime! Because then you'd have to repeat the last step again, possibly multiple times if it's a very busy day. All things considered, it seems like including commit information in the release notes would be quite a bit of effort and have a lot of room for error, so I'm not too convinced we want to move in that direction after all. Note that, for features and bugs tracked on Bugzilla, it's fairly common practice to add a comment pointing to the commit(s) once the relevant code has been merged, which means including a link to Bugzilla as mentioned above would kind of partially address this too :) -- Andrea Bolognani / Red Hat / Virtualization