--
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-devel...@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.
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.
--On Fri, 14 Feb 2020 at 08:05, Callum Styan <callu...@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-devel...@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.
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-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAOs1UmyOfHbC75bdk55frFQt-KYgD6cg7vh%2BCPSmVmMnSV3sng%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAFU3N5V9jDRn021txQ5CB5Cd2KTOyph5TAbtxa9cTbUXncothQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAHJKeLrFL_kN28EiagWYFbKMr5XWC%2Bk7h8n9D8VijvmOnX_5Tw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CABbyFmoOTL3BvNguLk%3D%3DpNJi52zP458DugtpOTz0HAdQanyXgQ%40mail.gmail.com.
Hi,
> 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.
It is 2h do it properly for mere mortals Brian (: Seriously, have been there.
The friction is real – DCO is not a submission quality issue but a roundtrip one. This would be even more difficult with wording.
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.
Even with all these changes, the only thing you'd save is the copying&pasting bit as the release shepard still needs to do all of the rest which is why I'm saying 2-3 minutes.
DCO is a strawman argument. We're always going to have issues with submission quality.
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)
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/CAM6RFu79WLX7ZZezxMvQdinV5VMdP-0pfPSfTPs45g7RO-qGcA%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 prometheus-devel...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/prometheus-developers/da403d28-cfad-41c2-8d0b-91168be070f5%40googlegroups.com.