Just my 2¢: I'm firmly in the camp of hand-creating the CHANGELOG. I do so many editorial work on it that a pre-populated CHANGELOG might easily create more work than it saves. I do have to understand anyway what each change is doing as we are supposed to filter out changes that are not user-visible/-impacting (which could as well be that a user-visible change was introduced with its corresponding CHANGELOG entry, but later it was removed again before a release happened).
I'm essentially doing what Brian is doing when I cut a release. I only found that problematic after releases were procrastinated for too long and the CHANGELOG exploded. With the fixed cadence in prometheus/prometheus, that isn't really a problem anymore (but 2.16.0 was a biggie nevertheless). What is a problem is unclear or incomplete commit and/or PR descriptions. I guess we can all agree to ask for those in reviews. I don't feel strongly about how in detail we want to encourage good commit and PR descriptions. If we put a hint in there to suggest a changelog line if applicable, I'm all for it. If people want a specific keyword to autoextract it, sure, as long as I don't have to use it and it doesn't make it harder to contribute. I would not like to directly edit the CHANGELOG.md file in each PR, for all the reasons already stated. -- Björn Rabenstein [PGP-ID] 0x851C3DA17D748D03 [email] [email protected] -- You received this message because you are subscribed to the Google Groups "Prometheus Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/20200217150639.GL2314%40jahnn.
