I don't think, removing the changelog entirely is a good idea. We do not have suitable replacement.
1)
I agree with said. GIT commit messages should describe the work of developer.
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)
2)
Generating BODHI updates messages?
Definitelly +1 !
But with chance to still edit it by hand.
3)
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.
4)
A research should be made first, about how do users use the changelogs.
If they do, I'd be cautious.
5)
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.
6)
It should be part of the packaging guidelines - where should be written what.
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.
1)
I agree with said. GIT commit messages should describe the work of developer.
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)
2)
Generating BODHI updates messages?
Definitelly +1 !
But with chance to still edit it by hand.
3)
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.
4)
A research should be made first, about how do users use the changelogs.
If they do, I'd be cautious.
5)
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.
6)
It should be part of the packaging guidelines - where should be written what.
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
Core Services - Databases Team
Red Hat
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
