I don't think, removing the changelog entirely is a good idea. We do not
have suitable replacement.

I agree with said. GIT commit messages should describe the work of
Thus messages like "typo fix" "revert of revert of merge of ..." "forgot to
add new-sources" are common, and should stay as they are. (Because they
well describe what changes has been made from developer / maintainer POV)

Generating BODHI updates messages?
Definitelly +1 !
But with chance to still edit it by hand.

What should be written to the changelog? IMHO the stuff that changed from
user POV.
So stuff like "update to NVR" "changelog can be found at URL" "CVEs fixed:
1, 2, 3, 4, ..." "bugs solved: RHBZ#1, 2, 3, 4, ..." "compiler optimization
for F22 disabled for PPC64le, because of bug XYZ"
And I don't see any other suitable place to add this.

A research should be made first, about how do users use the changelogs.
If they do, I'd be cautious.

The changelogs are long ass hell.
What about keeping just 2 latest releases in it and deleting the rest? (It
will be still kept in GIT history)
2 releases could be 2-20 entries, depends of work done.
But still it looks short enough for me.

It should be part of the packaging guidelines - where should be written
Probabbly not in a form of unbreakable rule, but rather information to the
packagers how to do it, and remind of things they shouldn't forget to write
down there.


Michal Schorm
Associate Software Engineer
Core Services - Databases Team
Red Hat
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to