On Sun, Jan 01 2017, Andreas Henriksson wrote: > My personal opinion is that a changelog is something where every change > is guaranteed to be logged. (And that guarantee is basically just saying > that if it's ever noticed that a change was not logged, that's indeed a > bug.) > A NEWS file is something different to me in that it's a subset of the > changelog. Sometimes that subset might be equal to the entire changelog > set, but there's no guarantee that NEWS logs every change - rather the > opposite.
Fully agree here. > Additionally possibly clarify that when something is not available from > upstream people should *not* go out of their way to find something to > stuff in there. Many times I've heard that "policy says I have to" > when asking people why they're insisting on showing a bad lie down my > throut when they could have just left it out (because all > policy really said was just "...should ... if ..."). > > In other words, I support suggestion number 1 (with the extension of > standardizing the NEWS name along side changelog). I would also like this approach. Reading a release summary in a changelog is a "quirk" I've sometimes came to expect from packages. There is a push to ship a changelog, which is why many packages go to great lengths to put something there. But changelogs are rarely useful for users. I'm a developer, and I never read changelogs, as they're almost never useful unless you also have the source at hand. If I need to, I go to the source repository and get the history from there. I /could/ want the source package to include it (as it generally strips the repository metadata), but not the binary. In fact, I'd rather have a consistent NEWS location, and shift the focus to this release summary instead, while not changing the existing changelog rules. It's way more consistent with the best practices already seen everywhere in source tarballs. As an user, I really want the release summary.
