On 20/09/2018 08:35, Jimmy Berry wrote:
On Wednesday, September 19, 2018 5:33:41 PM CDT Neal Gompa wrote:
It might also help if we didn't let people put ridiculously awful changelog entries (often generated by source services or something) due to the (IMO) odd desire to put lots of upstream changelog details from VCS history. I don't even bother to review some packages' changelogs on my computer anymore because too many packages make functionally useless changelogs because they just copy VCS history in, which is too much...
I 100% agree with this, but opposite of policy. If one says "Update to version 1.2.3" with a link to upstream changelogs that will be denied. IMO changelogs should contain RPM specific changes, spec reworking, new exposed features, build flag changes, etc, but leave upstream to upstream. If there is an exceptionally noteworthy upstream change sure, but for must packages this really does not apply.
The automatic changelogs taken from vcs commits is the result since it is essentially what one has to do manually although it does not scale beyond relatively small projects.
Use VCS for VCS and leave changelog to be a curated summary of relevant information.
This is all off-topic of course.
Its off the topic of the original post but still on topic for this list. The best way to interpret this policy is generally somewhere in between nothing but including a link and everything. Sure if its a bug fix release and there's less then 10 commits, including them all is fine. Normally for new releases I will take something derived from the upstream release notes which hopefully include all the major changes and atleast a list of bugs that were fixed + any changes I made to packaging. This is generally far more useful then a whole commit log and with most upstreams doesn't take much work to put together. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B