Typically for my projects, I try to put the changelog entry in the merge commit. So Something like
[BUGFIX] Fixes the bug #123 and then when writing a release, I run something similar to `git log --first-parent --pretty=oneline` to build my changelog On Fri, Feb 14, 2020 at 10:05 PM Bartłomiej Płotka <[email protected]> wrote: > > I think I like this idea of reusing a commit message for this! We can > definitely build some automation around this and it looks like such workflow > would be a huge improvement! > > Thanks Matthias. > > Kind Regards, > Bartek > > On Fri, 14 Feb 2020 at 13:02, 'Matthias Rampke' via Prometheus Developers > <[email protected]> wrote: >> >> In the exporters that I maintain I specifically ask contributors not to fill >> in the changelog. I want to keep a somewhat editorial voice there. I often >> rephrase changes to highlight what the change means for users, and usually >> provide extra remarks like upgrade instructions or deprecation notices. >> >> Having changelog entries added as part of PR commits also leads to endless >> merge conflicts. >> >> I usually update the changelog right after merging. I would appreciate >> building this into the PR flow in a way where I can write the changelog >> entry without having to use a command line. >> >> In Kubernetes, this seems to be done automatically by bots based on a >> section in the PR description. A big benefit of that is that as committers, >> we can edit it during review. >> >> My ideal flow would be: >> >> - the PR template has an empty entry for the changelog. a <!-- comment --> >> encourages contributors to fill it in but notes that the maintainers will >> take care of it >> - it also has an optional entry for additional changelog remarks (we can >> leave this out if it's too much) >> - as the maintainer, if I want to change or edit it, I edit the PR >> description >> - if we don't want an entry for the PR, we delete it or leave it empty >> - once I hit merge, an automatic mechanism adds both to the changelog (can >> CircleCI commit?) >> - when creating the release, the shepherd only looks over the changelog, >> possibly adds or consolidates notes about an overarching theme (say, if >> multiple PRs together introduce a change) >> >> This allows users to contribute the changelog entry, but we can edit it >> without the back-and-forth of changing commits. It splits the responsibility >> between the committer (to edit the changelog entry, if one is desired, for >> the concrete change), and the release shepherd (to make sure the changelog >> as a whole is good). The release shepherd would no longer need to look at >> every merge since the last release. Having a "field" in the description >> makes it easy for committers to edit, but keeps the distinction between >> "what does this PR do" and "what does this mean for users". >> >> /MR >> >> >> On Fri, 14 Feb 2020, 08:22 Brian Brazil, <[email protected]> >> wrote: >>> >>> On Fri, 14 Feb 2020 at 07:10, Frederic Branczyk <[email protected]> wrote: >>>> >>>> I recall Simon having a tool that would largely generate the changelog >>>> automatically, that worked pretty well last time I was release shepherd. >>>> Otherwise I'm also happy to discuss a process like in Kubernetes where the >>>> changelog item is written into the PR. On Thanos we have in the PR >>>> template that people have ensured that the changelog item was added >>>> respective to the change. Seems like there are options, >>> >>> >>> >>>> >>>> I personally would favor something that would be done at contribution >>>> time, so not all the responsibility falls on the release shepherd as it >>>> does today, and more generally it seems like the person contributing the >>>> change probably is also a good candidate to describe it in the changelog. >>> >>> >>> This is additional friction to contributions, we already have enough fun >>> getting the DCO signed. It's also an additional burden on every single PR, >>> we need to individually figure out if it's worth mentioned in the changelog >>> (many PRs aren't) and then get it in the right category, with good wording, >>> and handling the regular conflicts as everyone would be touching the same >>> lines in the same file. >>> >>> Even with all that the release shepard would still need to go through all >>> the commits and double check that nothing was missed, plus fixing poor >>> wording. I don't think saving 2-3 minutes off a release is worth all these >>> downsides. >>> >>> Brian >>> >>>> >>>> >>>> On Fri, 14 Feb 2020 at 08:05, Callum Styan <[email protected]> wrote: >>>>> >>>>> Hi all, >>>>> >>>>> I'd like to start a discussion around changing how we manage the >>>>> prometheus/prometheus changelog, specifically the fact that the changelog >>>>> is generated manually by the release shepherd as part of the release >>>>> process. >>>>> >>>>> We can discuss options for what the new process would look like, such as >>>>> requiring PR's to include changelog entries before merging or the next >>>>> release shepherd periodically updating the changelog prior to the >>>>> release, in more detail later. However I'd first like to get a sense of >>>>> whether anyone else feels strongly about either changing or not changing >>>>> this part of the release process. >>>>> >>>>> Thanks, >>>>> Callum. >>>>> >>>>> -- >>>>> 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/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.com. >>>> >>>> -- >>>> 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/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com. >>> >>> >>> >>> -- >>> Brian Brazil >>> www.robustperception.io >>> >>> -- >>> 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/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com. >> >> -- >> 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/CAFU3N5V9jDRn021txQ5CB5Cd2KTOyph5TAbtxa9cTbUXncothQ%40mail.gmail.com. > > -- > 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/CAMssQwZvLHSsFLa__12%2BAVMKhBw9h8226Xmh928JrWeUf5h%2Bfg%40mail.gmail.com. -- Paul Traylor http://kungfudiscomonkey.net/ -- 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/CAOOkOjgGJReeaj1%3Di8TXf7_jALTSsb7ZYKyR_eemBpVbVeicgw%40mail.gmail.com.
