I'll leave it up to the next few release shepherds to decide if they want
to revisit this topic. I'll do so myself next time I'm the release shepherd.
Thanks for the discussion everyone!
On Tue, Feb 18, 2020 at 7:56 AM Simon Pasquier wrote:
> On Fri, Feb 14, 2020 at 11:30 PM 'Matthias Rampke'
On Fri, Feb 14, 2020 at 11:30 PM 'Matthias Rampke' via Prometheus
Developers wrote:
>
> How do I make it so there is no entry?
If you mean "ignore a PR that shouldn't appear in the changelog" then
all PRs that aren't labelled will added as comments to the
CHANGELOG.md file.
>From there you're
I'm with Björn and Brian on keeping the CHANGELOG.md manually curated. You
need to understand all relevant changes since the last release anyway as
the release shepherd, and it's much easier and less overall overhead to
weigh everything centrally in the end than trying to get everyone to
formulate
Adopting one of many variants of semantic commits and using one of many
tools that generates a changelog from it can save some time there.
Examples: example: https://www.conventionalcommits.org/,
https://keepachangelog.com/
Going that path is easier if one uses commit message linter, to ensure
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
How do I make it so there is no entry?
On Fri, 14 Feb 2020, 18:07 Simon Pasquier, wrote:
> Correct, the PR is in the promu repository (I've updated it just now
> to address comments from Brian though it should have been done long
> ago):
> https://github.com/prometheus/promu/pull/170
>
> Right
Correct, the PR is in the promu repository (I've updated it just now
to address comments from Brian though it should have been done long
ago):
https://github.com/prometheus/promu/pull/170
Right now, it leverages the PR labels to classify the change (BUGFIX,
CHANGE, ...) and it uses the PR's title
>
> 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.
I agree with Bartek's response here, it's not a 2-3
But we don't have to block on changelog entries like we do for DCO legal
requirements.
For example, in GitLab codebases, we have a CI test that warns if a
changelog entry is missing. Unless you tag the review with a label.
On Fri, Feb 14, 2020 at 2:22 PM Brian Brazil <
The way I've been doing it in the node_exporter is to ask for the changelog
entry, but I don't block on it. If the code is ok, but they don't add a
changelog entry, I'll merge and do it myself.
Usually what saves the round trip time is I include a copy-paste text of
exactly what I want in the
On Fri, 14 Feb 2020 at 13:15, Matthias Rampke wrote:
> The friction is real – DCO is not a submission quality issue but a
> roundtrip one. This would be even more difficult with wording.
>
I'm with Matthias on this one. We've often have PRs which are ready to
merge, but have been sitting there
On Fri, 14 Feb 2020 at 12:50, Bartłomiej Płotka wrote:
> 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
>
The friction is real – DCO is not a submission quality issue but a
roundtrip one. This would be even more difficult with wording.
I agree that in *many* cases contributors can write the changelog entry;
having the field in the PR template would encourage them to do so
proactively.
/MR
On Fri,
DCO is a strawman argument. We're always going to have issues with
submission quality.
I've had very good luck asking for changelog entries on the node_exporter.
On Fri, Feb 14, 2020 at 8:22 AM Brian Brazil <
brian.bra...@robustperception.io> wrote:
> On Fri, 14 Feb 2020 at 07:10, Frederic
On 14 Feb 13:07, 'Matthias Rampke' via Prometheus Developers wrote:
> No – I mean to explicitly *not* use commit messages or anything that
> requires the contributor to change. I want to keep it in the PR
> *description* that is editable through the GitHub UI.
>
> /MR
Like a prombot command
Sorry, I somehow was treating those the same. PR description would do even
better agree!
Kind Regards,
Bartek
On Fri, 14 Feb 2020 at 13:08, Paul Traylor wrote:
> Typically for my projects, I try to put the changelog entry in the
> merge commit. So Something like
>
> [BUGFIX] Fixes the bug
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
No – I mean to explicitly *not* use commit messages or anything that
requires the contributor to change. I want to keep it in the PR
*description* that is editable through the GitHub UI.
/MR
On Fri, Feb 14, 2020 at 1:05 PM Bartłomiej Płotka
wrote:
> I think I like this idea of reusing a commit
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 <
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.
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 (:
On Fri, 14 Feb 2020 at 07:10, Frederic Branczyk 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
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
23 matches
Mail list logo
