[prometheus-developers] Remote write improvement design docs

[Callum Styan]

Hi all,

I wanted to share two design docs with you related to improvements I (and
others) have been slowly working on/discussing related to remove write:

1) improvements to the remote write wire format

2) idle CPU usage when there is low metric scrape throughput


Both docs are obviously still up for discussion, but I wanted to share
progress on some of the proposals listed in each.

For the remote write wire format, I have a WIP PR here
 for the protobuf
changes. I'll also be speaking at Tokyo Dev Ops days about Prometheus,
remote write, and this PR.

For the idle cpu usage, the Grafana agent team has implemented on of the
proposals but for tailing of logs (see here
 and here
)

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/CAN2d5OQgOruvBqR64AyKk3%3Dn-%2BFrd239Wz%3DNuOKKs_LUGR6miQ%40mail.gmail.com.

Re: [prometheus-developers] [VOTE] Rename blackbox_exporter to prober

[Callum Styan]

ABSTAIN

I don't have a strong enough opinion to vote either way.

On Mon, Jan 24, 2022 at 1:26 PM Richard Hartmann <
richih.mailingl...@gmail.com> wrote:

> PS: I would prefer if such a change would happen as part of a
> Prometheus 3.x -- but I don't know if that's realistic.
>
> --
> 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/CAD77%2BgTWYyqMfR8SGe9fgkaz9r0Ve%3DnbFd-NPpKenwOjwiyB2g%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAN2d5ORKWC3qJJkTwF4ZoNRyu%3Dy74ECRxyGmZ-tuGWii0O6fEA%40mail.gmail.com.

Re: [prometheus-developers] Re: Proposal: In-memory Exemplar Storage

[Callum Styan]

Hi all,

I've taken up my work on exemplars again; the above PR and design doc are
still relevant but I'll paste the links again below.

I've changed the PR from a draft to open, it's still rough but I would
appreciate feedback. Note that the implementation is in memory, using a
single fixed size circular buffer (size configurable by users) so that
overall memory usage by exemplar storage is bounded.

design doc
<https://docs.google.com/document/d/1ymZlc9yuTj8GvZyKz1r3KDRrhaOjZ1W1qZVW_5Gj7gA/edit?usp=sharing>
PR <https://github.com/prometheus/prometheus/pull/6635>

Thanks,
Callum.

On Fri, Mar 20, 2020 at 3:31 AM Bartłomiej Płotka 
wrote:

