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 < prometheus-developers@googlegroups.com> 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, <brian.bra...@robustperception.io> > wrote: > >> On Fri, 14 Feb 2020 at 07:10, Frederic Branczyk <fbranc...@gmail.com> >> 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 <callumst...@gmail.com> >>> 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 prometheus-developers+unsubscr...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/prometheus-developers/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/prometheus-developers/CAN2d5OTjOrCfpRF_NXGcQB5nOz%3DVPgnz3LdEk15ucV4PFz%2B4BQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >>> 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 prometheus-developers+unsubscr...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/prometheus-developers/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com >>> <https://groups.google.com/d/msgid/prometheus-developers/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >>> >> >> >> -- >> 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 prometheus-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com >> <https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- > 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 prometheus-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/prometheus-developers/CAFU3N5V9jDRn021txQ5CB5Cd2KTOyph5TAbtxa9cTbUXncothQ%40mail.gmail.com > <https://groups.google.com/d/msgid/prometheus-developers/CAFU3N5V9jDRn021txQ5CB5Cd2KTOyph5TAbtxa9cTbUXncothQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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 prometheus-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAMssQwZvLHSsFLa__12%2BAVMKhBw9h8226Xmh928JrWeUf5h%2Bfg%40mail.gmail.com.
