[CHANGELOG] Drop redundant OpenID items

[strk]

OpenID-2.0 login is a new feature, there's no point in mentioning
every single change included in that feature.

NOTE:
there are a lot more of these cases, just I'm not sure I've the
time to deal with them all, so this PR is a first step which I hope
can be used as an example to further simplify that file

[lunny]

Don't know the meaning of this PR? Since you removed all the OpenID related changelog, how users know what's happened about OpenID on v1.2?

[strk]

There's a single item left, which is probably hard to find due to the excessive noise of the rest (only this one had 11 items before this change!). The entry reads: * Login via OpenID-2.0 (#618) And it's everything users want to know.

[ptman]

Looks much better. A good changelog doesn't list every commit. http://keepachangelog.com/en/1.0.0/

[bkcsoft]

Why do we even have the changelog entries for RCs?

[strk]

On Mon, Oct 09, 2017 at 03:32:40PM -0700, bkcsoft wrote: Why do we even have the changelog entries for RCs?

That's a good question too, but I kept this PR small and focused in hope it would be merged quickly, postponing any further cleaning to later. This limited maintainers power is really annoying...

[bkcsoft]

I agree that since this is for a single release we don't have to list all the OpenID PRs separately. Maybe have the other PR-numbers on the line that's left though?

[lafriks]

Yes but the problem is we generate it automatically. Any ideas how to mark PR to group them together in on changelog?

[daviian]

I think that if we manage to stick to a short release cycle, we don't have to summarize the PRs as there won't be that much anyway...
However we have to pull ourselfs up on making small and early releases.

[bkcsoft]

Biggest issue I've seen with making releases is that it's cumbersome. Just to give an indication:

1. Generate changelog from git log --oneline v${oldVer}.. >> CHANGELOG.md & edit
2. commit and PR (in both master and release-branch), wait for merge
3. (optionally branch release-branch)
4. tag v${newVer} from release-branch
5. Make and upload blogpost, wait for PR merge

All in all takes about a day if you're lucky

It would be better if Changelog was auto-generated, so we could skip the PR-stage to that and just commit directly to master & rel-branch. But blogpost still takes time.

And then hopefully the build-system works as intended ;)

[strk]

Wasn't there a proposal to include changelog entries as part of feature PRs ? That way a PR for a fix of a feature which was added in a previous PR but still not released would not need a changelog entry...

[bkcsoft]

There was/is #505, and yes that would not need an entry for fixes in the same release.

[lunny]

@strk I think we should discuss these on a release notes PR but not a new PR. And since v1.2.0 has been released. I think we can close this one and be careful when we release v1.3.0