> Awesome! Exciting work, thanks for sharing. Will take a look in following
> days / weekend (:
>
> Kind Regards,
> Bartek
>
> On Thu, 19 Mar 2020 at 21:27, Callum Styan  wrote:
>
>> Hi all,
>>
>> For those who are interested, I've added notes on how the exemplar
>> storage might handle tail based sampling of traces. These notes are based
>> on discussions I've had with a few people involved in/working on tracing
>> systems.
>>
>> As usual, please let me know if you have any feedback.
>>
>> The current exemplar storage PR is here:
>> https://github.com/prometheus/prometheus/pull/6635 In the current state,
>> building Prometheus from that branch will allow you to scrape, store, and
>> query exemplars.
>>
>> Thanks,
>> Callum.
>>
>> On Thu, Jan 9, 2020 at 3:39 PM Callum Styan 
>> wrote:
>>
>>> Hi all,
>>>
>>> As many of you know we've been planning to add minimal in-memory storage
>>> of exemplars within Prometheus for some time now. Some work has already
>>> been done in this area; including the exposition of exemplars in the Python
>>> client
>>> <https://github.com/prometheus/client_python/search?q=exemplar_q=exemplar>,
>>> and parsing of the Open Metrics exemplar format
>>> <https://github.com/prometheus/prometheus/pull/6292> by the
>>> M3/Chronosphere folks, who also proposed a possible storage interface
>>> here <https://github.com/prometheus/prometheus/pull/6309>.
>>>
>>> More recently some of us have been putting together a design doc for the
>>> end to end exemplar experience within Prometheus; discussing what the query
>>> flow for exemplars might look like from Grafana itself, what the storage
>>> interface (external and internal) API might look like, and how the internal
>>> storage could be implemented.
>>>
>>> Some of you have also seen the experimental implementation PR
>>> <https://github.com/prometheus/prometheus/pull/6574> I opened a few
>>> days ago. From the comments there it sounds like there may be exemplar
>>> querying use cases that haven't been discussed yet, which I would ask you
>>> to make note of in the design doc.
>>>
>>> With all that said, here's the design doc
>>> <https://docs.google.com/document/d/1ymZlc9yuTj8GvZyKz1r3KDRrhaOjZ1W1qZVW_5Gj7gA/edit?usp=sharing>.
>>> Note that an implementation has not been finalized yet.
>>>
>>> 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/CAN2d5OT%2BJi4DB4fupTyjsgRa_T%2ByZiiVfG-FuEJDRV%3DWXDJDvg%40mail.gmail.com
>> <https://groups.google.com/d/msgid/prometheus-developers/CAN2d5OT%2BJi4DB4fupTyjsgRa_T%2ByZiiVfG-FuEJDRV%3DWXDJDvg%40mail.gmail.com?utm_medium=email_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/CAN2d5OS_9wamDTbEdJReYdNtuY81oZTkHAS4gCvBf%3Dm0jbWB9A%40mail.gmail.com.

Re: [prometheus-developers] Prometheus Storage Working Group

[Callum Styan]

I'd be interested in joining but the earliest I could do is around 1400 GMT
(I'm GMT-7 currently). If I'm the only one who can't make the time you're
proposing then that's okay, it's hard to schedule things at times that both
Ganesh and I can attend :)

On Mon, Sep 7, 2020 at 7:06 AM Manish G 
wrote:

> I am keen to be part of the initiative, but am relatively new to
> prometheus.
>
> With regards
>
> On Mon, Sep 7, 2020 at 4:28 PM fbra...@gmail.com 
> wrote:
>
>> Hello Prometheans,
>>
>> There have been various ideas around potentially improving parts of
>> Prometheus' TSDB. I would like to start a working group that meets
>> regularly around these topics and compares notes, researches, and
>> experiments with potential improvements and hopefully ultimately develop
>> designs to be proposed as improvements to Prometheus.
>>
>> I've been talking to Ganesh about this topic a bit and we've put together
>> a small starting document to kick this off:
>> https://docs.google.com/document/d/1HWL-NIfog3_pFxUny0kAHeoxd0grnqhCBcHVPZN4y3Y/edit?usp=sharing
>>
>> The idea, for now, is to meet at a biweekly cadence at 9 AM GMT for 30
>> minutes, a link to the meeting is in the above document. (this works for
>> Ganesh and me, we're open to rescheduling this and or extending this if
>> needed)
>>
>> The first meeting for this is scheduled for the 22nd of September. There
>> will be meeting notes, so if you're just interested in the results read
>> those, if you're interested in contributing to these topics join us! :)
>>
>> Best regards,
>> Frederic
>>
>> --
>> 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/ab025c6f-c37d-44e0-8dba-455ac9c1fadfn%40googlegroups.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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CAOFd6ii279fV0XBxU5H0Ra4h3iuNmkxFt1QYY_%3D96kGnaOxKBQ%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAN2d5ORgRyN%2BkXjj8Qe7HmRZERmuMfSyWTFnnfjXpW4Ms1%3DWcw%40mail.gmail.com.

Re: [prometheus-developers] Re: Remote Write Metadata propagation

[Callum Styan]

I'm hesitant to add anything that significantly increases the network
bandwidth usage or remote write while at the same time not giving users a
way to tune the usage to their needs.

I agree with Brian that we don't want the protocol itself to become
stateful by introducing something like negotiation. I'd also prefer not to
introduce multiple ways to do things, though I'm hoping we can find a way
to accommodate your use case while not ballooning average users network
egress bill.

I am fine with forcing the consuming end to be somewhat stateful like in
the case of Josh's PR where all metadata is sent periodically and must be
stored by the remote storage system.

Overall I'd like to see some numbers regarding current network bandwidth of
remote write, remote write with metadata via Josh's PR, and remote write
with sending metadata for every series in a remote write payload.

Rob, I'll review your PR tomorrow but it looks like Julien and Brian may
already have that covered.

On Sun, Aug 9, 2020 at 9:36 PM Rob Skillington  wrote:

> Update: The PR now sends the fields over remote write from the WAL and
> metadata
> is also updated in the WAL when any field changes.
>
> Now opened the PR against the primary repo:
> https://github.com/prometheus/prometheus/pull/7771
>
> I have tested this end-to-end with a modified M3 branch:
> https://github.com/m3db/m3/compare/r/test-prometheus-metadata
> > {... "msg":"received
> series","labels":"{__name__="prometheus_rule_group_...
> > iterations_total",instance="localhost:9090",job="prometheus01",role=...
> > "remote"}","type":"counter","unit":"","help":"The total number of
> scheduled...
> > rule group evaluations, whether executed or missed."}
>
> Tests still haven't been updated. Please any feedback on the approach /
> data structures would be greatly appreciated.
>
> Would be good to know what others thoughts are on next steps.
>
> On Sat, Aug 8, 2020 at 11:21 AM Rob Skillington 
> wrote:
>
>> Here's a draft PR that builds that propagates metadata to the WAL and the
>> WAL
>> reader can read it back:
>> https://github.com/robskillington/prometheus/pull/1/files
>>
>> Would like a little bit of feedback before on the datatypes and structure
>> going
>> further if folks are open to that.
>>
>> There's a few things not happening:
>> - Remote write queue manager does not use or send these extra fields yet.
>> - Head does not reset the "metadata" slice (not sure where "series" slice
>> is
>>   reset in the head for pending series writes to WAL, want to do in same
>> place).
>> - Metadata is not re-written on change yet.
>> - Tests.
>>
>>
>> On Sat, Aug 8, 2020 at 9:37 AM Rob Skillington 
>> wrote:
>>
>>> Sounds good, I've updated the proposal with details on places in which
>>> changes
>>> are required given the new approach:
>>>
>>> https://docs.google.com/document/d/1LY8Im8UyIBn8e3LJ2jB-MoajXkfAqW2eKzY735aYxqo/edit#
>>>
>>>
>>> On Fri, Aug 7, 2020 at 2:09 PM Brian Brazil <
>>> brian.bra...@robustperception.io> wrote:
>>>
 On Fri, 7 Aug 2020 at 15:48, Rob Skillington 
 wrote:

> True - I mean this could also be a blacklist by config perhaps, so if
> you
> really don't want to have increased egress you can optionally turn off
> sending
> the TYPE, HELP, UNIT or send them at different frequencies via config.
> We could
> package some sensible defaults so folks don't need to update their
> config.
>
> The main intention is to enable these added features and make it
> possible for
> various consumers to be able to adjust some of these parameters if
> required
> since backends can be so different in their implementation. For M3 I
> would be
> totally fine with the extra egress that should be mitigated fairly
> considerably
> by Snappy and the fact that HELP is common across certain metric
> families and
> receiving it every single Remote Write request.
>

 That's really a micro-optimisation. If you are that worried about
 bandwidth you'd run a sidecar specific to your remote backend that was
 stateful and far more efficient overall. Sending the full label names and
 values on every request is going to be far more than the overhead of
 metadata on top of that, so I don't see a need as it stands for any of this
 to be configurable.

 Brian


>
> On Fri, Aug 7, 2020 at 3:56 AM Brian Brazil <
> brian.bra...@robustperception.io> wrote:
>
>> On Thu, 6 Aug 2020 at 22:58, Rob Skillington 
>> wrote:
>>
>>> Hey Björn,
>>>
>>>
>>> Thanks for the detailed response. I've had a few back and forths on
>>> this with
>>> Brian and Chris over IRC and CNCF Slack now too.
>>>
>>> I agree that fundamentally it seems naive to idealistically model
>>> this around
>>> per metric name. It needs to be per series given what may happen
>>> w.r.t.
>>> collision across targets, etc.
>>>

Re: [prometheus-developers] [VOTE] Allow Kelvin as temperature unit in some cases

[Callum Styan]

YES

On Thu, May 28, 2020 at 11:52 AM Bjoern Rabenstein 
wrote:

> Dear Prometheans,
>
> So far, we have recommended Celsius as the base unit for temperatures,
> despite Kelvin being the SI unit. That was well justified by the
> overwhelming majority of use cases, where Kelvin would be just
> weird. I'd really like to see more scientific usage of Prometheus, so
> I was never super happy with that recommendation, but since it was
> just a recommendation, I could live with it.
>
> Now Matt Layher came up with another, more technical use case: color
> temperature. Here, using Celsius would be even weirder. So there is a
> case where you clearly do not want to follow the suggestion of the
> linter, which is more in line with typical Prometheus use cases than
> my arguably somewhat far fetched time series for low-temperature
> experiments.
>
> Therefore, Matt suggested to make the metrics linter not complain
> about kelvin.
>
> I think this is a clearly defined problem with clear arguments and a
> clear disagreement between Brian Brazil on the one side and Matt and
> myself on the other side. The appropriate amount of effort has been
> spent to find a consensus. All arguments can be found in
> https://github.com/prometheus/client_golang/pull/761 and
> https://github.com/prometheus/docs/pull/1648 .
>
> I hereby call a vote for the following proposal:
>
> Allow Kelvin as a base unit in certain cases and update our
> documented recommendation and the linter code accordingly.
>
>
> (The changes may take the form of the two PRs out there, but the vote
> in about the general idea above, not the implementation detail.)
>
>
> The vote closes on 2020-06-04 20:00 UTC.
> --
> Björn Rabenstein
> [PGP-ID] 0x851C3DA17D748D03
> [email] bjo...@rabenste.in
>
> --
> 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/20200528185216.GK2326%40jahnn
> .
>

-- 
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/CAN2d5ORc0WoNd43Gp0VkJUMowuoJW4oC2FHGj%2B5o201CsC%3DpiA%40mail.gmail.com.

[prometheus-developers] Re: Proposal: In-memory Exemplar Storage

[Callum Styan]

Hi all,

For those who are interested, I've added notes on how the exemplar storage
might handle tail based sampling of traces. These notes are based on
discussions I've had with a few people involved in/working on tracing
systems.

As usual, please let me know if you have any feedback.

The current exemplar storage PR is here:
https://github.com/prometheus/prometheus/pull/6635 In the current state,
building Prometheus from that branch will allow you to scrape, store, and
query exemplars.

Thanks,
Callum.

On Thu, Jan 9, 2020 at 3:39 PM Callum Styan  wrote:

> Hi all,
>
> As many of you know we've been planning to add minimal in-memory storage
> of exemplars within Prometheus for some time now. Some work has already
> been done in this area; including the exposition of exemplars in the Python
> client
> <https://github.com/prometheus/client_python/search?q=exemplar_q=exemplar>,
> and parsing of the Open Metrics exemplar format
> <https://github.com/prometheus/prometheus/pull/6292> by the
> M3/Chronosphere folks, who also proposed a possible storage interface here
> <https://github.com/prometheus/prometheus/pull/6309>.
>
> More recently some of us have been putting together a design doc for the
> end to end exemplar experience within Prometheus; discussing what the query
> flow for exemplars might look like from Grafana itself, what the storage
> interface (external and internal) API might look like, and how the internal
> storage could be implemented.
>
> Some of you have also seen the experimental implementation PR
> <https://github.com/prometheus/prometheus/pull/6574> I opened a few days
> ago. From the comments there it sounds like there may be exemplar querying
> use cases that haven't been discussed yet, which I would ask you to make
> note of in the design doc.
>
> With all that said, here's the design doc
> <https://docs.google.com/document/d/1ymZlc9yuTj8GvZyKz1r3KDRrhaOjZ1W1qZVW_5Gj7gA/edit?usp=sharing>.
> Note that an implementation has not been finalized yet.
>
> 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/CAN2d5OT%2BJi4DB4fupTyjsgRa_T%2ByZiiVfG-FuEJDRV%3DWXDJDvg%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Callum Styan]

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' 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 still free to rearrange whatever has been produced.
>
> Here is an example with Alertmanager:
>
> https://github.com/simonpasquier/alertmanager/commit/7fde3cc25471c626e82def873a01a9924e1816ae
>
>
> >
> > 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 now, it leverages the PR labels to classify the change (BUGFIX,
> >> CHANGE, ...) and it uses the PR's title as the changelog entry. It
> >> wouldn't be hard to mimic what Kubernetes is doing and lookup the
> >> changelog entry in the PR description as Matthias suggested. If
> >> nothing is found it can always fallback to the title.
> >> I agree that asking every PR to include the changelog update might not
> >> be convenient (both for the contributor and the maintainer).
> >>
> >> On Fri, Feb 14, 2020 at 8:10 AM 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 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 
> 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
> .
> >> >
> >> > --
> >> > 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
> .
> >>
> >> --
> >> 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 

Re: [prometheus-developers] [VOTE] New governance document

[Callum Styan]

Yes

On Fri, Feb 21, 2020 at 6:11 AM Chris Marchbanks 
wrote:

> Yes
>
> On Wed, Feb 19, 2020 at 1:44 PM Richard Hartmann <
> richih.mailingl...@gmail.com> wrote:
>
>> Dear all,
>>
>> I am hereby calling for a vote on merging
>> https://github.com/prometheus/docs/pull/1552 at commit
>> de2266c36d8a2ea1f139f97632808e12b354bb76.
>>
>> References and discussion can be found in said PR and in the email
>> thread "Pre-vote feedback on proposed governance changes" on
>> prometheus-team (not visible to the public).
>>
>> This vote will run until 2020-02-26 23:59 UTC or when supermajority
>> has been reached, whichever comes first.
>>
>>
>> Please note that while we are voting in public, only Prometheus team
>> members are eligible to vote.
>>
>>
>> Best,
>> Richard
>>
>> --
>> 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/CAD77%2BgTHNk%3DORUiU%3DKucKtgKDUtSEfGv%2BQVLFKB-d0sVc%2ByBNQ%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-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/prometheus-developers/CANVFovU6Lk1NiCdpkUdjDZg_09A1qqGTgDabTYbJKokoqhs33Q%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-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/prometheus-developers/CAN2d5OQfBX9Ee6cQZi4%3DfS4UGRQgEARi9hT9BinE9JCvUhweJA%40mail.gmail.com.

Re: [prometheus-developers] prometheus/prometheus Changelog Management

[Callum Styan]

>
> 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 minute process at all.
Not everyone is familiar with as many areas of the prometheus/prometheus
code as you are, and we're not reviewing or merging most of the PR's in
areas we don't know about. Another factor is the fact that commit messages
and PR descriptions vary widely, and in some cases merged PR's had no
descriptions and commit messages that did not really accurately reflect the
user facing change of the PR.

Even with all these changes, the only thing you'd save is the
> copying bit as the release shepard still needs to do all of the
> rest which is why I'm saying 2-3 minutes.

The point is the messages you're copy/pasting are not necessarily accurate,
and again it's not 2-3 minutes.

DCO is a strawman argument. We're always going to have issues with
> submission quality.

Yes. While I think the delaying of PR merges and having to rebase because
of CHANGELOG.md are valid concerns, I don't think we should choose not to
adopt some improved changelog management based on these reasons. As you
say, we're always going to have issues with varying quality of drive by
submissions. We can only do our best to encourage people submitting those
PR's to be good citizens and help make our lives easier.

Right now I'm liking Matthias' idea:

> My ideal flow would be:

- the PR template has an empty entry for the changelog. a 
> 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)


I also like the idea of a prombot command like Julien brought up.

-- 
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/CAN2d5ORVNwUb4JUEYGZ%2BN0buAg1ndvz_H3hEAUd%3DskZHMCV1KA%40mail.gmail.com.

[prometheus-developers] prometheus/prometheus Changelog Management

[Callum Styan]

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.